Domain IP Lookup

재귀 DNS 조회, 단계별로 살펴보기

브라우저

example.com 요청

리졸버

내 ISP / 1.1.1.1

루트 + TLD

.com 운영 주체는?

권한 네임서버

실제 응답

체인의 각 단계도 DNS 조회이며 이후 캐시됩니다

DNS 기초

네임서버란? 도메인 위임의 원리

읽는 시간 3분

네임서버는 도메인의 DNS 레코드를 보유하고 그에 대한 질문에 응답하는 서버입니다. 도메인의 NS 레코드가 어느 네임서버가 담당하는지 지정하며, 이 단 하나의 설정이 어느 관리 패널에서 한 수정이 실제로 유효한지를 결정합니다.

DNS 레코드를 바꾸고 기다렸는데도 아무 일도 일어나지 않은 적이 있다면, 거의 확실히 이것이 이유입니다.

위임: 인터넷이 내 네임서버를 찾는 방법

DNS는 위임 계층 구조입니다. 모든 도메인의 마스터 목록을 가진 곳은 없습니다. 대신 각 단계가 책임을 다음 단계로 넘깁니다.

재귀 DNS 조회, 단계별로 살펴보기

브라우저

example.com 요청

리졸버

내 ISP / 1.1.1.1

루트 + TLD

.com 운영 주체는?

권한 네임서버

실제 응답

체인의 각 단계도 DNS 조회이며 이후 캐시됩니다

각 단계는 다음에 누구에게 물어볼지만 압니다. 내 네임서버가 최종 권한입니다.
  1. 루트 서버는 각 최상위 도메인을 누가 운영하는지 압니다. .com, .org, .io를 누가 책임지는지입니다.
  2. .com 레지스트리는 각 .com 도메인이 어느 네임서버에 위임되어 있는지 압니다. 내 NS 레코드가 기록되는 곳입니다.
  3. 내 네임서버가 실제 존을 보유합니다. A, MX, TXT 등 모든 레코드입니다.

핵심 요약

레지스트라는 도메인이 어느 네임서버를 가리키는지를 제어합니다. 그 네임서버를 운영하는 쪽이 레코드가 무엇을 말하는지를 제어합니다. 이 둘은 서로 다른 회사인 경우가 많습니다.

레지스트라 대 DNS 호스트

이 구분은 DNS에서 그 무엇보다 많은 혼란을 일으킵니다.

레지스트라DNS 호스트
하는 일도메인 이름을 등록하고 소유함도메인에 대한 DNS 질의에 응답함
제어 대상NS 위임실제 레코드
예시Namecheap, GoDaddy, Google DomainsCloudflare, Route 53, 웹 호스트
같은 회사인가?자주 그렇지만 반드시 그런 것은 아님

NS 레코드의 모습

위임 레코드
example.com.    86400    IN    NS    ns1.cloudflare.com.
example.com.    86400    IN    NS    ns2.cloudflare.com.

긴 TTL에 주목하세요. 86400초는 하루이며, 위임 TTL은 그보다 더 긴 경우가 많습니다. 의도된 것입니다. 위임은 거의 바뀌지 않으며, 이를 강하게 캐시하면 TLD 서버의 부하가 줄어듭니다.

네임서버 두 대가 실질적인 최소치이며, 대부분의 레지스트리는 최소 두 대를 요구합니다. 제공업체는 보통 두 대에서 네 대를 제공하며, 한 곳의 장애로 도메인이 오프라인이 되지 않도록 서로 다른 네트워크에 호스팅합니다.

내 네임서버 확인하는 방법

명령줄
dig +short example.com NS

또는 도메인을 조회 도구에 넣어 보세요. 다른 모든 정보와 함께 NS 레코드가 나열됩니다. 어떤 결과가 나오든, 그 제공업체의 관리 패널이 내가 수정해야 하는 곳입니다.

네임서버를 안전하게 변경하기

DNS 제공업체를 바꾸면 존 전체가 한꺼번에 이동합니다. 부주의하게 진행하면 웹사이트, 이메일, 모든 검증 레코드가 동시에 망가집니다.

  1. 기존 레코드를 먼저 모두 복사

    현재 제공업체에서 존 전체를 내보내세요. A 레코드만이 아니라 MX, 모든 TXT(SPF, DKIM, 소유권 확인 토큰), CNAME, 모든 서브도메인을 포함합니다. 하나라도 빠뜨리면 그 레코드에 의존하는 서비스가 중단됩니다.

  2. 전환 전에 새 제공업체에서 재생성

    위임이 아직 이전 제공업체를 가리키는 동안 새 호스트에서 완전한 존을 구축하세요. 아직 아무것도 적용되지 않았으므로 실수해도 비용이 들지 않습니다.

  3. 새 네임서버에 직접 질의해 검증

    각 레코드 유형별로 dig @ns1.newprovider.com example.com을 실행하세요. 위임을 변경하기 전에 새 서버를 질의하므로 존이 올바른지 확인할 수 있습니다.

  4. 레지스트라에서 NS 레코드 업데이트

    이제야 위임을 변경합니다. 레지스트리 TTL 때문에 모든 곳에서 변경이 보이기까지 최대 48시간이 걸릴 수 있습니다.

  5. 이전 존은 일주일 동안 유지

    이전 레코드를 즉시 삭제하지 마세요. 위임이 전환되는 동안 일부 리졸버는 여전히 이전 서버에 접속하며, 존이 없어지면 그 쿼리는 완전히 실패합니다.

도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.

이 주제의 무료 도구

자주 묻는 질문

관련 글

재귀 DNS 조회, 단계별로 살펴보기

브라우저

example.com 요청

리졸버

내 ISP / 1.1.1.1

루트 + TLD

.com 운영 주체는?

권한 네임서버

실제 응답

체인의 각 단계도 DNS 조회이며 이후 캐시됩니다

DNS 기초

DNS의 작동 원리: 도메인 이름에서 IP 주소까지

인터넷의 전화번호부를 처음부터 끝까지 추적합니다. 도메인을 입력한 뒤 첫 패킷이 서버에 닿기까지 몇 밀리초 동안 무슨 일이 일어날까요?

읽는 시간 3분

“전파”란 사실 캐시 만료일 뿐

0분

변경 사항 저장

0-5분

DNS 호스트가 업데이트

TTL까지

이전 응답이 아직 캐시됨

TTL 이후

모두 새 응답을 확인

어디로도 푸시되지 않으며, 각 캐시가 사본 재사용을 멈출 뿐입니다

DNS 기초

DNS 전파, 변경이 오래 걸리는 진짜 이유

실제로 전파되는 것은 없습니다. 기다리는 동안 무슨 일이 일어나는지 이해하면 얼마나 걸릴지, 어떻게 줄일지 정확히 알 수 있습니다.

읽는 시간 3분

거의 모든 존에서 만나게 되는 레코드

A호스트 이름을 IPv4 주소로 연결
AAAA호스트 이름을 IPv6 주소로 연결
CNAME호스트 이름을 다른 호스트 이름으로 연결
MX도메인을 메일 서버로 연결, 우선순위 기준
TXT도메인에 임의의 텍스트 연결: SPF, DKIM, 소유권 확인
NS도메인에 응답하는 네임서버 지정
DNS 기초

DNS 레코드 유형 총정리: 완전한 레퍼런스

알아 둘 가치가 있는 모든 레코드 유형의 역할, 모양, 그리고 흔히 저지르는 실수를 한 페이지에 정리했습니다.

읽는 시간 4분