DNS 레코드를 바꿨는데 안 바뀝니다

레코드를 고치고 저장하고 새로고침했는데 여전히 예전 사이트가 뜹니다. 그런데 동료는 잘 된다고 합니다. 고장 난 게 아닙니다. 캐시를 보고 계신 거고, 그게 얼마나 유지되는지에는 “48시간 기다리세요”보다 훨씬 구체적인 규칙이 있습니다.

“DNS 전파”라는 건 없습니다

이 표현이 널리 쓰이는데 오해를 부릅니다. 변경 사항이 파도처럼 퍼져나가고 그게 도착하기를 기다려야 한다는 인상을 주거든요.

실제로는 그렇지 않습니다. 저장하는 순간 권한 네임서버에는 이미 반영돼 있습니다. 대기열도 없고 전송 중인 것도 없습니다.

지연의 진짜 원인은 아무도 그 네임서버에 안 물어본다는 것입니다. 전 세계의 리졸버들이 이미 물어봤고, 답을 받았고, “이만큼은 보관해도 된다”는 허락까지 받아뒀습니다. 그 허락이 만료될 때까지는 나한테 연락도 안 하고 기억에서 답합니다.

그래서 질문은 “전파됐나”가 아닙니다. **“내가 지금 누구의 캐시를 보고 있고, 그게 언제 만료되나”**입니다.

TTL은 그 허락증입니다

모든 DNS 레코드에는 TTL(초 단위)이 붙습니다. 리졸버가 이 답을 얼마나 재사용해도 되는지를 레코드 스스로 선언하는 값입니다.

example.net.   3600   IN   A   203.0.113.10

3600은 한 시간입니다. 50분 전에 이 레코드를 받아간 리졸버는, 내가 뭘 바꾸든 앞으로 10분 더 203.0.113.10을 계속 답합니다.

여기서 직관과 어긋나는 핵심: 지금 변경을 지배하는 건 새 TTL이 아니라 예전 TTL입니다. 리졸버들은 이전 레코드를 이전 TTL 조건으로 캐싱했습니다. 지금 TTL을 낮춰봐야, 각자 갖고 있는 사본이 만료된 뒤에 물어보는 리졸버부터 적용됩니다.

이래서 “이전(migration) 전에 TTL을 미리 낮추라”고 하는 겁니다. 하루 전에 300으로 내려서 긴 예전 TTL이 다 빠지게 두면, 실제 전환은 하루가 아니라 5분 만에 끝납니다.

동료는 되는데 나는 안 되는 이유

리졸버가 다르고, 캐시가 다르고, 만료 시점이 다릅니다. 동료의 리졸버는 사본이 아예 없었거나 이미 만료됐을 뿐입니다.

낡은 답을 들고 있을 수 있는 캐시는 세 군데고, 순서대로 지워야 합니다.

1. 브라우저. Chrome과 Firefox는 OS와 별개로 자체 DNS 캐시를 씁니다. 강력 새로고침으로는 안 지워집니다. 시크릿 창이나 다른 브라우저로 테스트해서 변수에서 빼세요.

2. 운영체제. macOS는 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, Windows는 ipconfig /flushdns, systemd를 쓰는 대부분의 Linux는 sudo resolvectl flush-caches.

3. 실제로 쓰는 리졸버. ISP의 것이거나 공유기, 또는 1.1.1.1 같은 공용 리졸버입니다. 이건 지울 수 없습니다. 예전 TTL이 정한 때가 되어야 만료됩니다. 기다리게 만드는 건 바로 이겁니다.

실제로 뭐가 응답되는지 확인하기

브라우저로 테스트하지 마세요. 브라우저는 자체 캐시, 자체 DoH 설정, HTTP 캐시까지 얹기 때문에 낡은 페이지가 떠도 DNS에 대해 알려주는 게 없습니다.

리졸버에 직접 묻고 TTL이 줄어드는 걸 보세요:

dig example.net A

몇 초 간격으로 두 번 돌려서 TTL 값을 비교하세요. 줄어들고 있으면 캐시에서 주는 중이고 그 숫자가 남은 초입니다. 원래 값으로 되돌아왔으면 방금 만료돼서 다시 받아온 것입니다.

캐시를 완전히 건너뛰고 내 네임서버가 진짜 뭘 갖고 있는지 보려면:

dig @ns1.yourprovider.example example.net A

이게 새 값을 주는데 공용 리졸버가 예전 값을 주면, 변경은 제대로 됐고 그냥 기다리면 됩니다. 이게 예전 값을 준다면 생각한 곳에 저장이 안 된 겁니다. 도메인이 실제로 쓰는 존을 고쳤는지 확인하세요.

DNS 조회 도구는 내 컴퓨터가 아니라 서버에서 같은 질의를 던지므로, 로컬이 의심될 때 두 번째 의견으로 쓸 만합니다. 더 나은 건 전파 확인 도구입니다. 서로 다른 지역의 리졸버 네 곳에 동시에 물어보므로, “한 캐시가 뭐라고 하는지”가 아니라 “어느 캐시가 낡았는지”를 답해줍니다.

정말 흔한 실수들

대개는 기다리는 게 답이지만 항상 그렇진 않습니다. 캐시 탓하기 전에 이것부터 지우세요.

• 네임서버는 다른 곳인데 등록기관에서 레코드를 고침. 네임서버가 DNS 업체를 가리키면 등록기관의 레코드는 아예 무시됩니다. dig example.net NS로 확인하세요.
• 지우는 걸 잊은 예전 레코드. A 레코드가 둘이면 라운드로빈이라 요청의 절반이 옛 서버로 갑니다. 추가와 삭제는 별개의 작업입니다.
• 레코드 종류를 잘못 봄. A를 바꿔도 IPv6로 접속하는 클라이언트는 AAAA를 봅니다.
• 위에 CNAME이 있음. www가 다른 곳을 가리키는 CNAME이면 www의 A 레코드는 참조되지 않습니다.
• 끝점(.) 빠짐. 존 파일에서 example.net을 점 없이 쓰면 존 기준 상대 경로로 해석돼 example.net.example.net이 됩니다.
• VPN. 회사 VPN은 자체 DNS를 강제하고 내부 이름을 다르게 풀어주는 경우가 많습니다. 끊고 다시 해보세요.

실제로 얼마나 기다려야 하나

예전 TTL을 아직 찾을 수 있다면 그 값을 보세요. 저장한 시점부터 그 값이 최대 대기 시간입니다. 예전 TTL이 3600이었으면 한 시간 안에 모두 최신이 됩니다. 86400이었으면 하루고요.

지원 문서에 흔히 나오는 “48시간”은 네임서버 자체를 옮기는 경우를 감안한 여유분입니다. 그건 상위 존에 별도 TTL이 있고 보통 길게 잡혀 있거든요. 네임서버는 그대로 두고 레코드만 바꾸는 일반적인 경우라면 시간 단위가 맞는 기대치입니다.

예전 TTL보다 오래 지났는데도 공용 리졸버가 여전히 옛 답을 준다면, 기다리기를 멈추세요. 캐시가 아니라 레코드가 잘못된 것입니다.