네임서버·DNS 제공자 확인하는 법

문제

DNS 레코드를 하나 바꿔야 합니다 — 도메인 인증용 TXT를 추가하거나, A 레코드를 새 서버로 돌리거나, 메일 때문에 MX를 고쳐야 합니다. 그런데 아무도 답을 알려주지 않는 질문에 걸립니다: 이걸 대체 어디서 하지? 도메인을 산 등록대행사에 로그인해 DNS 섹션을 찾아 바꾸는데… 아무 일도 안 일어납니다. 아니면 애초에 등록대행사가 맞는 곳인지도 모르겠습니다. 몇 년 전에 누군가 — 본인일 수도, 지금은 없는 개발자일 수도 — 설정해 뒀고, 도메인은 멀쩡히 작동합니다. 그 말은 어딘가의 서버가 응답하고 있다는 뜻입니다. 다만 그게 어느 것인지, 어떻게 들어가는지를 모를 뿐입니다.

이건 사람들이 막히는 가장 흔한 지점 중 하나이고, 서로 가까이 있을 뿐 별개인 세 가지를 하나로 뭉뚱그리는 데서 옵니다.

세 층, 그리고 레코드를 고치는 건 그중 하나뿐

도메인 이름에는 서로 다른 세 가지 역할이 있고, 보통 한두 회사가 나눠 맡습니다. 혼란은 전부 이 셋을 한 덩어리로 취급하는 데서 옵니다:

1. 등록대행사 — 이름을 소유한 곳. 도메인을 산 곳이고 갱신 요금을 청구하는 곳입니다. 등록대행사는 레지스트리에 있는 도메인 레코드를 통제합니다: 만료, 이전, 그리고 결정적으로 도메인이 어느 네임서버로 위임되는지를. 등록대행사는 소유권이지, 꼭 DNS는 아닙니다.

2. 네임서버 — 도메인에 응답하는 곳. “이 도메인의 A 레코드가 뭐냐”고 세상이 물을 때 응답하는 권위 DNS 서버들입니다. 그 목록이 위임(delegation)이고, 한 단계 위 TLD 존에 저장됩니다. “레코드를 어디서 고치나”에서 중요한 층이 바로 이것입니다 — 레코드는 위임이 가리키는 네임서버가 서빙할 때만 효력이 있기 때문입니다.

3. DNS 레코드 — 실제 응답. A, AAAA, CNAME, MX, TXT. 이것들은 네임서버 위에 있는 존 안에 들어 있습니다. 다른 어디서 고치면 아무도 안 읽는 파일에 쓰는 셈입니다.

기본값으로는 등록대행사와 네임서버가 같은 회사입니다 — 호스트에서 도메인을 사면 처음부터 그 호스트의 네임서버를 가리킵니다. 그러나 누군가 도메인을 다른 곳으로 위임하는 순간(가장 흔한 경우: 무료 요금제와 속도를 위해 DNS를 Cloudflare로 옮기는 것), 소유권은 등록대행사에 남고 응답은 새 제공자로 넘어갑니다. 그 뒤로 등록대행사의 DNS 패널은 미끼입니다.

권위 네임서버 찾기

기억으로 추측하지 말고 두 권위 소스를 직접 읽으세요. 둘 다 비밀번호가 필요 없습니다 — 이 정보는 설계상 공개이기 때문입니다.

• NS 레코드가 내 DNS를 누가 호스팅하는지 알려줍니다. 도메인의 네임서버 레코드를 조회하세요. ns1.example-dns.com·ns2.example-dns.com 같은 호스트 이름이 나오는데, 그 호스트 이름이 곧 제공자의 명찰입니다. 자주 보게 될 몇 가지:

  • *.cloudflare.com → Cloudflare
  • ns-cloud-*.googledomains.com → Google Cloud DNS
  • *.awsdns-*.net/.org/.com/.co.uk → Amazon Route 53
  • *.azure-dns.com/.net → Azure DNS
  • *.domaincontrol.com → GoDaddy
  • ns.cafe24.com, ns.gabia.co.kr, *.dnszi.com → 국내 호스트에서 흔함

  그 호스트 이름이 속한 곳이 레코드가 실제로 들어 있는 곳이고, 바꾸려면 로그인해야 하는 곳입니다.

• RDAP(또는 WHOIS)가 등록대행사를 알려줍니다. 구조화된 레지스트리 레코드는 후원 등록대행사 — 갱신하는 곳, 위임을 바꿀 수 있는 곳 — 와 대개 등록된 네임서버까지 보여줍니다. 도메인을 어디서 샀는지조차 잃어버렸다면, 이것으로 찾습니다.

