[Network] 13. 우리는 왜 숫자 대신 이름으로 접속할까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 4. 이름을 주소로 바꾸고 대화를 시작하기

ㅁ 들어가며

라우터는 Destination IP를 보고 패킷의 다음 길을 선택한다.

그런데 사용자는 웹사이트에 접속할 때 IP 주소를 직접 입력하지 않는다.

 

https://example.com

 

사람은 example.com이라는 이름을 기억한다.

실제 IP Packet을 보내려는 운영체제는 목적지 IP 주소가 필요하다.

사람이 아는 정보 : example.com
네트워크가 필요한 정보 : IPv4 또는 IPv6 Address

 

이름과 주소 사이에는 누군가 답해야 할 질문이 있다.

 

example.com은 어느 IP 주소에 있는가?

이 질문을 전 세계에서 하나의 서버가 모두 처리한다면 그 서버의 장애와 부하가 인터넷 전체에 영향을 준다.

모든 이름을 한 파일에 저장해 배포해도 변경 사항을 빠르게 반영하기 어렵다.

DNS는 이름 공간을 계층적으로 나누고, 각 영역의 관리 권한을 위임하고, 반복되는 답은 일정 시간 캐시하는 방식으로 이 문제를 해결한다.

이번 글에서는 

 Stub Resolver, Recursive Resolver, Root Name Server, TLD Name Server, Authoritative Name Server를

거치는 흐름과 주요 DNS Record, Cache TTL, 그리고 이름 조회 실패가 어떤 모습으로 나타나는지 살펴본다.

---

ㅁ 인터넷 주소록은 한 권일까?

동네의 모든 집 주소를 한 사람이 관리할 수는 있다.

하지만 전 세계의 사람과 조직, 서비스 이름을 한 권의 주소록에 넣는다면 다음 문제가 생긴다.

• 새로운 이름을 등록할 때마다 중앙 관리자가 수정해야 한다.
• 모든 조회가 한 장소로 몰린다.
• 주소록 한 권이 고장 나면 누구도 이름을 찾지 못한다.
• 서로 다른 조직이 자신의 이름을 독립적으로 관리하기 어렵다.

 

DNS는 이름을 오른쪽에서 왼쪽으로 이어지는 계층으로 구성한다.

www.example.com.
│   │       │  └─ Root
│   │       └──── Top-Level Domain: com
│   └──────────── Domain: example
└──────────────── Host 또는 Service Label: www

마지막의 점은 DNS 계층의 Root를 나타낸다. 

www.example.com.처럼 Root까지 모두 적은 이름을 FQDN(Fully Qualified Domain Name)이라고 한다.

일상에서는 마지막 점을 생략한 www.example.com을 주로 사용한다.

 

각 점 사이의 문자열을 Label이라고 한다.

상위 영역은 하위 영역의 모든 레코드를 직접 관리하는 대신 관리 권한을 위임할 수 있다.

Root는 com의 위치를 안내
com은 example.com의 권한 서버를 안내
example.com의 권한 서버가 www의 실제 Record를 답변

 

한 권의 주소록이 아니라 여러 관리자가 맡은 계층적인 주소 체계다.

---

ㅁ 애플리케이션은 누구에게 이름을 물을까?

브라우저가 www.example.com에 접속하려고 한다.

브라우저 또는 애플리케이션은 일반적으로 Root Server부터 직접 찾아가지 않는다. 운영체제의 이름 해석 기능을 호출한다.

호스트 안에서 애플리케이션의 요청을 받아 DNS 질의를 시작하는 구성 요소를 Stub Resolver라고 한다.

Stub Resolver는 시스템에 설정된 Recursive Resolver에게 질문한다.

Application
    ↓ 이름 해석 요청
Stub Resolver
    ↓ Recursive Query
Recursive Resolver

Recursive Resolver는 가정용 공유기, 인터넷 사업자, 회사 내부 DNS, 또는 공개 DNS 서비스일 수 있다. DHCP나 수동 설정을 통해 주소를 받을 수 있다.

Stub Resolver가 기대하는 것은 보통 다음과 같다.

