소개
Willow Commons는 웹사이트를 새 서버 주소로 옮기려 합니다. 커뮤니티는 계속 site.community.test를 사용해야 하며, 이전 중에도 원래 위치를 사용할 수 있어야 합니다. 두 백엔드에는 이미 각각의 정상 행사 안내가 들어 있습니다. 여러분의 작업은 콘텐츠 배포가 아니라 DNS 이전입니다.
먼저 클라이언트가 사용하는 주소 확인하기를 완료하세요. 이 독립 환경은 정식 이름이 기존 주소를 가리키는 상태에서 다시 시작하며, 권한 서버, 별도의 캐싱 리졸버, 준비된 기존 및 새 HTTP 서비스를 제공합니다. 이전 VM을 재사용하지 않습니다. TTL을 준비하고 주소를 바꾸며 실제 클라이언트와 완전한 내용을 확인합니다. 읽기와 일반적인 실수 처리를 포함해 약 50분을 예상하세요. 이는 작성자의 추정입니다.
이는 통제된 로컬 DNS 연습입니다. 전 세계 전파, 무중단, 공개 등록기관 이전을 보장하지 않으며, 기존 서버를 즉시 삭제해도 된다는 뜻도 아닙니다.
전환 시간 준비하기
이 단계에서는 정식 레코드의 TTL을 줄이기 전에 정상 서비스와 새 백엔드를 확인합니다. Community Preview에서 시작해 Warm Client를 선택하고 old location 표시가 있는 기존 Willow Commons 페이지를 읽으세요. 주소를 바꾸기 전에는 Fresh Client를 사용하지 마세요. 별도의 해당 리졸버는 이 사이트를 아직 조회하지 않았습니다.
Warm Client로 전환하세요. 명령과 curl 옵션은 첫 단원과 같습니다. 먼저 기존 서비스를 이름으로 요청합니다.
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Service location: old의 완전한 행사 안내가 나와야 합니다. 이어서 같은 경로와 포트를 사용해 준비된 새 백엔드를 주소로 확인합니다.
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
같은 세 모임과 출입구 정보가 Service location: new와 함께 나와야 합니다. 이 직접 준비 확인은 의도적으로 DNS를 우회하므로, 이름으로 접근하는 클라이언트가 이전했다는 증거는 아닙니다. 두 웹사이트는 변경하지 마세요.
Warm Client의 현재 사본을 조회합니다.
dig @127.0.0.1 site.community.test A +noall +answer
기존 주소와 120 이하의 TTL이 나와야 합니다. 준비 시 캐시된 사본이 읽는 동안 만료됐다면 이 실제 조회가 여전히 유효한 기존 레코드의 사본을 다시 가져옵니다. 실습을 연 순간부터 시작되는 마감은 없습니다.
/home/labex/project/site-move에 있는 DNS Desk로 전환해 레코드 파일과 준비된 백엔드 계획을 읽습니다.
cat backends.tsv
cat community.zone
이전에서 바꿀 수 있는 것은 site의 A 주소와 TTL, 필요한 SOA 일련번호뿐입니다. practice는 선택적인 반복 관찰용으로 남겨 둡니다. keep, 네임서버, 모든 웹사이트 바이트를 보존해야 합니다. 준비된 기존 레코드에는 실제 120초 TTL이 있습니다. 연습은 의도적으로 초 단위를 사용하며, 운영 환경의 하루짜리 캐시 수명이 2분 안에 사라진다는 주장이 아닙니다.
주소를 바꾸기 전에 정식 레코드의 TTL만 낮추세요. 다음 완전한 리터럴 히어 도큐먼트는 첫 단원에서 배운 파일 쓰기 구문을 사용합니다.
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 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
loaded serial 2와 OK가 나와야 합니다. 다시 로드하기 전에 모든 구문 문제를 고치세요.
sudo /opt/labex/site-move/reload-zone
저장한 파일만이 아니라 실행 중인 권한 서버를 확인합니다.
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
45 IN A 10.94.0.10이 나와야 합니다. 권한 응답은 아직 기존 백엔드를 가리킵니다. Warm Client로 전환합니다.
dig @127.0.0.1 site.community.test A +noall +answer
기존 캐시 사본은 이전의 남은 수명을 유지합니다. 남은 TTL이 40이라고 새 45초 정책을 얻었다고 판단하지 마세요. 기존 120초 사본도 40초만 남을 수 있습니다.
관찰한 기존 사본이 만료되기를 기다린 다음 다시 조회합니다. 마지막으로 표시된 남은 초에 1초를 더해 기다려도 됩니다. 다음 완전한 보수적 명령은 원래 최대 120초를 포함합니다.
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
새로 얻은 45초 안팎의 TTL과 기존 주소가 나와야 합니다. 마지막 DNS 요청이 중요합니다. 만료는 기존 사본을 없애지만 대체 사본을 스스로 가져오지는 않습니다. 네이티브 DNS 교환은 수명이 줄어든 기존 주소 응답을 기록합니다. 검사는 자체 탐색 전에 그 기존 교환을 읽으며, 이 준비 단계를 대신하지 않습니다.
응답이 없거나 다른 주소라면 진행하기 전에 권한 서버와 클라이언트의 정확한 출력을 다시 읽으세요. DNS Desk에서 파일 오류를 고치고 검증한 뒤 다시 로드하고, Warm Client에서 이름 조회를 재시도합니다. 리졸버를 재시작하거나 비우지 마세요. 짧은 수명의 기존 주소를 실제로 얻은 다음에만 이 단계의 검사를 실행하세요.
주소를 바꾸고 두 클라이언트 비교하기
이 단계에서는 정식 이름을 이전하고 독립적인 클라이언트를 비교합니다. 짧은 순서를 시작하기 전에 이 단계를 읽으세요. 다음 warm 조회는 남은 비교 시간을 보여 주며, 캐시 적중은 TTL을 다시 시작하지 않습니다. 자연 만료 후 얻은 새 사본만 환경 준비와 무관하게 새로운 45초 수명을 시작합니다. 편집이 느리면 보이는 차이를 놓칠 수 있지만 이전은 여전히 유효하며, 아래의 별도 연습용 이름 복구 방법으로 관찰을 반복할 수 있습니다.
Warm Client에서 현재 상태를 다시 확인합니다.
dig @127.0.0.1 site.community.test A +noall +answer
남은 TTL이 거의 끝났다면 권한 서버가 아직 기존 주소를 반환하는 동안 만료를 기다리고, 편집 전에 다시 조회합니다. 그다음 DNS Desk로 전환하세요. 정식 A 주소를 바꾸고, 45초 TTL은 유지하며, 일련번호를 올립니다.
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
실행 중인 권한 서버는 이제 45 IN A 10.94.0.20을 반환해야 합니다. 여전히 기존 주소라면 저장된 파일과 로드된 데이터가 다릅니다. 클라이언트 캐시를 해석하기 전에 구문과 다시 로드 결과를 확인하세요.
Warm Client로 전환합니다.
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
남은 캐시 수명 동안에는 기존 주소를 사용해 Service location: old를 반환할 수 있으며 이는 정상입니다. 자체 리졸버를 사용하고 /home/labex/project/site-move/fresh에서 시작하는 Fresh Client로 전환합니다.
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
새 주소와 완전한 Service location: new 행사 안내가 나와야 합니다. DNS 전환 중에는 두 클라이언트가 같은 이름을 쓰면서도 서로 다른 유효한 백엔드에 도달할 수 있습니다. 이들은 하나의 VM 안에 있는 독립적인 Linux 클라이언트 네임스페이스와 캐시 프로세스이지, 두 물리 장치나 독립 VM이 아닙니다.
둘 다 이미 new를 표시한다면: 비교 전에 warm 사본이 자연 만료된 것입니다. 정식 이전을 계속하세요. 통과하려고 스크린샷이나 과거의 중첩 구간을 남길 필요는 없습니다. 이전을 되돌리지 않고 현상을 반복하려면 첫 단원에서 배운 practice.community.test를 사용하세요. DNS Desk에서 site는 새 주소로 유지하고, practice만 기존 주소와 120초로 설정하며, nano community.zone으로 현재 일련번호를 올립니다(Ctrl+O, Enter, Ctrl+X). 검증하고 다시 로드하세요. Warm Client에서 현재 연습용 사본의 만료를 기다린 뒤 practice를 조회해 새 관찰 시간을 시작합니다. practice만 새 주소와 45초로 바꾸고 더 큰 일련번호로 검증과 다시 로드를 수행한 다음, 두 클라이언트에서 practice를 비교하세요. 정식 site 레코드는 그동안 계속 이전된 상태로 유지됩니다. 연습 관찰은 자연 만료로 마무리하고, 캐시를 비우거나 사이트 내용을 교체하지 마세요.
TTL 준비를 끝내기 전에 정식 주소를 바꿨다면 배운 레코드 편집 방식으로 site만 기존 주소와 45초로 되돌리고 더 큰 일련번호를 사용해 검증하고 다시 로드합니다. Warm Client의 현재 응답이 만료되기를 기다리세요. 짧은 TTL의 기존 주소를 요청한 뒤, 더 큰 일련번호로 다시 전환합니다. 원래의 두 백엔드가 모두 사용 가능하므로 이 범위 제한 DNS 롤백은 서비스 초기화나 작업 삭제 없이 순서를 복구합니다. 최종 목표는 여전히 새 정식 주소입니다. 실행 중인 권한 서버가 바뀐 것을 확인한 다음 이 단계의 검사를 실행하세요.
DNS를 통해 새 접속 대상 확인하기
이 단계에서는 통제된 클라이언트가 새 내용에 도달하고 기존 서비스도 사용 가능함을 증명합니다. Warm Client에서 시작하세요. 허용된 정책에서 이전 시 원래 사본은 최대 60초 유지되며, 예시 순서는 45초를 사용합니다. 남은 TTL을 확인합니다.
dig @127.0.0.1 site.community.test A +noall +answer
아직 기존 주소라면 남은 초에 1초를 더해 기다리고 다시 조회합니다. 다음 완전한 보수적 대기는 허용된 짧은 수명의 최대값을 포함합니다.
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
10.94.0.20과, 예시 정책에서 45 이하의 남은 TTL이 나와야 합니다. 주소가 맞는 것만으로는 부족합니다. 그 이름으로 홈페이지를 요청하고 완전한 행사 안내를 저장합니다.
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
실제 new location 홈페이지와, 세 모임 및 출입구 정보를 모두 포함한 Service location: new 행사 안내가 나와야 합니다. DNS는 맞지만 내용이 틀리다면 실제 백엔드 경로와 주소를 조사하세요. 기존 웹사이트를 편집해 새 사이트처럼 보이게 만드는 것은 범위 밖입니다.
Fresh Client로 전환해 같은 완전한 리소스를 독립적으로 저장합니다.
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
같은 새 위치 내용이 나와야 합니다. Community Preview로 전환하고 필요하면 브라우저 Back으로 선택 페이지에 돌아가 각 클라이언트를 선택한 뒤 실제 페이지를 새로 고칩니다. 이제 둘 다 new location을 보여 줍니다. 각 화면에서 Download the programme을 사용해 전체 텍스트를 여세요. 이 브라우저 요청은 브라우저 컴퓨터의 DNS와 별개로 선택한 과정 클라이언트를 사용합니다.
상단 부근의 new location 표시와 세 모임 아래의 원래 행사 안내 링크를 확인하세요. 각 클라이언트는 이 실제 새 백엔드 페이지를 표시해야 합니다.
Warm Client로 돌아가 보존 요구사항을 확인합니다. 기존 백엔드를 직접 요청합니다.
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
원래 기존 위치의 행사 안내가 나와야 합니다. 권한 서버에서 무관한 이름을 조회합니다.
dig @10.94.0.2 keep.community.test A +noall +answer
변경되지 않은 120 IN A 10.94.0.10이 나와야 합니다. 기존 서비스는 여전히 이번 전환 계약의 일부입니다. 두 클라이언트가 이전했다고 중지하지 마세요. 이 관찰은 현실의 모든 클라이언트가 업데이트되었음을 뜻하지 않습니다.
저장 파일에 이전 위치의 내용이 있다면 실제 클라이언트 DNS 조회가 바뀐 후 올바른 클라이언트 탭에서 같은 다운로드 명령을 반복하세요. 경로가 잘못됐다면 pwd와 cd /home/labex/project/site-move/warm, 또는 해당하는 fresh 디렉터리로 복구합니다. 최종 검사는 자체 요청 전에 기존 DNS 및 다시 로드 증거를 읽습니다. 반복 채점은 캐시를 비우거나 권한 서버를 다시 로드하지 않지만, 일반적인 읽기는 네이티브 로그를 추가할 수 있습니다.
요약
새 백엔드를 확인하고, 기존 주소가 여전히 권한 응답인 동안 TTL을 낮춘 뒤, 실제 클라이언트가 해당 정책을 가져오도록 했습니다. 그다음 주소를 바꾸고 독립적인 클라이언트를 비교했으며, 자연 만료 후 새 사이트의 완전한 내용을 확인했습니다. 원래 이름, 기존 백엔드, 무관한 레코드는 계속 이용할 수 있습니다. 이는 통제된 클라이언트의 관찰이며 전 세계 DNS 전파 보장은 아닙니다.
