네임서버 변경 적용 확인하는 법

Problem

등록기관에서 도메인의 네임서버를 바꿨습니다 — DNS 제공자를 갈아탔거나, 도메인을 호스트의 네임서버로 돌렸습니다. 그리고 지금 사이트를 새로고침하며 이게 됐는지 안 됐는지 가늠하는 중입니다. 사무실에선 새 서버가 뜹니다. 휴대폰 셀룰러에선 아직 옛 서버입니다. 지방의 동료는 인증서 오류를 봅니다. 어느 것도 끝난 것처럼 보이지 않고, 이게 정상적인 롤아웃인지 지금 당장 고쳐야 할 실수를 보고 있는 건지 판단이 안 섭니다.

헷갈리는 이유는 네임서버 변경이 됐거나 안 됐거나 하는 하나의 사건이 아니기 때문입니다. 서로 다른 두 시계 위에서 두 가지가 각각 갱신되는 것이고, 지금 어느 쪽을 기다리는지 아는 것이 전부입니다.

시계는 하나가 아니라 둘

네임서버를 바꾸면 실제로 일어나야 하는 일은 이렇습니다:

1. 부모 존에서 위임이 갱신된다. 도메인의 네임서버는 내 존이 아니라 한 단계 위, TLD 레지스트리의 존(.com·.net·.kr 서버)에 저장됩니다. 이것이 위임(delegation)입니다 — 부모가 아래를 가리키며 “이 도메인의 권위 서버는 이것들이다”라고 말하는 것. 등록기관에서 새 네임서버를 저장하면 등록대행사가 레지스트리에 알리고, 레지스트리가 그 포인터를 다시 씁니다. 밀어 넣히면 이 부분은 빠릅니다 — 보통 몇 분에서 한두 시간.

2. 재귀 리졸버가 옛 네임서버를 놓아준다. 최근에 도메인을 조회한 리졸버는 어느 네임서버에 물어야 하는지를 캐시했고, 캐시한 사본이 만료될 때까지 계속 그것들에게 묻습니다. 그 수명이 부모 존에 있는 NS 레코드의 TTL이며, .com/.net은 보통 172800초 — 48시간입니다. 변경 한 시간 전에 옛 위임을 캐시한 리졸버는 앞으로 최대 이틀 더 옛 네임서버를 씁니다.

첫 시계는 “변경이 등록됐는가”입니다. 둘째는 “다들 알아챘는가”입니다. 사람들이 네임서버 변경이 “최대 48시간 걸린다”고 할 때 그건 둘째 시계 얘기이고 — 실제로 잘못되는 건 거의 그게 아닙니다. 중요한 건 첫째를 확인하는 것입니다.

자기 리졸버 말고 부모를 확인하라

가장 유용한 한 수는 내 리졸버에게 네임서버가 뭐냐고 묻기를 그만두고(캐시된 답을 붙들고 있어 아무것도 못 알려줄 수 있습니다) 두 권위 소스를 확인하는 것입니다:

• 레지스트리가 기록한 위임. RDAP(WHOIS의 구조화된 후계자)는 레지스트리 수준에서 도메인에 현재 등록된 네임서버를 보고합니다. RDAP가 새 네임서버를 보여주면 위임이 성공적으로 등록된 것 — 첫째 시계는 끝났고, 나머지는 캐시가 늙어 가는 것뿐입니다. 몇 시간 뒤에도 옛 것을 보여주면 변경이 안 먹은 것이고, 그건 기다림이 아니라 등록기관에서 쫓아야 할 문제입니다.
• 전 세계 리졸버가 지금 실제로 반환하는 것. 여러 공개 리졸버에 한꺼번에 물으면 롤아웃의 모양이 보입니다: 전부 새 것이면 끝, 섞여 있으면 진행 중, 전부 옛 것이면 아직 이르거나 위임이 안 바뀐 것. 섞여 있는 건 정상이고 저절로 낫습니다. 버그가 아닙니다.

이 두 답을 합치면 정확히 어디에 있는지 알 수 있습니다. 레지스트리 갱신됨 + 리졸버 섞임 = 정상, 기다리세요. 레지스트리 안 바뀜 = 고장, 등록기관으로 돌아가세요.