필요한 곳에 대신 물어보고 최종 답이나 실패 결과를 돌려 달라.

그래서 Recursive라는 이름을 사용한다.

---

ㅁ Recursive Resolver는 먼저 기억을 확인한다

Resolver는 외부에 질문하기 전에 Cache를 확인한다.

www.example.com A Record가 Cache에 있는가?
├─ 있다 → 남은 TTL과 함께 즉시 응답
└─ 없다 → DNS 계층에 질의 시작

 

캐시된 답이 있으면 Root, TLD, Authoritative Server에 다시 질의할 필요가 없다.

이는 두 가지 효과를 만든다.

• 사용자에게 더 빠르게 답할 수 있다.
• DNS 계층 서버의 반복 조회 부하를 줄인다.

DNS가 인터넷 규모로 확장될 수 있었던 중요한 이유는 계층 구조와 Cache가 함께 있기 때문이다.

Cache Miss라면 Resolver는 답을 찾기 위한 과정을 시작한다.

---

ㅁ Root Server는 모든 IP 주소를 알고 있을까?

Recursive Resolver가 www.example.com의 A Record를 찾는 흐름을 단순화해 보자.

 

ㅇ 1단계: Root Name Server에 묻는다

Resolver는 Root Name Server에 질문한다.

www.example.com의 A Record는 무엇인가?

Root Server는 보통 www.example.com의 IP 주소를 직접 답하지 않는다.

대신 .com을 담당하는 TLD Name Server의 위치를 안내한다.

나는 최종 답을 갖고 있지 않다.
com 영역은 이 Name Server들에게 물어보라.

이처럼 다음 권한 영역을 안내하는 답을 Referral이라고 한다.

 

ㅇ 2단계: TLD Name Server에 묻는다

Resolver는 .com TLD Name Server에 같은 질문을 한다.

TLD Server도 보통 www의 A Record를 직접 관리하지 않는다. 대신 example.com을 담당하는 Authoritative Name Server의 NS Record를 안내한다.

example.com은 이 Authoritative Name Server들에게 물어보라.

 

ㅇ 3단계: Authoritative Name Server에 묻는다

Resolver는 example.com의 권한 서버에 질문한다.

이 서버가 해당 Zone의 Record를 관리하고 있다면 최종 답을 제공한다.

www.example.com A <IPv4 Address>
TTL <seconds>

 

ㅇ 4단계: 답을 Cache하고 Stub Resolver에 돌려준다

Recursive Resolver는 받은 Record를 TTL 범위 안에서 Cache하고 Client에게 응답한다.

Stub → Recursive → Root → TLD → Authoritative
Stub ← Recursive ← 최종 답과 TTL

 

Root와 TLD는 모든 Host의 IP 주소를 저장하지 않는다.

다음 관리 영역을 찾을 수 있도록 위임 정보를 제공한다.

이 분산 위임 구조가 각 조직이 자신의 Domain을 독립적으로 관리하면서도 하나의 전역 이름 공간을 사용할 수 있게 한다.

---

ㅁ Recursive Query와 Iterative Query는 무엇이 다를까?

Stub Resolver는 Recursive Resolver에게 최종 답을 요청한다.

 

Recursive Query:
“대신 끝까지 찾아서 답을 달라.”

Recursive Resolver가 DNS 계층을 따라갈 때는 각 서버가 자신이 아는 최선의 정보나 다음 서버를 안내하는 방식의 질의를 사용한다.

 

Iterative Resolution:
Root          → com Server를 안내
com Server    → example.com Server를 안내
Authoritative → 최종 Record 응답

 

실제 Resolver 구현은 위임 정보와 NS 주소도 Cache하고,

 여러 Authoritative Server 중 응답 가능한 서버를 선택하며,

 DNSSEC 검증 같은 추가 작업을 수행할 수 있다.

 

입문 단계에서 핵심 차이는 다음과 같다.

Stub은 Recursive Resolver에게 최종 답을 맡긴다.
Recursive Resolver는 여러 DNS Server의 안내를 따라 답을 찾는다.

---

ㅁ 이름 하나에는 어떤 Record가 있을까?

