DNS 조회 과정: 스텁 리졸버·재귀 리졸버·권한 서버의 역할

브라우저에 도메인을 입력했을 때 한 대의 “DNS 서버”가 이름을 IP 주소로 바꿔 주는 것은 아니다. 보통 운영체제의 스텁 리졸버가 재귀 리졸버에 질문하고, 재귀 리졸버가 캐시 또는 권한 서버 계층을 따라 답을 구한 뒤 클라이언트에 돌려준다.

DNS는 A·AAAA 주소만 찾는 시스템도 아니다. MX, TXT, SRV, CNAME 등 이름에 연결된 여러 종류의 리소스 레코드를 조회한다. 각 구성 요소의 역할을 분리해야 장애가 클라이언트, 캐시, 위임과 권한 데이터 중 어디에 있는지 좁힐 수 있다.

같은 ‘DNS 서버’라도 역할이 다르다

DNS 표준 문서에서도 authoritative server와 recursive resolver를 모두 DNS server 또는 name server라고 부를 수 있다고 설명한다. 이름보다 제공하는 기능을 확인하는 편이 정확하다.

구성 요소	주로 있는 곳	하는 일
스텁 리졸버	운영체제·애플리케이션	재귀 리졸버에 질의를 맡기고 결과를 받는다.
재귀 리졸버	통신사·회사·공용 DNS	캐시를 확인하고 필요하면 다른 DNS 서버를 질의해 최종 답을 구한다.
루트 서버	DNS 루트 계층	최상위 도메인 서버로 가는 위임 정보를 제공한다.
TLD 권한 서버	.com, .kr 같은 영역	하위 도메인의 권한 서버로 가는 위임 정보를 제공한다.
권한 서버	해당 DNS zone의 운영 영역	자신이 권한을 가진 zone의 레코드 또는 위임을 답한다.

권한 서버는 특정 zone의 원본 데이터를 서비스한다. 재귀 리졸버는 클라이언트를 대신해 답을 구하고 캐시한다. 한 제품이 두 역할을 모두 구현할 수 있지만, 논리적 책임은 다르다.

example.com을 찾는 순서

캐시에 답이 없다고 단순화하면 흐름은 다음과 같다.

애플리케이션
  ↓
운영체제 스텁 리졸버
  ↓ 재귀 질의
재귀 리졸버
  ↓ 반복 질의
루트 → .com TLD → example.com 권한 서버
  ↑
최종 응답과 위임 정보
  ↓
캐시에 저장한 뒤 클라이언트에 반환

1. 애플리케이션이 운영체제 이름 해석 API를 호출한다.
2. 스텁 리졸버가 설정된 재귀 리졸버로 질의를 보낸다.
3. 재귀 리졸버는 자신의 캐시를 먼저 본다.
4. 캐시에 없으면 루트에서 TLD, TLD에서 도메인의 권한 서버를 안내받는다.
5. 권한 서버의 답을 받아 TTL 범위에서 캐시하고 스텁에 반환한다.

재귀 리졸버가 루트부터 매 요청마다 다시 시작하는 것은 아니다. NS·주소와 최종 응답을 캐시하므로 실제 조회는 중간 단계부터 이어질 수 있다.

재귀 질의와 반복 질의의 차이

스텁 리졸버는 보통 “최종 답이나 오류를 구해 달라”는 재귀 질의를 보낸다. 요청의 RD(Recursion Desired) 비트와 응답의 RA(Recursion Available) 비트로 재귀 서비스 요청과 제공 여부를 확인할 수 있다.

재귀 리졸버가 권한 계층을 따라갈 때는 반복 질의를 사용한다. 각 서버는 자신이 가진 답을 주거나 다음에 물어볼 서버를 referral로 알려 준다.

스텁 → 재귀 리졸버: 최종 답을 구해 주세요.
재귀 리졸버 → 권한 계층: 답 또는 다음 위임을 알려 주세요.

따라서 “리졸버는 클라이언트에서 실행된다”는 문장은 스텁 리졸버에는 맞을 수 있지만, 재귀 리졸버까지 설명하지는 못한다.

캐시와 TTL을 어떻게 읽을까

