재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
네임서버란? 도메인 위임의 원리
네임서버는 도메인의 DNS 레코드를 보유하고 그에 대한 질문에 응답하는 서버입니다. 도메인의 NS 레코드가 어느 네임서버가 담당하는지 지정하며, 이 단 하나의 설정이 어느 관리 패널에서 한 수정이 실제로 유효한지를 결정합니다.
DNS 레코드를 바꾸고 기다렸는데도 아무 일도 일어나지 않은 적이 있다면, 거의 확실히 이것이 이유입니다.
위임: 인터넷이 내 네임서버를 찾는 방법
DNS는 위임 계층 구조입니다. 모든 도메인의 마스터 목록을 가진 곳은 없습니다. 대신 각 단계가 책임을 다음 단계로 넘깁니다.
재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
- 루트 서버는 각 최상위 도메인을 누가 운영하는지 압니다.
.com,.org,.io를 누가 책임지는지입니다. .com레지스트리는 각.com도메인이 어느 네임서버에 위임되어 있는지 압니다. 내NS레코드가 기록되는 곳입니다.- 내 네임서버가 실제 존을 보유합니다.
A,MX,TXT등 모든 레코드입니다.
핵심 요약
레지스트라는 도메인이 어느 네임서버를 가리키는지를 제어합니다. 그 네임서버를 운영하는 쪽이 레코드가 무엇을 말하는지를 제어합니다. 이 둘은 서로 다른 회사인 경우가 많습니다.
레지스트라 대 DNS 호스트
이 구분은 DNS에서 그 무엇보다 많은 혼란을 일으킵니다.
| 레지스트라 | DNS 호스트 | |
|---|---|---|
| 하는 일 | 도메인 이름을 등록하고 소유함 | 도메인에 대한 DNS 질의에 응답함 |
| 제어 대상 | NS 위임 | 실제 레코드 |
| 예시 | Namecheap, GoDaddy, Google Domains | Cloudflare, 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 제공업체를 바꾸면 존 전체가 한꺼번에 이동합니다. 부주의하게 진행하면 웹사이트, 이메일, 모든 검증 레코드가 동시에 망가집니다.
기존 레코드를 먼저 모두 복사
현재 제공업체에서 존 전체를 내보내세요.
A레코드만이 아니라MX, 모든TXT(SPF, DKIM, 소유권 확인 토큰),CNAME, 모든 서브도메인을 포함합니다. 하나라도 빠뜨리면 그 레코드에 의존하는 서비스가 중단됩니다.전환 전에 새 제공업체에서 재생성
위임이 아직 이전 제공업체를 가리키는 동안 새 호스트에서 완전한 존을 구축하세요. 아직 아무것도 적용되지 않았으므로 실수해도 비용이 들지 않습니다.
새 네임서버에 직접 질의해 검증
각 레코드 유형별로
dig @ns1.newprovider.com example.com을 실행하세요. 위임을 변경하기 전에 새 서버를 질의하므로 존이 올바른지 확인할 수 있습니다.레지스트라에서 NS 레코드 업데이트
이제야 위임을 변경합니다. 레지스트리 TTL 때문에 모든 곳에서 변경이 보이기까지 최대 48시간이 걸릴 수 있습니다.
이전 존은 일주일 동안 유지
이전 레코드를 즉시 삭제하지 마세요. 위임이 전환되는 동안 일부 리졸버는 여전히 이전 서버에 접속하며, 존이 없어지면 그 쿼리는 완전히 실패합니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
이 주제의 무료 도구
자주 묻는 질문
관련 글
재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
DNS의 작동 원리: 도메인 이름에서 IP 주소까지
인터넷의 전화번호부를 처음부터 끝까지 추적합니다. 도메인을 입력한 뒤 첫 패킷이 서버에 닿기까지 몇 밀리초 동안 무슨 일이 일어날까요?
“전파”란 사실 캐시 만료일 뿐
0분
변경 사항 저장
0-5분
DNS 호스트가 업데이트
TTL까지
이전 응답이 아직 캐시됨
TTL 이후
모두 새 응답을 확인
어디로도 푸시되지 않으며, 각 캐시가 사본 재사용을 멈출 뿐입니다
DNS 전파, 변경이 오래 걸리는 진짜 이유
실제로 전파되는 것은 없습니다. 기다리는 동안 무슨 일이 일어나는지 이해하면 얼마나 걸릴지, 어떻게 줄일지 정확히 알 수 있습니다.
거의 모든 존에서 만나게 되는 레코드
DNS 레코드 유형 총정리: 완전한 레퍼런스
알아 둘 가치가 있는 모든 레코드 유형의 역할, 모양, 그리고 흔히 저지르는 실수를 한 페이지에 정리했습니다.