DNS는 이름을 IP 주소로만 바꾸는 시스템이 아니다.

이름에 관한 여러 종류의 정보를 Resource Record(RR)로 저장한다.

Record Type	역할
A	이름을 IPv4 주소에 연결
AAAA	이름을 IPv6 주소에 연결
CNAME	한 이름을 다른 Canonical Name의 별칭으로 연결
NS	Zone의 Authoritative Name Server를 지정
MX	Domain의 Mail Exchanger를 지정
TXT	정책 검증 등 다양한 Text 정보를 저장
SOA	Zone의 시작과 관리·갱신 관련 기본 정보를 표현
PTR	IP 주소에 대응하는 이름을 찾는 Reverse DNS에 사용

브라우저가 접속할 주소를 찾을 때 A와 AAAA Record를 함께 질의할 수 있다.

CNAME을 만나면 별칭이 가리키는 이름의 A 또는 AAAA Record를 다시 찾아야 할 수 있다.

www.example.com CNAME service.example.net
service.example.net A <IPv4 Address>

 

MX Record는 Mail Server의 이름을 알려 주며,

그 이름에 대한 A 또는 AAAA 조회가 추가로 필요할 수 있다.

 

Record Type마다 질문과 답의 의미가 다르다.

“DNS가 된다”는 표현보다 어떤 이름의 어떤 Record를 조회했는가를 명확히 하는 것이 좋다.

---

ㅁ DNS TTL은 패킷의 TTL과 같은 것일까?

DNS Record에도 TTL(Time To Live)이 있다.

이름은 IPv4 Header의 TTL과 같지만 목적은 다르다.

구분	IP TTL	DNS TTL
위치	IPv4 Header	DNS Resource Record
단위·동작	Router Hop마다 감소	Cache가 답을 보관할 수 있는 시간(초)
목적	Packet의 무한 Routing Loop 제한	DNS 답의 재사용 기간 제한
만료 결과	Packet 폐기와 ICMP 가능	다음 조회에서 새 DNS 질의 필요

 

DNS TTL이 300이면 Resolver는 일반적으로 해당 Record를 최대 300초 동안 재사용할 수 있다.

Cache에서 응답할 때는 남은 TTL이 줄어든 모습으로 보일 수 있다.

권한 서버 응답 TTL : 300
100초 뒤 Cache 응답: 남은 TTL 약 200
TTL 만료 후         : 권한 계층에 다시 질의

 

DNS TTL은 변경 사항이 전 세계에 “전파되는 속도”를 직접 지시하는 값이라기보다

각 Cache가 기존 답을 언제까지 재사용할 수 있는지를 제한하는 값이다.

---

ㅁ 서버 주소를 바꿨는데 왜 예전 주소로 갈까?

서비스 운영자가 A Record를 새 IP 주소로 변경했다고 하자.

이전 A Record: Old IP, TTL 3600
새 A Record  : New IP

 

권한 서버에서는 새 주소를 답하지만 변경 전에 Old IP를 받은 Resolver는 남은

TTL 동안 기존 답을 사용할 수 있다.

다음과 같은 여러 Cache 계층도 영향을 줄 수 있다.

• 애플리케이션 또는 브라우저 Cache
• 운영체제 Resolver Cache
• 로컬 네트워크의 DNS Forwarder
• Recursive Resolver Cache

그래서 같은 시간에도 사용자가 사용하는 Resolver와 기존 Cache 시점에 따라 서로 다른 IP 주소를 받을 수 있다.

주소 변경을 계획할 때는 일반적으로 다음 흐름을 고려한다.

1. 변경 전 충분한 시간에 TTL을 낮춘다.
2. 기존의 긴 TTL Cache가 만료될 시간을 기다린다.
3. A/AAAA Record를 새 주소로 변경한다.
4. 이전 주소도 전환 기간 동안 요청을 처리할 수 있게 유지한다.
5. 안정화 후 TTL을 운영 값으로 조정한다.

이미 Cache된 답의 TTL을 권한 서버에서 나중에 낮춰도 기존 Cache의 남은 시간을 즉시 줄일 수는 없다.

