주소창에 도메인을 입력하면, IP는 어디서 올까? DNS 조회의 전체 흐름

브라우저 주소창에 www.example.com을 입력하면 곧바로 웹 서버에 연결되는 것처럼 보입니다.

하지만 네트워크는 도메인 이름만으로 목적지를 찾을 수 없습니다. 실제 통신을 시작하려면 먼저 IPv4 또는 IPv6 주소가 필요합니다.

그렇다면 브라우저는 누구에게 IP 주소를 물어보고, DNS 서버들은 어떻게 최종 답을 찾아낼까요?

 

이 글에서는 브라우저 캐시부터 재귀 DNS 리졸버, Root DNS, TLD DNS, Authoritative DNS까지 이어지는 전체 조회 흐름을 따라갑니다. 마지막에는 TTL이 서버 이전에 미치는 영향과 DNS가 UDP뿐 아니라 TCP도 사용하는 이유까지 정리합니다.

---

1. 브라우저는 도메인 이름만으로 접속할 수 없다

DNS는 사람이 읽기 쉬운 도메인 이름을 네트워크가 사용할 IP 주소로 바꾸는 분산 디렉터리 시스템입니다.

 

브라우저는 먼저 자체 캐시를 확인하고, 운영체제의 DNS 캐시와 이름 해석 기능을 사용합니다. 여기에도 답이 없으면 운영체제에 설정된 재귀 DNS 리졸버에 최종 IP를 대신 찾아 달라고 요청합니다.

 

재귀 리졸버는 ISP, 회사 네트워크, 공유기 뒤의 DNS 서비스 또는 Google Public DNS 같은 공용 서비스가 제공할 수 있습니다. 웹 요청을 중계하는 프록시 서버와는 다른 구성 요소입니다.

2. DNS 서버의 실제 테이블은 어떻게 생겼을까?

DNS는 하나의 거대한 표에서 주소를 한 번에 찾지 않습니다. Root, TLD, Authoritative DNS가 자신이 책임지는 Resource Record를 나눠 가집니다.

2-1. Root DNS가 가진 Resource Record 테이블

Name	Type	Value	TTL	의미
com.	NS	ns1.com-tld.example.	172800	.com은 이 TLD DNS가 담당
ns1.com-tld.example.	A	192.0.2.10	172800	TLD DNS로 가기 위한 Glue Record

리졸버가 www.example.com. A를 물으면 Root DNS는 오른쪽 계층인 com. 행을 찾습니다. 최종 웹 서버 IP 대신 .com TLD DNS의 NS 레코드와 필요한 Glue Record를 반환합니다.

2-2. .com TLD DNS가 가진 Resource Record 테이블

Name	Type	Value	TTL	의미
example.com.	NS	ns1.example.com.	86400	example.com Zone의 책임 DNS
ns1.example.com.	A	192.0.2.53	86400	책임 DNS로 가기 위한 Glue Record

리졸버는 Root DNS가 알려 준 192.0.2.10으로 이동해 같은 질문을 보냅니다. TLD DNS는 example.com. 행을 찾아 이 Zone을 담당하는 Authoritative DNS를 안내합니다.

2-3. example.com Authoritative DNS가 가진 Resource Record 테이블

Name	Type	Value	TTL	의미
www.example.com.	A	192.0.2.80	300	웹 서버의 IPv4 주소
www.example.com.	AAAA	2001:db8::80	300	웹 서버의 IPv6 주소
app.example.com.	CNAME	www.example.com.	300	app을 www의 별칭으로 연결

리졸버는 192.0.2.53의 Authoritative DNS에 질의합니다. 이 서버는 이름 www.example.com.과 요청 타입 A가 모두 일치하는 행을 찾아 최종 IP 192.0.2.80을 반환합니다.

2-4. 조회가 끝난 뒤 재귀 리졸버의 캐시 테이블

Name	Type	Value	남은 TTL	출처
com.	NS	ns1.com-tld.example.	최대 172800	Root DNS
example.com.	NS	ns1.example.com.	최대 86400	.com TLD DNS
www.example.com.	A	192.0.2.80	최대 300	Authoritative DNS