DNS 응답의 TTL은 재귀 리졸버가 그 레코드를 캐시할 수 있는 남은 시간을 나타낸다. TTL이 끝나기 전에는 권한 서버의 값이 바뀌어도 이전 응답이 보일 수 있다.

dig example.com A

ANSWER SECTION의 숫자는 그 응답에서 보이는 TTL이다. 같은 리졸버에 다시 질의하면 캐시된 레코드의 TTL이 줄어드는 모습을 볼 수 있다.

오류도 일부 캐시된다. 존재하지 않는 이름인 NXDOMAIN과 이름은 있지만 요청한 타입의 데이터가 없는 응답은 구분해야 한다. “IP가 안 나왔다”만으로 도메인이 존재하지 않는다고 판단하면 안 된다.

DNS는 UDP만 쓰다가 512바이트를 넘으면 TCP로 바뀌는가

이 설명은 현재 DNS를 지나치게 단순화한다. 전통적인 DNS over UDP는 512바이트 제한이 있었지만 EDNS(0)는 클라이언트가 더 큰 UDP 응답 크기를 알릴 수 있게 했다. 그러므로 응답이 512바이트를 넘는다는 이유만으로 항상 TCP가 되는 것은 아니다.

일반적인 흐름은 다음과 같다.

• 짧은 질의·응답은 UDP로 처리되는 경우가 많다.
• EDNS(0)를 사용하면 512바이트보다 큰 UDP 응답을 협상할 수 있다.
• UDP 응답의 TC(Truncated) 비트가 설정되면 클라이언트가 TCP로 다시 질의할 수 있다.
• 권한 서버와 재귀 리졸버는 DNS over TCP를 지원해야 한다.
• AXFR 같은 전체 zone transfer는 TCP를 사용한다.

DNSSEC 응답이 커질 수 있다는 사실도 “DNSSEC이면 TCP”를 뜻하지 않는다. EDNS 크기, 네트워크 경로, 조각화 회피와 응답 잘림 여부가 함께 작용한다.

dig로 역할별 답을 비교하기

먼저 현재 설정된 재귀 리졸버에 질의한다.

dig example.com A

특정 재귀 리졸버를 지정하려면 @서버를 붙인다.

dig @1.1.1.1 example.com A

위임 경로를 학습 목적으로 따라가려면 다음을 쓸 수 있다.

dig +trace example.com A

+trace는 로컬에서 반복 질의를 흉내 내므로 평소 사용하는 재귀 리졸버의 캐시·정책·검증 경로와 결과가 완전히 같다고 보장하지 않는다.

권한 서버를 찾은 뒤 직접 물으면 재귀 경로와 권한 데이터를 분리할 수 있다.

dig example.com NS
dig @a.iana-servers.net example.com A +norecurse

실제 도메인에는 해당 도메인의 NS 응답에 나온 서버를 사용한다. 결과를 볼 때는 다음 항목을 함께 확인한다.

• 응답 코드: NOERROR, NXDOMAIN, SERVFAIL, REFUSED
• 플래그: aa, rd, ra, tc, ad
• Answer와 Authority 섹션
• TTL과 응답한 서버

장애를 좁히는 순서

1. 같은 이름을 다른 재귀 리졸버에서도 조회한다.
2. A와 AAAA, CNAME 등 요청 타입을 분리한다.
3. +trace로 위임이 끊기는 지점을 찾는다.
4. 권한 서버에 +norecurse로 직접 질의한다.
5. TTL 때문에 예전 응답이 남았는지 확인한다.
6. SERVFAIL이면 DNSSEC 검증 실패와 권한 서버 오류를 포함해 원인을 더 본다.

IP 패킷이 권한 서버까지 가는 경로와 DNS 위임 경로는 같은 개념이 아니다. IP 라우팅은 라우팅과 포워딩의 차이, DNS와 함께 쓰이는 네트워크 계층 프로토콜은 IP·ICMP·ARP·DHCP 정리에서 이어서 볼 수 있다.

참고 자료

• RFC 9499: DNS Terminology
• RFC 9199: 권한 DNS 서버와 재귀 리졸버의 관계
• RFC 6891: Extension Mechanisms for DNS, EDNS(0)
• RFC 7766: DNS Transport over TCP