DNS 변경은 Record 한 줄을 수정하는 순간보다 Cache에 남아 있는 이전 답이 사라지는 기간까지 포함해 계획해야 한다.

---

ㅁ 없는 이름도 Cache할까?

Resolver는 성공한 답만 Cache하는 것이 아니다.

존재하지 않는 이름이라는 답도 일정 시간 Cache할 수 있다. 이를 Negative Caching이라고 한다.

예를 들어 잘못된 이름을 조회해 NXDOMAIN을 받은 직후 Record를 생성해도

일부 Resolver는 이전의 부정 응답을 잠시 재사용할 수 있다.

Negative Cache 기간은 Zone의 SOA 정보와 Resolver 정책 등의 영향을 받는다.

Positive Cache : “이 이름의 A Record는 이 주소다.”
Negative Cache : “이 이름은 존재하지 않는다.”

새 Record를 만들었는데도 일부 환경에서 NXDOMAIN이 계속 보인다면 성공 응답 Cache뿐 아니라 Negative Cache도 확인해야 한다.

---

ㅁ 주소가 여러 개면 어느 서버로 갈까?

하나의 이름에 여러 A 또는 AAAA Record가 있을 수 있다.

service.example.com A 192.0.2.10
service.example.com A 192.0.2.20

DNS Server와 Resolver는 답의 순서를 바꾸거나 여러 주소를 함께 전달할 수 있다.

Client는 자신의 주소 선택과 연결 로직에 따라 하나를 사용한다.

이를 단순한 부하 분산에 활용할 수 있지만 DNS Record가 있다는 사실이 Server의 상태를 자동으로 보장하지는 않는다.

두 주소 중 하나의 Server가 죽었는데 DNS 답에 계속 포함되어 있으면 사용자에게 다음과 같이 보일 수 있다.

어떤 연결은 빠르게 성공
어떤 연결은 Timeout 후 다른 주소로 시도
환경에 따라 일부 요청은 그대로 실패

Client의 재시도 방식, DNS 기반 Health Check, Load Balancer 구성에 따라 결과는 달라진다.

“DNS에 IP가 여러 개 있으니 자동으로 장애 조치된다”고 가정하면 안 된다.

---

ㅁ DNS가 실패했다는 말은 무엇을 뜻할까?

이름 해석 실패도 여러 상태로 나뉜다.

 

ㅇ NXDOMAIN

질의한 Domain Name이 존재하지 않는다는 권한 있는 부정 응답이다.

오타, Record 생성 전, 잘못된 Search Domain 등이 원인일 수 있다.

 

ㅇ NOERROR지만 원하는 Answer가 없음

이름은 존재하지만 요청한 Record Type의 데이터가 없을 수 있다. 이를 흔히 NODATA 상황으로 설명한다.

예를 들어 이름에는 A Record가 있지만 AAAA Record가 없을 수 있다.

 

ㅇ SERVFAIL

Resolver가 질의를 처리했지만 정상적인 답을 만들지 못했다.

권한 서버 실패, DNSSEC 검증 실패, 위임 문제 등 여러 원인이 있을 수 있다.

 

ㅇ Timeout

정해진 시간 안에 DNS 응답을 받지 못했다.

Resolver까지의 경로, UDP/TCP 53 정책, 서버 과부하, Packet Loss 등을 확인해야 한다.

 

ㅇ REFUSED

DNS Server가 정책상 해당 질의를 처리하지 않겠다고 응답할 수 있다.

NXDOMAIN : 이름이 없다는 답을 받음
NODATA   : 이름은 있지만 요청 Type의 답이 없음
SERVFAIL : 서버가 정상 답을 만들지 못함
Timeout  : 응답 자체를 받지 못함
REFUSED  : 정책상 질의를 거부함

 

모두 애플리케이션에서는 “이름 해석 실패”로 보일 수 있지만 조사할 계층은 다르다.

---

ㅁ DNS는 UDP만 사용할까?

전통적인 DNS 질의는 주로 UDP Port 53을 사용한다.