”고쳤는데 아직도 틀림”의 정체

가장 흔한 함정은 진짜 실수 — 네임서버 호스트명 오타, 잘못된 제공자 — 를 고친 뒤 틀린 답이 완강히 남는 걸 보고 고침이 안 먹었다고 결론짓는 것입니다. 두 가지 캐싱이 이걸 일으킵니다:

• 옛 NS TTL이 아직 돌고 있다. 다른 나라 어느 리졸버에 이미 캐시된 사본은 줄일 수 없습니다. 부모 TTL이 48시간이었다면 지금 한 고침도 나쁜 답이 이미 저장된 곳에서는 그 창을 다 기다려야 합니다.
• 네거티브 캐싱. 리졸버가 도메인이 진짜로 깨져 있을 때 조회해 NXDOMAIN(이름 없음)을 받았다면, RFC 2308에 따라 그 실패도 존의 SOA minimum 필드 기간만큼 캐시합니다. 그래서 위임을 고친 뒤에도 일부 리졸버는 네거티브 캐시가 만료될 때까지 “없음”을 계속 반환합니다. 고침이 무시된 것처럼 보이지만, 옛 실패를 기억하는 것뿐입니다.

판별의 열쇠는 시간에 따른 일관성입니다: 부모가 올바른 네임서버를 보여주고 확인할 때마다 새 답을 반환하는 리졸버 비율이 계속 오른다면 정상입니다. 여러 시간 동안 아무것도 안 움직이고 부모가 여전히 옛 위임을 보여주면 캐싱이 아니라 실제로 뭔가 잘못 설정된 것입니다.

DechoNet으로 진단

• 전파 확인(Propagation Check)은 여러 공개 리졸버에 한꺼번에 물어, 세계의 얼마가 새 네임서버를 집었고 얼마가 아직 옛 것인지를 한 화면에서 보여줍니다. 비율이 움직이는 걸 보세요 — 그게 롤아웃이 일어나는 것입니다.
• RDAP / WHOIS는 레지스트리에 도메인으로 등록된 네임서버를 보여줍니다 — 어떤 리졸버의 캐시와도 무관하게 “위임이 실제로 바뀌었는가”에 대한 권위 있는 답입니다.
• DNS 조회(DNS Lookup)는 리졸버가 새 네임서버로 넘어온 뒤 그 네임서버가 기대하는 A·MX 등 레코드를 반환하는지 확인해, 위임은 맞는데 새 존이 레코드를 빠뜨린 경우를 잡아냅니다.

확인 체크리스트

• RDAP로 레지스트리가 이제 새 네임서버를 나열하는지 확인. 아니라면 변경이 등록 안 된 것 — 전파가 아니라 등록기관 문제입니다.
• 전파 확인을 돌려 섞임 비율을 읽기: 새 답 비중이 오르는 중 = 정상 롤아웃 진행.
• DNS 조회로 새 네임서버가 실제로 레코드(A/AAAA, MX, TXT)를 서빙하는지 확인해, 올바른 위임이 빈 존을 가리키지 않게 합니다.
• 일부 리졸버가 아직 옛 서버를 보여주면 옛 부모 NS TTL(.com/.net은 최대 48시간)을 감안하고 다시 바꾸지 말고 기다리세요.
• 겹치는 창이 완전히 닫힐 때까지 옛 DNS 제공자의 존이 동일하게 응답하도록 두세요 — 변경 저장하자마자 지우지 마세요.

이럴 땐 확대 대응

• 변경 저장 후 여러 시간이 지나도 RDAP가 여전히 옛 네임서버를 보여주면 갱신이 레지스트리에 도달하지 못한 것입니다. 더 기다릴 게 아니라 등록기관에 문의하세요.
• 위임은 맞는데 레코드가 틀리거나 없다면 문제는 새 존 안에 있습니다 — 등록기관과 활성 DNS 호스트가 어긋날 땐 네임서버 불일치 진단, 위임이 아니라 레코드 수준 변경은 DNS 전파 지연을 보세요.
• 국내 호스트에서 도메인 연결의 일부로 바꾸는 중이라면, 카페24 도메인 연결 안 됨이 그 관리판 필드로 같은 3층 점검을 안내합니다.