함께 읽으면: 등록대행사는 어느 네임서버가 응답할지를 바꾸는 곳, 네임서버는 레코드를 바꾸는 곳입니다. 평범한 레코드 수정이라면 두 번째가 필요합니다.

“고쳤는데 아무 일도 안 일어남”의 이유

전형적인 함정은 권위가 아닌 곳에서 레코드를 고치는 것이고, 흔한 두 가지 모양은:

• DNS를 다른 곳으로 옮긴 뒤에도 등록대행사에서 레코드를 고침. 등록대행사는 실제로 내 존을 서빙하든 말든 패널에 DNS 편집기를 유지합니다. NS 레코드가 Cloudflare를 가리키면 등록대행사의 A 레코드는 반송 불가 편지입니다 — 실재하고, 저장되고, 완전히 무시됩니다. 단서는 간단합니다: 위임의 네임서버가 지금 편집 중인 패널과 일치하지 않습니다.

• 반대 경우 — 존을 만든 적 없는 제공자로 네임서버를 설정함. 누군가 등록대행사에서 NS를 어떤 DNS 제공자로 바꿨는데 거기에 존이 (또는 빈 존만) 없어서, 권위 서버가 아무것도 없이 또는 NXDOMAIN으로 응답합니다. 여기선 위임은 “맞지만” 목적지에 레코드가 없습니다.

어느 쪽이든 해법의 출발은 같습니다: 권위 네임서버를 찾고, 지금 로그인한 곳이 거기인지 확인하고, 거기서 고치세요. 통합하고 싶다면 — DNS를 등록대행사로 되돌리거나 한 제공자로 몰고 싶다면 — 그건 등록대행사에서의 네임서버 변경이고, 적용되는 데는 시간이 걸립니다(별개 문제입니다, 아래 참고).

DechoNet으로 진단

• DNS 조회는 도메인의 NS 레코드를 권위 체인에서 바로 읽어, 위임에 어떤 네임서버 호스트 이름이 있는지 — 따라서 어느 제공자가 내 DNS를 호스팅하고 레코드를 고치러 어디에 로그인해야 하는지 — 를 정확히 보여줍니다.
• RDAP / WHOIS는 레지스트리 수준의 후원 등록대행사와 등록된 네임서버를 보여줍니다 — “누구와 갱신하나”, “누가 위임을 바꿀 수 있나”에 대한 답으로, 지금 보고 있는 패널과 무관합니다.
• 전파 확인은 찾아낸 네임서버가 실제로 전 세계 리졸버가 쓰는 것인지 확인해, 아직 바뀌는 중인 위임을 보고 섣불리 움직이지 않게 합니다.

점검 체크리스트

• 도메인의 NS 레코드를 DNS 조회로 실행하고 네임서버 호스트 이름을 읽으세요 — 그것이 내 DNS 제공자의 이름입니다.
• 그 호스트 이름의 제공자를 내가 가진 로그인과 맞춰보세요. 등록대행사가 아니라(둘이 같지 않다면) 그 제공자의 DNS 패널이 레코드를 고치는 곳입니다.
• RDAP로 등록대행사(갱신·위임 변경용)와, 등록된 네임서버가 조회 결과와 일치하는지 확인하세요.
• 고치기 전에 지금 들어와 있는 패널이 위임의 네임서버에 속하는지 확인하세요. 일치하지 않으면 엉뚱한 곳에 있는 것입니다.
• 고친 레코드가 적용되지 않으면 위임부터 다시 확인하세요 — 권위 아닌 패널을 고치는 것이 가장 흔한 원인입니다.

이럴 땐 넘기세요

• NS 레코드가 내가 계정 없는 제공자를 가리키면, 도메인은 다른 사람이 설정한 것입니다. 그 제공자의 접근 권한을 쫓으세요 — 등록대행사는 자기가 서빙하지 않는 레코드를 못 고칩니다. 다만 등록대행사는 네임서버를 내가 통제하는 곳으로 되돌릴 수는 있습니다.
• 방금 네임서버를 옮기고 전환이 적용되길 기다리는 중이라면, 그건 조회가 아니라 타이밍 문제입니다 — 네임서버 변경 적용 확인하는 법을 보세요.
• 국내 호스트에서 도메인을 처음 연결하는 중이라면, 카페24 도메인 연결 안 됨의 제공자별 3층 안내가 같은 등록대행사 / 네임서버 / 레코드 틀을 그 패널의 항목으로 따라갑니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

진단