UDP는 연결 설정 없이 질문과 답을 주고받을 수 있어 작은 DNS 메시지에 효율적이다.

그러나 DNS는 TCP Port 53도 사용한다.

• UDP 응답이 잘려 TC(Truncated) Flag가 설정되면 Client가 TCP로 다시 질의할 수 있다.
• 큰 DNSSEC 응답 등에서 TCP가 필요할 수 있다.
• Zone Transfer는 일반적으로 TCP를 사용한다.
• Resolver와 Server 구현은 필요에 따라 TCP를 직접 사용할 수 있다.

EDNS를 사용하면 UDP에서 더 큰 메시지 크기를 협상할 수 있지만 경로 MTU와 Fragment 처리 문제도 고려해야 한다.

따라서 Firewall에서 UDP 53만 허용하고 TCP 53을 모두 차단하면 작은 질의는 되지만 특정 큰 응답만 실패하는 장애가 생길 수 있다.

---

ㅁ DoH와 DoT는 무엇을 바꿀까?

전통적인 DNS는 질의 이름이 네트워크에서 평문으로 보일 수 있다.

암호화된 Resolver 전송 방식으로 다음 기술을 사용할 수 있다.

• DoT(DNS over TLS): DNS 메시지를 TLS로 보호하며 일반적으로 전용 Port 853 사용
• DoH(DNS over HTTPS): DNS 메시지를 HTTPS 위에서 전달

DoH와 DoT는 Client와 선택한 Resolver 사이의 DNS 전송을 암호화한다.

반면 DNSSEC은 DNS 데이터가 권한 있는 출처에서 왔고 중간에 변조되지 않았는지 검증하기 위한 서명 체계다.

DoH / DoT : DNS 질의 전송의 기밀성과 보호
DNSSEC    : DNS 데이터의 출처 인증과 무결성 검증

DNSSEC이 질의 내용을 암호화하는 것은 아니며,

DoH/DoT가 모든 DNS Record의 권한 체인을 자동으로 검증한다는 뜻도 아니다.

서로 다른 문제를 해결한다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
사용자가 주소 찾기를 요청하는 창구	Stub Resolver	애플리케이션의 이름 해석 요청을 DNS Resolver로 전달
여러 주소록을 대신 찾아보는 안내소	Recursive Resolver	Cache를 확인하고 필요한 DNS 계층 질의를 수행
최상위 분류 안내	Root Name Server	TLD Name Server로 가는 위임 정보를 제공
com, net 같은 구역 안내	TLD Name Server	하위 Domain의 권한 서버를 안내
해당 조직이 관리하는 공식 주소록	Authoritative Name Server	Zone의 권한 있는 Record를 응답
이름에 연결된 정보 한 줄	Resource Record	A, AAAA, CNAME, NS 등 DNS 데이터
답을 다시 사용해도 되는 기간	DNS TTL	Cache가 Record를 보관할 수 있는 시간
다음 주소록 담당자를 안내	Referral	하위 위임 영역의 NS 정보를 제공하는 응답
존재하지 않는 이름도 잠시 기록	Negative Caching	NXDOMAIN 같은 부정 응답을 Cache

 

일반적인 DNS 조회 흐름은 다음처럼 정리할 수 있다.

1. Application이 Stub Resolver에 이름 해석을 요청한다.
2. Stub은 설정된 Recursive Resolver에 질의한다.
3. Resolver는 먼저 Cache를 확인한다.
4. Cache Miss이면 Root → TLD → Authoritative 순으로 답을 찾는다.
5. Resource Record와 TTL을 Cache한다.
6. A/AAAA 주소를 Application에 돌려준다.
7. Application이 받은 IP 주소로 실제 연결을 시작한다.

---

ㅁ dig로 주소록의 답을 읽어 보기

DNS 진단 도구인 dig로 A Record를 조회한다.

dig example.com A

출력에서 다음 구역을 살펴본다.

HEADER     : Status, Flag, 질의 ID
QUESTION   : 물어본 이름과 Record Type
ANSWER     : 최종 Resource Record와 TTL
AUTHORITY  : 권한 또는 위임 관련 정보
ADDITIONAL : 관련 주소나 EDNS 정보

