도메인 이전 날 DNS TTL보다 먼저 확인한 네 가지

“전파 중입니다”라는 말로 설명되지 않던 문제

서비스 도메인을 옮긴 날 A 레코드를 바꾸고 TTL이 지나기만 기다렸다. 새 도메인은 열렸지만 로그인 뒤 예전 주소로 튕기고 문의 메일도 들어오지 않았다. DNS 전파 문제라고 넘길 뻔했지만 서로 다른 설정을 한데 묶어 생각한 것이 원인이었다.

TTL은 캐시 갱신 시간일 뿐이다. 이전 완료는 HTTP, TLS, 메일, 애플리케이션 설정까지 따로 확인해야 한다.

1. 새 이름이 올바른 원본을 가리키는지

공개 리졸버와 HTTP 응답을 함께 확인했다.

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8
curl -I https://example.com

IP가 맞아도 Location이 옛 도메인을 가리키면 앱이나 프록시 문제다. 이때 DNS를 더 수정하면 원인을 늘릴 수 있다.

2. 인증서 이름이 맞는지

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

*.example.com이 루트 example.com까지 자동으로 포함한다고 한동안 헷갈렸다. 두 이름은 별도로 확인해야 한다.

3. 리다이렉트와 쿠키를 분리해서 봤다

옛 주소는 경로와 쿼리를 보존해 한 곳으로 보낸다.

server {
  server_name old-example.com www.old-example.com;
  return 301 https://example.com$request_uri;
}

리다이렉트가 맞는데 로그인만 풀리면 DNS가 아니라 쿠키 Domain 또는 HTTPS 설정을 의심한다.

4. 웹 밖 레코드도 목록으로 확인했다

MX, SPF, DKIM, DMARC와 외부 결제 웹훅, OAuth 콜백 URL을 점검했다. 웹 페이지가 열린다고 메일까지 옮겨진 것은 아니다.

이전 완료 판정

• 여러 리졸버에서 새 레코드가 보이는가?
• 인증서 이름이 새 도메인과 일치하는가?
• 옛 주소의 경로와 쿼리가 보존되는가?
• 로그인, 메일 수신, 웹훅을 실제로 시험했는가?

DNS 변경은 이전 작업의 시작일 뿐이었다. TTL을 기다리는 동안 이 항목을 확인하면 전파가 끝난 뒤 발견하는 장애를 줄일 수 있다.