리졸버는 중간 위임 정보와 최종 A 레코드를 각각의 TTL 동안 캐시합니다. A 레코드만 만료되고 NS 캐시는 남아 있다면 Root부터 다시 시작하지 않고 Authoritative DNS에 곧바로 물을 수 있습니다.

3. 테이블의 어느 행을 따라가는가

질의: www.example.com. A

1) Root DNS 테이블
   com.  NS  ns1.com-tld.example.
   → .com TLD DNS: 192.0.2.10

2) .com TLD DNS 테이블
   example.com.  NS  ns1.example.com.
   → Authoritative DNS: 192.0.2.53

3) Authoritative DNS 테이블
   www.example.com.  A  192.0.2.80
   → 최종 웹 서버 IP: 192.0.2.80

4) 재귀 리졸버 캐시
   중간 NS와 최종 A 레코드를 각 TTL 동안 저장
   → 브라우저에 192.0.2.80 반환

 

정리하면 Root와 TLD DNS는 질문과 일치하는 오른쪽 도메인 계층의 NS 행을 찾아 다음 DNS 서버를 안내합니다. Authoritative DNS에 도착한 뒤에야 전체 이름과 타입이 일치하는 A 행에서 최종 IP를 얻습니다.

 

www.example.com.의 마지막 점은 DNS 계층 최상단인 Root를 뜻합니다. 평소에는 생략하지만 완전한 도메인 이름에는 개념적으로 포함되어 있습니다.

4. 재귀 질의와 반복 질의는 책임이 다르다

클라이언트가 재귀 리졸버에게 최종 결과를 대신 찾아 달라고 요청하는 것은 재귀 질의입니다.

재귀 리졸버가 Root, TLD, Authoritative DNS에 차례로 물으며 다음 질의 위치를 안내받는 것은 일반적으로 반복 질의입니다.

• Root DNS는 .com을 담당하는 TLD DNS의 NS 레코드를 알려 줍니다.
• TLD DNS는 example.com을 담당하는 Authoritative DNS의 NS 레코드를 알려 줍니다.
• Authoritative DNS는 자신이 책임지는 A·AAAA 또는 CNAME 레코드로 응답합니다.

Root 같은 상위 서버가 모든 재귀 조회를 직접 처리하지 않기 때문에 부하와 장애 범위를 전 세계 DNS 계층에 분산할 수 있습니다.

5. A, AAAA, NS, CNAME은 무엇이 다를까

레코드	의미
A	호스트 이름을 IPv4 주소에 연결합니다.
AAAA	호스트 이름을 IPv6 주소에 연결합니다.
NS	특정 도메인 또는 Zone을 담당하는 이름 서버를 가리킵니다.
CNAME	한 호스트 이름을 다른 정식 호스트 이름의 별칭으로 연결합니다.

Authoritative DNS가 다음처럼 CNAME을 반환할 수도 있습니다.

www.example.com CNAME app.hosting.net

 

이 경우 재귀 리졸버는 app.hosting.net의 A·AAAA 레코드가 캐시에 있는지 확인합니다. 없다면 hosting.net에 대한 DNS 조회를 이어갑니다. 클라이언트가 실제 서버에 접속하려면 결국 IP 주소가 필요합니다.

6. TTL이 끝나야 DNS 변경이 보이는 이유

DNS 응답의 Resource Record에는 TTL, Time To Live가 들어 있습니다. 재귀 리졸버는 레코드를 TTL 동안 캐시해 반복 조회의 지연과 DNS 서버의 부하를 줄입니다.

 

TTL이 만료됐다고 리졸버가 즉시 새 주소를 가져오는 것은 아닙니다. 일반적으로 만료된 캐시를 더 이상 사용하지 않고, 이후 같은 질의가 들어왔을 때 다시 조회합니다.

 

흔히 말하는 “DNS 전파 시간”도 중앙 서버가 변경을 전 세계에 밀어내는 시간이 아닙니다. 브라우저, 운영체제, 재귀 리졸버 등에 흩어진 기존 캐시가 각자의 TTL에 따라 만료되는 시간에 가깝습니다.

