DNS 변경 전 영향도 체크리스트

DNS 레코드 변경은 사이트 접속, 메일 수신, 인증서까지 한꺼번에 영향을 줄 수 있는 민감한 작업입니다. 네임서버(NS)나 MX를 잘못 바꾸면 몇 시간 동안 메일이 유실되거나 사이트가 끊길 수 있습니다. 이 체크리스트는 변경 전 반드시 확인해야 할 항목을 영역별로 점검하고 준비도를 점수로 보여줍니다.

서버 이전, 메일 호스팅 변경, 네임서버 교체, CDN 도입 등 DNS를 건드리는 모든 작업 전에 확인하세요.

왜 TTL을 먼저 낮추나요?

TTL은 리졸버가 레코드를 캐싱하는 시간입니다. 기본값이 크면 변경 후에도 그 시간만큼 옛 정보가 남습니다. 변경 1~2일 전에 300초로 낮춰두면 전파가 빨라지고 문제 시 빠르게 되돌릴 수 있습니다. 안정화 후 다시 올리세요.

안전한 전환 순서

1. 신규 서버/메일을 완전히 구성하고 직접 접속·송수신을 확인합니다.
2. 변경할 레코드의 TTL을 낮춥니다.
3. 트래픽이 적은 시간대에 전환합니다.
4. 전환 직후 사이트·메일·인증서를 즉시 테스트하고, DNS 전파 확인으로 새 값이 퍼지는지 추적합니다.
5. 안정적이면 TTL을 원래대로 복구합니다.

이전 전·후 반드시 점검할 레코드

서버나 네임서버를 옮기기 전에 아래 레코드를 모두 스냅샷으로 남기고, 전환 후 같은 항목을 하나씩 다시 검증하세요. 하나라도 빠지면 사이트는 멀쩡한데 메일만 끊기거나, 인증서 발급만 실패하는 식의 부분 장애가 생깁니다.

실전 예시 — 서버 이전 타임라인

금요일 저녁에 example.com을 새 서버로 옮기는 상황을 단계별로 따라가 봅니다.

• D-2 (수요일): 변경할 A·AAAA·MX의 TTL을 86400(24시간)에서 300(5분)으로 낮춰 전파를 기다립니다. TTL 자체도 전파에 옛 TTL만큼 걸리므로 미리 해야 합니다.
• D-1 (목요일): 현재 존 전체를 스냅샷으로 기록합니다 — A 203.0.113.10, MX 10 mail.example.com, TXT "v=spf1 include:_spf.old.com ~all", NS·CNAME·CAA까지. 문제 시 되돌릴 기준선입니다.
• D-Day 02:00 (저트래픽): 등록기관/DNS 콘솔에서 A를 198.51.100.20으로, 필요하면 MX·SPF·DKIM도 새 호스트 값으로 교체합니다.
• 전환 직후: 새 IP로 사이트 접속, 테스트 메일 송수신, HTTPS 인증서를 즉시 확인합니다. DNS 전파 확인으로 여러 리졸버에 새 값이 퍼졌는지 추적합니다.
• D+1 (안정 후): 모든 항목이 정상이면 TTL을 3600~86400으로 복구해 평상시 캐싱 효율을 되살립니다.

증상 → 원인 → 조치로 정리하면: 사이트만 안 열림 → A/AAAA 누락 또는 옛 캐시 → 새 IP 직접 접속·전파 재확인 / 메일만 끊김 → MX·SPF·DKIM 누락 → 새 호스트 값으로 갱신 / 인증서 발급 실패 → CAA 차단 → 허용 CA 추가.