소개
Willow Commons에는 이미 정상적으로 작동하는 커뮤니티 웹사이트가 있습니다. 이전하기 전에 클라이언트가 실제로 어느 주소를 사용하는지 알아보세요. 저장된 DNS 레코드, 캐시에 있는 응답, 웹사이트 응답은 요청 경로의 서로 다른 부분을 설명합니다.
먼저 정상 사이트를 사용한 뒤 실제 권한 DNS 서버와 독립적인 캐싱 리졸버를 비교하고, 별도의 연습용 이름을 변경합니다. 이 단원에서는 커뮤니티가 사용하는 정식 사이트 이름을 바꾸지 않습니다. 두 HTTP 백엔드와 DNS 서비스는 하나의 VM 커널을 공유하는 격리된 Linux 네트워크 네임스페이스에 준비되어 있습니다.
터미널 명령 입력, 경로 구분, 탭 전환에 익숙해야 합니다. 이 실습에서 사용하는 DNS 명령과 작은 설정 변경은 직접 설명합니다. 공개 도메인 계정이나 BIND 관리 경험은 필요하지 않습니다. 읽기와 일반적인 실수 처리를 포함해 약 40분을 예상하세요. 이는 작성자의 추정입니다.
작동 중인 사이트를 이름으로 사용하기
이 단계에서는 커뮤니티의 기존 사이트를 읽고 실제 행사 안내를 저장합니다. Community Preview에서 시작해 Warm Client를 선택하세요. Willow Commons 페이지, 세 모임, old location 표시가 보여야 합니다. Download the programme을 선택해 다운로드한 텍스트를 여세요. 위치 표시는 백엔드의 신원이며, 성공을 연출하는 애니메이션이 아닙니다.
상단 근처의 위치 표시를 읽은 다음 세 모임 아래의 Download the programme을 사용하세요. 그림의 페이지는 원래 백엔드가 실제로 반환한 응답입니다.
미리보기는 선택한 과정 클라이언트에서 실제 DNS 조회와 HTTP 요청을 수행합니다. 바깥쪽 플랫폼 URL은 브라우저 게이트웨이이며, 여러분의 컴퓨터가 과정의 DNS를 사용한다는 뜻은 아닙니다. 브라우저를 새로 고치면 새 요청을 보내지만 과정 리졸버의 캐시는 비우지 않습니다. 지금은 Fresh Client를 사용하지 마세요.
Warm Client 터미널로 전환하세요. 이 클라이언트는 자체 리졸버 설정을 가지며 /home/labex/project/site-move/warm에서 시작합니다. pwd는 현재 디렉터리를 출력합니다.
pwd
DNS, 즉 도메인 이름 시스템은 이름을 주소에 대응시킵니다. A 레코드는 이름을 IPv4 주소에 대응시킵니다. 그다음 HTTP는 해당 주소와 포트를 이용해 콘텐츠를 요청합니다. 여기서 이름은 site.community.test입니다. 8081은 HTTP 포트이지 DNS 레코드 값이 아닙니다. .test는 테스트를 위해 예약된 접미사이며 공개 커뮤니티 도메인이 아닙니다.
curl은 HTTP 요청을 수행합니다. --noproxy '*'는 이번 요청에서 모든 프록시 사용을 제외하며, 따옴표는 별표를 문자 그대로 유지합니다. -f는 HTTP 오류를 실패로 처리하고, -s는 진행 표시를 숨기며, -S는 오류 출력을 유지합니다. --max-time 5는 요청을 5초로 제한합니다.
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Willow Commons와 old location을 포함한 HTML이 나와야 합니다. 터미널은 소스 텍스트를 보여 주고, 브라우저는 같은 페이지를 렌더링합니다. 이제 실제 텍스트 리소스를 다운로드하세요. -o programme.txt는 이 클라이언트의 현재 디렉터리에 응답을 저장합니다.
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat은 저장된 파일을 출력합니다.
cat programme.txt
세 모임 전체, 계단 없는 출입구 정보, Service location: old가 있어야 합니다. 파일이 존재하거나 HTTP 상태가 성공이라는 사실만으로는 내용이 올바름을 증명하지 못합니다.
curl이 Could not resolve host를 보고하면 이름 철자를 확인하세요. Failed to connect는 HTTP 연결이 만들어지지 않았다는 뜻입니다. 이는 서버가 응답했지만 경로가 없는 HTTP 404와 다릅니다. 오타를 고친 다음 표시된 URL로 다시 시도하세요. 플랫폼 DNS, /etc/hosts, 과정 리졸버 파일은 변경하지 마세요. 다른 터미널을 열었다면 실제 Warm Client 탭을 사용하고, 저장하기 전에 cd /home/labex/project/site-move/warm을 실행하세요. 파일과 터미널 작업 디렉터리는 해당 클라이언트에 속하며, 브라우저 다운로드는 브라우저 쪽에 속합니다.
권한 서버와 캐시 비교하기
이 단계에서는 원본 레코드와 임시 캐시 사본을 구분합니다. Warm Client에 머무르세요. 권한 DNS 서버는 community.test를 관리하며 주소는 10.94.0.2입니다. 클라이언트의 캐싱 리졸버는 이 클라이언트 내부의 루프백 주소인 127.0.0.1에서 수신합니다. 다른 클라이언트는 별도의 리졸버와 캐시를 가집니다.
dig는 DNS에 질문합니다. @10.94.0.2는 서버를 명시적으로 선택합니다. A는 IPv4 주소를 요청합니다. +noall은 dig의 일반적인 섹션을 숨기고, +answer는 응답 행을 보여 줍니다.
dig @10.94.0.2 site.community.test A +noall +answer
다음과 같은 형태의 행이 나와야 합니다.
site.community.test. 120 IN A 10.94.0.10
열은 이름, TTL, 클래스, 유형, 주소 순서입니다. TTL, 즉 수명은 응답이 캐시에 남아 있을 수 있는 초 단위 시간입니다. IN은 Internet 클래스입니다. 끝의 점은 완전한 DNS 이름을 뜻합니다. 공백과 탭은 다를 수 있습니다.
이번에는 과정 클라이언트의 리졸버에 물어보세요.
dig @127.0.0.1 site.community.test A +noall +answer
주소는 여전히 10.94.0.10이어야 하지만, 앞선 요청이 캐시를 채웠으므로 TTL은 더 작을 수 있습니다. sleep 5는 DNS를 바꾸지 않고 실제로 5초 기다립니다.
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
보통 남은 TTL이 줄어듭니다. 이전 사본이 만료되면 리졸버가 권한 서버에 다시 질문하고 TTL은 120에 가까운 값으로 되돌아갑니다. 이 실습을 읽는 데 그 시간이 모두 걸릴 수도 있습니다. 이는 캐시 고장이 아니라 정상적인 만료입니다. 환경 준비 직후의 특정 관찰 시간을 잡을 필요는 없습니다.
다가올 편집에는 별도의 이름을 사용합니다. 같은 기존 백엔드를 가리키지만 커뮤니티의 정식 사이트 이름은 아닙니다.
dig @127.0.0.1 practice.community.test A +noall +answer
이름, 주소, 남은 TTL을 살펴보세요. 조회가 성공했다고 웹사이트에 도달할 수 있다는 뜻은 아닙니다. 1단계에서는 별도의 HTTP 요청을 했습니다. 이 단계의 검사를 실행하고 다음 단계를 읽은 뒤, 짧은 변경 및 비교 순서를 시작하세요.
연습용 레코드를 바꾸고 캐시 사본 만료 기다리기
이 단계에서는 작은 레코드 변경을 검증하고 권한 서버에 로드한 뒤, TTL을 낮춰도 이미 캐시된 사본의 수명이 짧아지지 않는 이유를 확인합니다. 변경할 수 있는 것은 practice와 community.zone의 필요한 SOA 일련번호뿐입니다. 정식 site, keep, 네임서버와 두 웹사이트는 그대로 유지하세요.
먼저 아래 편집 설명을 읽으세요. 그런 다음 Warm Client에서 탭을 바꾸기 직전에 연습용 이름을 다시 조회합니다.
dig @127.0.0.1 practice.community.test A +noall +answer
몇 초만 남았다면 그 시간이 끝나기를 기다린 뒤, 권한 서버가 아직 원래 레코드를 유지할 때 다시 조회하세요. 실제 DNS 요청으로 관찰 시간을 새로 얻는 것이며 캐시를 비우는 것이 아닙니다. 새 사본은 최대 120초 유지됩니다. 자기 속도로 진행하고 시간을 놓쳤다면 아래 복구 설명을 사용하세요.
DNS Desk로 전환하세요. 디렉터리는 /home/labex/project/site-move입니다. 파일을 읽습니다.
cat community.zone
존은 DNS의 일부에 대해 권한 서버가 보유하는 데이터 집합입니다. $TTL 120은 기본 수명을 제공합니다. practice 120 IN A 10.94.0.10은 연습용 이름의 수명과 주소를 명시합니다. SOA, Start of Authority에는 일련번호라는 버전 번호가 들어 있습니다. 변경을 게시할 때 이 번호를 올리고 나머지 SOA 값은 유지하세요. DNS 수명과 SOA 타이머는 목적이 다릅니다. 여기서 @는 존의 시작점인 community.test.를 뜻합니다. NS는 권한 서버를 지정하고, ns의 A 레코드는 그 서버 주소를 제공합니다. 괄호는 SOA 필드를 하나의 레코드로 묶습니다. 기존 갱신, 재시도, 만료, 부정 응답 캐시 값은 존 관리용 설정이므로 바꾸지 마세요. 연습용 A 레코드의 TTL과는 다릅니다.
다음 히어 도큐먼트는 작은 존 전체를 기록합니다. >는 파일을 덮어씁니다. 따옴표로 감싼 'ZONE'은 $TTL을 셸 변수로 확장하지 않고 문자 그대로 유지합니다. 마지막 ZONE은 줄의 맨 앞에서 시작해야 합니다. 블록 전체를 복사하세요.
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
연습용 주소와 수명, 일련번호만 바뀌었습니다. named-checkzone은 저장한 존 전체를 검증하지만 로드하지 않습니다. 첫 번째 인수는 존 이름, 두 번째는 파일입니다.
named-checkzone community.test community.zone
loaded serial 2 다음에 OK가 나와야 합니다. 이는 파일 검증 결과이지, 실행 중인 권한 서버가 로드했다는 증거가 아닙니다. 구문 검사가 실패하면 파일을 읽고 전체 블록을 복원한 뒤 다시 확인하세요. 저장한 파일이 잘못되어도 유효한 다시 로드가 이루어질 때까지 이전의 실행 중인 존은 계속 사용 가능합니다.
sudo는 이 하나의 관리 명령을 실행합니다. 제공된 범위 제한 도구는 과정 권한 서버 안에서 BIND의 실제 rndc reload community.test를 호출하며, 어느 캐시도 재시작하지 않습니다.
sudo /opt/labex/site-move/reload-zone
zone reload queued가 나와야 합니다. 실행 중인 권한 서버에 조회해 실제 로드된 데이터를 확인합니다. 작업대 자체에는 과정의 기본 리졸버가 없으므로 이 진단은 권한 서버의 네트워크 네임스페이스에 명시적으로 들어갑니다. ip netns exec site-authority는 그 과정 네트워크 안에서 바로 뒤의 명령만 실행합니다.
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
45 IN A 10.94.0.20이 나와야 합니다. Warm Client로 전환해 캐시를 조회합니다.
dig @127.0.0.1 practice.community.test A +noall +answer
원래 수명이 남아 있는 동안에는 45초보다 많이 남았더라도 계속 10.94.0.10을 반환할 수 있습니다. 새 45초 TTL은 새 사본에 적용되며 기존 캐시 응답을 다시 쓰지 않습니다. 클라이언트가 정상적으로 서로 다른 결과를 받는 동안에도 두 백엔드는 계속 작동합니다.
방금 관찰한 남은 TTL에 1초를 더해 기다린 다음 다시 조회하세요. 예를 들어 37초가 표시됐다면 그 사본에는 sleep 38이면 충분합니다. 다음 보수적인 대기는 정확한 값을 적어 두지 않았더라도 이 실습의 원래 최대 120초 전체를 포함합니다.
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
이제 10.94.0.20과 45 이하의 남은 TTL이 나와야 합니다. 실제 행을 읽으세요. 타이머가 끝났다는 사실만으로는 아무것도 증명하지 못합니다. 같은 클라이언트에서 이름을 사용해 HTTP 요청을 수행합니다.
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
완전한 행사 안내와 Service location: new가 나와야 합니다. 정식 site.community.test는 여전히 기존 위치를 제공합니다.
차이를 놓쳤다면: 완료된 결과는 여전히 유효합니다. 관찰을 반복하려면 practice만 사용하세요. DNS Desk에서 해당 행을 practice 120 IN A 10.94.0.10으로 되돌리고 nano community.zone으로 현재 SOA 일련번호를 올립니다. nano는 텍스트 편집기입니다. 화살표로 이동해 그 행과 일련번호만 바꾸고, Ctrl+O, Enter로 저장한 뒤 Ctrl+X로 종료합니다. 위와 같은 명령으로 검증하고 다시 로드하세요. 연습 클라이언트에서 현재 관찰되는 TTL이 자연 만료되기를 기다리고, 조회해 최대 120초의 기존 주소를 얻습니다. 그다음 practice만 새 주소와 45초로 다시 바꾸고, 더 큰 일련번호로 검증하고 다시 로드한 뒤 즉시 비교합니다. 자연 만료와 새 사이트에 대한 실제 요청으로 마무리하세요. 관찰 시간을 반복하기 위해 정식 사이트를 초기화하거나, 리졸버를 재시작하거나, 웹사이트 내용을 교체하지 마세요.
경로를 잘못 입력했다면 DNS Desk에서 pwd와 cd /home/labex/project/site-move를 사용한 뒤 파일을 다시 읽으세요. 구문 오류와 잘못된 내용은 다른 문제입니다. 파일을 검증하고, 실행 중인 권한 서버를 확인하고, 캐시를 확인한 뒤 HTTP를 요청하세요. 연습 클라이언트가 새 주소를 확인하면 최종 검사를 실행합니다.
요약
이름으로 작동하는 사이트를 사용하고, 완전한 행사 안내를 저장했으며, 권한 데이터와 캐시 DNS 응답, HTTP 콘텐츠를 구분했습니다. 범위가 제한된 연습용 변경을 검증하고 TTL을 낮춰도 기존 캐시 사본의 수명은 줄어들지 않음을 확인했습니다. 정식 커뮤니티 사이트와 기존 백엔드는 계속 이용 가능합니다. 다음 단원에서는 이 지식을 단계적인 주소 이전에 적용합니다.
