DNS 변경이 적용되지 않을 때 해야 할 일

DNS 변경이 적용되지 않는 것처럼 보이는 현상은 일상적인 인프라 작업에서 가장 흔한 불만 중 하나입니다. 기반 시스템(레코드별 만료 시간이 있는 분산 캐시)이 일부러 찾아보기 전까지는 보이지 않기 때문입니다.

고장 났다고 단정하기 전에 확인할 것

1. 권한 서버 쪽에 변경이 실제로 저장되었는지 확인합니다. 일반 공개 리졸버 대신 도메인의 권한 네임서버를 직접 조회하여, 저장이 조용히 실패했거나 제공업체 내부 인프라에 아직 동기화되지 않은 경우를 가려냅니다.
2. 레코드의 이전 TTL을 확인합니다. 예를 들어 86400초(24시간)로 설정되어 있었다면, 변경 몇 분 전에 이전 응답을 캐시한 리졸버는 최대 하루 동안 다시 묻지 않습니다.
3. 브라우저나 OS 수준의 DNS 캐시를 배제합니다. 이 캐시는 설정된 리졸버보다 더 가까이 있으며 리졸버와 독립적으로 응답을 보관할 수 있습니다.
4. 의도한 레코드를 실제로 변경했는지 확인합니다. 스테이징이나 비운영 DNS 존을 실수로 수정하는 일이 의외로 흔합니다.
5. 한 곳이 아니라 여러 관측 지점에서 확인합니다. 한 리졸버에서 이전 응답이 보인다고 해서 다른 모든 곳에 변경이 전파되었는지는 알 수 없습니다.

덜 알려진 원인: 보조(슬레이브) 네임서버의 지연

대규모 DNS 구성에서는 변경을 실제로 수행하는 주(또는 “마스터”) 네임서버 하나와, 존 전송을 통해 주기적으로 존을 복사해 가는 하나 이상의 보조(“슬레이브”) 네임서버를 함께 운영하는 경우가 많습니다. 전송 일정 설정 오류, 주 서버와 보조 서버 간 네트워크 문제, 또는 단순히 전송 간격이 아직 지나지 않은 이유로 보조 서버가 최신 전송을 받지 못했다면, 주 서버가 완전히 최신이고 모든 리졸버의 TTL 기반 캐시가 만료되었더라도 그 보조 서버에 질의하는 리졸버는 계속 이전 응답을 받습니다. 단순 캐시보다는 드문 원인이지만, 공개 리졸버끼리만 불일치하는 경우뿐 아니라 같은 도메인의 권한 네임서버들끼리 서로 다른 응답을 줄 때는 특히 이 가능성을 확인해 볼 만합니다.

미리 계획하면 대부분 피할 수 있습니다

마이그레이션, 제공업체 전환, 컷오버 같은 계획된 변경에서는 하루 이틀 전에 TTL을 낮춰 두는 것이 가장 효과가 큰 단일 조치입니다. 약간의 추가 쿼리 비용을 치르는 대신, 변경이 최악의 경우 꼬박 하루가 걸리는 대신 몇 분 안에 전파됩니다. TTL을 낮추고, 이전 TTL 기간이 완전히 지나기를 기다린 다음 변경하고, 모든 것이 정상인지 확인한 뒤 TTL을 다시 올리세요.

로컬 캐시가 실제 원인일 때 직접 비우기

권한 네임서버와 확인한 모든 공개 리졸버가 이미 새 응답에 일치하는데 특정 컴퓨터에서만 이전 값이 보인다면, 그 컴퓨터의 로컬 캐시가 남은 용의자입니다.

권한 서버 쪽이 이미 올바른지 확인한 뒤에만 이 명령을 쓰는 것이 좋습니다. 실제 레코드가 아직 갱신되지 않았는데 로컬 캐시를 비우면 같은 이전 응답을 새로 받아 올 뿐이고, 캐시 삭제가 실패한 것과 똑같이 보입니다.