DNS 마이그레이션이 순조롭게 끝났는지 확인하는 방법

DNS 마이그레이션(제공업체 전환, 새 네임서버 구성으로 이동, 대량 레코드 재구성)은 대부분의 인프라 변경보다 위험이 큽니다. 실수가 요란하게 실패하지 않기 때문입니다. 고장 난 레코드는 조용히 확인되지 않거나 엉뚱한 곳으로 확인될 뿐이며, 첫 신호는 알림이 아니라 고객 지원 문의인 경우가 많습니다.

마이그레이션 전

• 현재 제공업체의 기존 레코드를 모두 내보냅니다. 설정한 기억이 있는 것만이 아니라 완전한 존 파일이나 그에 준하는 것이어야 합니다.
• 변경될 레코드의 TTL을 최소한 TTL 한 주기 전에 미리 낮춥니다.
• 모든 항목의 현재 값을 기록해 둡니다. A/AAAA, CNAME, MX, TXT(SPF/DKIM/DMARC 포함), 그리고 사용 중인 드문 레코드 유형까지 포함합니다.

마이그레이션 후

1. 이전된 모든 레코드에 대해 새 권한 네임서버를 직접 질의하고, 각 응답을 마이그레이션 전에 내보낸 자료와 비교합니다.
2. 예전에 둘 중 하나라도 있던 모든 호스트 이름에 대해 A와 AAAA를 각각 독립적으로 확인합니다. 한쪽 주소 체계만 옮기고 다른 쪽을 잊기 쉽습니다.
3. MX와 이를 둘러싼 이메일 인증 레코드를 특별히 검증합니다. DNS 마이그레이션으로 인한 이메일 장애는 유난히 흔하고 유난히 피해가 큽니다.
4. 마이그레이션이 끝났다고 선언하기 전에 둘 이상의 리졸버에서, 가능하면 둘 이상의 네트워크 위치에서 다시 확인합니다.
5. 이전 TTL 기간이 지나도록 기다린 뒤 다시 확인합니다. 컷오버 직후의 깨끗한 결과가 전 세계의 모든 캐시된 리졸버가 따라잡았다는 뜻은 아닙니다.

전체 호스트 이름 목록을 대상으로 컷오버 직후와 이전 TTL 기간이 지난 뒤에 한 번씩 대량 조회를 실행하면, 레코드별 수동 점검이 한 번에 반복 가능한 단일 단계로 바뀌고, 무엇을 언제 검증했는지에 대한 내보낼 수 있는 기록도 남습니다.

이전 환경을 너무 일찍 철거하지 마세요

마이그레이션 후 가장 흔한 후회는 빠뜨린 레코드가 아니라, 새 환경이 가동되는 바로 그날 이전 제공업체의 계정이나 네임서버를 해지하거나 폐기한 일입니다. 전 세계 일부 리졸버는 TTL이 만료될 때까지 이전 설정을 가리키는 캐시된 응답으로 계속 동작하므로, 컷오버 후 최소 이전 TTL 한 주기 동안은 이전 제공업체를 (새로 가리키는 것이 없더라도) 활성 상태로 유지하는 것이 저렴한 보험입니다. 빠른 롤백이 필요해졌을 때 이전 환경이 여전히 응답하고 있다면, 네임서버를 몇 분 만에 되돌리느냐와 압박 속에서 기억에 의존해 존 파일을 재구성하느냐의 차이가 생깁니다.

예행연습은 대부분의 문제를 실제가 되기 전에 잡아 줍니다

새 DNS 제공업체가 허용한다면, 완전히 구성했지만 아직 위임하지는 않은 새 존 전체를 미리 구축하고, 일반적인 위임을 우회해 직접 질의하세요. 테스트 도구가 해당 네임서버를 명시적으로 가리키게 하거나 제공업체의 미리보기 기능을 사용하면 됩니다. 이렇게 하면 마이그레이션 검증이 컷오버 후의 허둥지둥하는 작업에서, 문제가 있어도 사용자에게 전혀 영향이 없는 컷오버 전 점검으로 바뀝니다. 누락되었거나, 잘못 설정되었거나, 단지 의도와 다른 레코드가 실제 리졸버가 한 번도 보기 전에 드러나므로, 컷오버가 이미 실서비스로 진행된 후에 실수를 발견하는 것보다 훨씬 부담이 적습니다.