AAAA Record도 별도로 확인한다.

dig example.com AAAA

특정 Recursive Resolver에 직접 질의하려면 @Resolver-IP 형식을 사용한다.

dig @SERVER_IP example.com A

SERVER_IP는 확인하려는 Resolver의 실제 IP 주소로 바꾼다. 로컬 시스템이 사용하는 Resolver와 다른 서버에 물으면 Cache와 정책이 달라 결과도 다를 수 있다.

 

DNS 계층을 따라가는 모습을 확인한다.

dig +trace example.com

+trace는 dig가 Root부터 위임을 따라 직접 질의한다.

회사 방화벽이 외부 DNS Server로의 직접 질의를 막거나 네트워크 정책이 특정 Resolver만 허용하면 실패할 수 있다.

Linux에서 Resolver 설정을 확인한다.

cat /etc/resolv.conf
resolvectl status

systemd-resolved를 사용하지 않는 환경에서는 resolvectl이 없을 수 있다. 

/etc/resolv.conf도 로컬 Stub 주소만 가리키고 실제 Upstream Resolver는 별도 서비스 설정에 있을 수 있다.

 

macOS에서는 다음 명령으로 DNS Resolver 구성을 볼 수 있다.

scutil --dns

 

평문 DNS Packet을 관찰하려면 다음처럼 캡처할 수 있다.

sudo tcpdump -n -i eth0 'port 53'

 

DoH를 사용하는 애플리케이션의 질의는 HTTPS Traffic으로 보이므로 이 Filter에서 DNS 이름이 보이지 않을 수 있다.

---

ㅁ 핵심 정리

• DNS는 계층적 이름 공간, 권한 위임, Cache를 사용해 인터넷 규모의 이름 조회를 제공한다.
• 애플리케이션은 Stub Resolver를 통해 Recursive Resolver에 최종 답을 요청한다.
• Cache Miss이면 Resolver는 Root, TLD, Authoritative Name Server의 위임을 따라 답을 찾는다.
• A와 AAAA는 주소, CNAME은 별칭, NS는 권한 서버 등 Record Type마다 역할이 다르다.
• DNS TTL은 Cache 보관 시간이며 IPv4 Packet의 TTL과 다른 개념이다.
• 이미 Cache된 이전 답은 권한 Record를 수정해도 남은 TTL 동안 사용될 수 있다.
• 존재하지 않는다는 답도 Negative Caching의 대상이 될 수 있다.
• 여러 A/AAAA Record가 있다고 자동으로 Health Check와 완전한 장애 조치가 보장되지는 않는다.
• NXDOMAIN, NODATA, SERVFAIL, Timeout, REFUSED는 서로 다른 실패다.
• DNS는 UDP 53뿐 아니라 TCP 53도 사용한다.
• DoH/DoT는 전송 암호화에, DNSSEC은 DNS 데이터의 출처 인증과 무결성에 초점을 둔다.

 

핵심 용어: DNS, FQDN, Label, Zone, Delegation, Stub Resolver, Recursive Resolver, Root Name Server, TLD Name Server, Authoritative Name Server, Referral, Resource Record, A, AAAA, CNAME, NS, MX, SOA, PTR, DNS TTL, Negative Caching, NXDOMAIN, SERVFAIL, DoH, DoT, DNSSEC

 

 

DNS는 이름을 주소로 바꾸는 한 대의 서버가 아니다. 권한을 나누고 답을 캐시해 전 세계가 함께 사용하는 분산 주소 체계다.

---

ㅁ 다음 이야기

DNS를 통해 example.com의 IP 주소를 알아냈다.

하지만 하나의 Server에서는 Web Server, SSH Server, Database처럼 여러 프로그램이 동시에 통신할 수 있다.

IP 주소가 건물을 찾았다면 그 안의 어느 창구에 데이터를 건네야 할까?

다음 글에서는 「한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?」라는 질문을 통해 Transport Layer, Port Number, Socket, Well-Known Port, Ephemeral Port와 5-Tuple을 살펴본다.