• 긴 TTL: 조회량과 지연은 줄지만 장애 조치와 주소 변경이 느립니다.
• 짧은 TTL: 변경은 빠르게 반영되지만 DNS 질의량과 인프라 의존도가 커집니다.

7. 서버 IP를 안전하게 이전하는 순서

현재 A 레코드의 TTL이 24시간인데 내일 서버 IP를 바꾼다고 가정해 보겠습니다. 변경 직전에 TTL을 5분으로 낮춰도 이미 캐시된 24시간은 소급해서 줄어들지 않습니다.

1. 이전 최소 24시간 전에 TTL을 5분처럼 짧게 낮춥니다.
2. 기존 24시간 캐시가 만료될 시간을 기다립니다.
3. A·AAAA 레코드를 새 서버 IP로 변경합니다.
4. 짧은 TTL과 운영 여유 시간 동안 이전 서버와 새 서버를 함께 운영합니다.
5. 트래픽과 오류율을 확인한 뒤 이전 서버를 종료합니다.
6. 전환과 롤백 위험이 낮아지면 TTL을 다시 늘립니다.

DNS 변경 후 사용자가 무조건 존재하지 않는 IP로 가는 것은 아닙니다. TTL이 남아 있는 동안에는 이전 IP로 갑니다. 이전 서버를 너무 일찍 종료했을 때 연결 실패가 발생합니다.

8. DNS는 왜 UDP를 사용하고 언제 TCP로 바꿀까

일반적인 DNS 질의는 짧은 요청 하나와 응답 하나로 끝납니다. UDP를 사용하면 TCP 연결을 만들기 위한 Handshake와 연결 상태 관리 비용을 피할 수 있습니다. 응답이 유실되면 클라이언트가 다시 질의하거나 다른 DNS 서버를 시도할 수 있습니다.

DNS가 UDP를 사용하는 이유는 IP 주소의 정확성이나 유실이 중요하지 않아서가 아닙니다. 짧은 요청·응답을 더 적은 비용으로 처리하고, 손실 시 DNS 계층에서 재시도할 수 있기 때문입니다.

 

DNS는 UDP만 사용하는 프로토콜도 아닙니다.

• UDP 응답이 너무 커서 잘리면 서버가 TC, Truncated 플래그를 설정하고 클라이언트가 TCP로 다시 질의합니다.
• EDNS는 기존 UDP 응답 크기 한계를 확장해 TCP 전환을 줄일 수 있습니다.
• DNSSEC, AAAA, 대형 TXT 레코드 등으로 응답이 커지면 TCP가 필요할 수 있습니다.
• Authoritative DNS 사이에서 Zone 전체를 옮기는 AXFR는 TCP를 사용합니다.
• 현재 DNS 표준은 완전한 DNS 구현이 TCP도 지원하도록 요구합니다.

TCP도 연결 실패와 Timeout이 생길 수 있으므로 “오래 걸려도 무조건 받는 방식”은 아닙니다. 전송 방식의 보장과 애플리케이션이 결과를 끝내 얻는다는 보장은 구분해야 합니다.

마무리

브라우저가 도메인 이름을 IP로 바꾸는 과정의 중심에는 재귀 DNS 리졸버가 있습니다. 리졸버는 캐시가 없으면 Root, TLD, Authoritative DNS를 반복적으로 조회하고, 얻은 A·AAAA 또는 CNAME 결과를 TTL 동안 저장합니다.

DNS의 계층 구조는 전 세계 이름 정보를 한 서버에 집중하지 않게 하고, 캐시는 조회 지연과 부하를 줄입니다. 대신 TTL 동안 이전 주소가 남을 수 있으므로 서버 이전에서는 DNS 변경뿐 아니라 기존 서버의 운영 기간까지 함께 설계해야 합니다.

---

참고한 표준

• RFC 1034 — Domain Names: Concepts and Facilities
• RFC 1035 — Domain Names: Implementation and Specification
• RFC 6891 — EDNS(0)
• RFC 7766 — DNS over TCP
• RFC 5936 — DNS Zone Transfer Protocol
• RFC 5737 — IPv4 Address Blocks Reserved for Documentation
• RFC 3849 — IPv6 Address Prefix Reserved for Documentation