브라우저와 운영체제에 사용할 답이 없다고 가정해 보겠습니다. 사용자가 입력한 호스트는 www.example.com입니다. 내 컴퓨터가 전 세계의 DNS 서버를 직접 돌아다니며 답을 모을 수도 있을 것 같지만, 일반적인 구성에서는 로컬의 스텁 리졸버가 설정된 재귀 리졸버에 일을 맡깁니다.
사용자의 질문은 단순합니다.
www.example.com의 주소 레코드를 알려 주세요.
하지만 이 질문의 정답은 한곳에 모여 있지 않습니다. 루트 존은 .com 아래의 모든 호스트 주소를 가지고 있지 않고, .com을 담당하는 서버도 www.example.com의 최종 주소를 직접 관리하지 않습니다. DNS는 이름 공간의 관리 권한을 여러 단계로 나눈 분산 시스템입니다. 재귀 리졸버는 각 단계에서 “정답은 내가 아니라 다음 담당자에게 물어보라”는 위임을 받아 최종 답에 접근합니다.
사용자는 맡기고, 리졸버는 찾아갑니다
먼저 두 종류의 질의를 구분해야 합니다.
재귀 질의(recursive query)는 요청한 답을 가능한 범위에서 완성해 달라는 부탁입니다. 사용자의 스텁 리졸버는 보통 재귀 리졸버에 이런 요청을 보냅니다. 재귀 리졸버는 자기 캐시에 답이 있으면 바로 돌려주고, 없으면 다른 DNS 서버에 질문해 결과를 완성합니다.
반복 질의(iterative query)는 현재 서버가 아는 최선의 정보를 받는 방식입니다. 서버가 최종 답을 가지고 있지 않으면 다음에 물어볼 권한 서버의 정보를 돌려줄 수 있습니다. 재귀 리졸버는 이 위임을 따라 루트 네임서버, 최상위 도메인 서버, 권한 있는 DNS 서버에 차례로 접근합니다.
이름 때문에 두 과정을 뒤집어 이해하기 쉽습니다. 사용자의 질문이 한 번만 보인다고 해서 재귀가 아닌 것이 아닙니다. 반대로 리졸버가 여러 서버에 차례로 질문한다고 해서 그 모든 질문을 재귀 질의라고 부르는 것도 아닙니다. 핵심은 누가 답을 완성할 책임을 맡았느냐입니다.
| 구분 | 요청의 뜻 | 대표 주체 |
|---|---|---|
| 재귀 질의 | “최종적으로 사용할 답을 완성해 주세요.” | 스텁 리졸버 → 재귀 리졸버 |
| 반복 질의 | “당신이 아는 답이나 다음 담당자를 알려 주세요.” | 재귀 리졸버 → 권한 계층의 DNS 서버 |
실제 DNS 동작은 캐시, 병렬 질의, IPv4·IPv6, DNSSEC 검증, 네트워크 실패 대응 때문에 더 복잡할 수 있습니다. 여기서는 위임 구조를 이해하기 위한 대표 흐름을 따라갑니다.
첫 번째 안내자: 루트 네임서버
재귀 리졸버는 DNS 루트에 대한 기본 정보를 미리 가지고 시작합니다. www.example.com을 오른쪽부터 보면 마지막의 점으로 표현할 수 있는 루트 아래에 com, 그 아래에 example, 다시 그 아래에 www가 놓입니다.
리졸버가 루트 네임서버에 www.example.com의 A 레코드를 물으면 루트 서버가 최종 IP 주소를 답하는 것은 아닙니다. 루트는 .com 존을 담당하는 네임서버 정보를 알려 줍니다. 이것이 위임(referral)입니다.
전화번호 안내 비유로 말하면 루트는 모든 사람의 번호를 가진 안내원이 아니라 지역별 안내소의 연락처를 알려 주는 최상위 안내자입니다. 다만 DNS 루트는 한 대의 중앙 서버가 아닙니다. 논리적으로 정해진 루트 서버 식별자들이 여러 네트워크 위치에서 서비스됩니다.
재귀 리졸버는 루트의 위임 응답도 캐시에 보관할 수 있습니다. 그래서 실제 조회마다 루트에 묻는 것은 아닙니다. .com 담당 서버 정보를 이미 알고 있다면 첫 단계를 건너뜁니다. DNS 캐시가 웹사이트의 최종 주소만 저장하는 것이 아니라 탐색 중 얻은 위임 정보도 재사용한다는 점이 중요합니다.
두 번째 안내자: 최상위 도메인 서버
.com, .org, .kr처럼 이름 공간의 상위 구역을 최상위 도메인(Top-Level Domain, TLD)이라고 합니다. 리졸버가 .com의 권한 서버에 같은 질문을 보내면, TLD 서버는 example.com 존을 담당하는 권한 있는 DNS 서버의 정보를 알려 줍니다.
TLD 서버 역시 보통 www.example.com의 웹 서버 주소를 직접 관리하지 않습니다. example.com의 관리 주체가 지정한 네임서버가 어디인지 연결해 주는 역할을 합니다. DNS의 분산 구조는 이렇게 관리 경계를 나눕니다. 루트 운영자가 개별 쇼핑몰의 주소 변경을 처리하지 않고, TLD 운영자도 각 호스트의 레코드를 대신 수정하지 않습니다.
마지막 담당자: 권한 있는 DNS 서버
권한 있는 DNS 서버(authoritative DNS server)는 특정 존에 대해 관리 주체가 설정한 데이터를 바탕으로 권한 있는 응답을 제공합니다. 재귀 리졸버가 example.com 존의 권한 서버에 www.example.com의 A 레코드를 물으면, 이 서버는 최종 주소 레코드나 별칭, 또는 해당 데이터가 없다는 응답을 돌려줄 수 있습니다.
최종 답이 다음과 같다고 가정해 보겠습니다.
www.example.com. 3600 IN A 192.0.2.80
여기에는 이름, TTL, 인터넷 클래스, 레코드 유형, IPv4 주소가 담겨 있습니다. 재귀 리졸버는 이 결과를 요청한 스텁 리졸버에 돌려주고 TTL에 따라 캐시에 저장할 수 있습니다. 브라우저는 전달받은 후보 주소를 사용해 다음 단계의 연결을 시도합니다.
AAAA 레코드를 함께 물었다면 IPv6 주소도 받을 수 있습니다. CNAME이 답으로 오면 별칭이 가리키는 이름의 주소를 추가로 해석해야 할 수 있습니다. 실제 응답은 하나의 값보다 풍부하며, 리졸버가 여러 질의와 캐시 항목을 조합해 애플리케이션에 필요한 결과를 제공합니다.
대표 흐름을 한 번에 정리하면
1. 스텁 리졸버가 재귀 리졸버에 www.example.com의 답을 맡깁니다.
2. 재귀 리졸버가 캐시를 확인합니다.
3. 필요한 위임 정보가 없으면 루트 네임서버에서 .com 담당자를 안내받습니다.
4. .com 권한 서버에서 example.com 담당자를 안내받습니다.
5. example.com 권한 서버에서 최종 레코드 또는 부정 응답을 받습니다.
6. 재귀 리졸버가 결과를 캐시하고 스텁 리졸버에 답합니다.
리졸버가 이전 조회에서 얻은 위임 정보를 가지고 있으면 중간 단계를 생략합니다. 사용자가 매번 계층 전체의 지연을 부담하지 않는 이유가 캐시에 있습니다.
‘없다’에도 두 가지가 있습니다
DNS 조회가 성공했다는 말은 반드시 IP 주소를 받았다는 뜻이 아닙니다. 권한 서버가 “그 이름은 존재하지 않는다”거나 “이름은 있지만 요청한 형식의 데이터는 없다”고 확정적으로 알려 주는 것도 유효한 DNS 응답입니다.
NXDOMAIN(Non-Existent Domain)은 질의한 이름 자체가 존재하지 않음을 뜻합니다. 예를 들어 오타가 난 wwww.example.com이라는 이름이 존에 없다면 NXDOMAIN 응답을 받을 수 있습니다.
NODATA는 이름은 존재하지만 요청한 유형의 레코드가 없는 상황을 가리킵니다. service.example.com에 A 레코드는 있지만 AAAA 레코드는 없다면, AAAA 질문에 이름 부재가 아니라 해당 데이터 부재를 나타내는 응답이 올 수 있습니다.
| 결과 | 이름 존재 여부 | 요청한 레코드 유형 | 조사 방향 |
|---|---|---|---|
| 주소 응답 | 존재 | 존재 | 받은 주소와 TTL 확인 |
| NODATA | 존재 | 없음 | 레코드 유형과 존 설정 확인 |
| NXDOMAIN | 없음 | 해당 없음 | 이름 오타·삭제·위임 범위 확인 |
둘을 구분하면 장애 보고가 달라집니다. “DNS가 실패했습니다”보다 “이름 자체가 NXDOMAIN입니다” 또는 “이름은 존재하지만 AAAA 레코드가 없습니다”가 훨씬 구체적입니다. 특히 IPv4에서는 열리는데 IPv6 구성만 기대와 다를 때 NODATA와 연결 실패를 구분해야 합니다.
없는 답도 캐시하는 이유
존재하는 레코드만 캐시한다면 오타가 난 이름이나 존재하지 않는 이름에 대한 질문이 반복될 때마다 권한 서버까지 같은 탐색이 이어집니다. 이를 줄이기 위해 DNS는 부정적인 결과도 저장합니다. 이를 음성 캐시(negative caching)라고 합니다.
NXDOMAIN과 NODATA 같은 권한 있는 부정 응답에는 보통 SOA(Start of Authority) 정보가 관여합니다. RFC 2308에 따르면 음성 캐시에 사용할 TTL은 응답에 포함된 SOA 레코드의 TTL과 SOA.MINIMUM 값 중 작은 값으로 정해집니다. 따라서 “없는 주소는 무조건 5분 저장된다”처럼 하나의 시간을 모든 도메인에 적용할 수 없습니다.
음성 캐시는 운영 중 예상 밖의 현상을 만듭니다. 새 호스트 이름을 만들기 전에 누군가 그 이름을 조회해 NXDOMAIN을 받았다고 가정해 보겠습니다. 관리자가 곧바로 레코드를 추가해도 해당 부정 응답을 저장한 재귀 리졸버는 음성 TTL이 남아 있는 동안 이전의 ‘없음’을 돌려줄 수 있습니다. 레코드를 추가했는데 일부 사용자에게만 계속 존재하지 않는다고 보이는 이유가 여기에 있을 수 있습니다.
대응할 때는 권한 서버의 새 레코드를 먼저 확인하고, 문제가 있는 사용자의 재귀 리졸버와 NXDOMAIN의 남은 TTL을 살펴야 합니다. 브라우저 캐시만 지우는 처방으로는 재귀 리졸버의 음성 캐시가 바뀌지 않을 수 있습니다.
권한 있는 ‘없음’과 일시적 실패는 다릅니다
NXDOMAIN은 이름이 없다는 권한 있는 답입니다. 반면 SERVFAIL이나 시간 초과는 리졸버가 답을 완성하지 못했다는 실패입니다. 권한 서버에 일시적으로 닿지 못했거나, DNSSEC 검증이 실패했거나, 네트워크 문제가 생긴 경우 등 원인은 다양합니다.
실패를 전혀 캐시하지 않으면 같은 문제가 발생하는 동안 리졸버와 권한 서버가 즉시 반복 질의로 몰릴 수 있습니다. RFC 9520은 DNS 해석 실패를 일정 시간 캐시하도록 기준을 정리하며, 실패 캐시 시간을 최소 1초에서 최대 5분 범위로 제한합니다. 이 값은 NXDOMAIN의 음성 TTL과 같은 규칙이 아닙니다.
따라서 다음 세 상황을 하나로 묶지 않아야 합니다.
- NXDOMAIN: 이름이 존재하지 않는다는 권한 있는 응답
- NODATA: 이름은 존재하지만 요청한 유형의 데이터가 없다는 응답
- 해석 실패: 답을 완성하지 못한 일시적 또는 검증 관련 실패
DNSSEC은 질문을 숨기지 않습니다
DNS 응답이 전달되는 도중 조작되지 않았는지, 신뢰할 수 있는 서명 체인을 통해 확인할 필요가 있습니다. DNSSEC(Domain Name System Security Extensions)은 DNS 데이터에 디지털 서명을 적용하고 검증자가 신뢰 사슬을 따라 응답의 출처와 무결성을 확인할 수 있게 합니다.
DNSSEC의 역할은 DoH·DoT와 다릅니다. DoH와 DoT는 주로 클라이언트와 선택한 리졸버 사이의 전송 구간을 암호화합니다. DNSSEC은 DNS 데이터가 권한 관리자가 제공한 내용과 일치하는지 검증하는 데 초점을 둡니다. DNSSEC을 사용한다고 질의 이름과 응답 내용이 암호화되어 보이지 않게 되는 것은 아닙니다.
| 기술 | 주된 질문 | 제공하는 핵심 가치 |
|---|---|---|
| DoT·DoH | 전달 구간에서 누가 질의와 응답을 볼 수 있는가? | 클라이언트와 리졸버 사이 전송 보호 |
| DNSSEC | 받은 DNS 데이터가 권한 있는 데이터와 일치하는가? | 출처 인증과 무결성 검증 |
두 기술은 경쟁 관계가 아니라 서로 다른 위협을 다룹니다. ‘보안 DNS’라는 한 단어로 합치기보다 무엇을 어느 구간에서 보호하는지 물어야 합니다. DNSSEC 서명이나 상위 존의 위임 정보가 어긋나면 검증 리졸버는 답을 실패로 처리할 수 있습니다.
실무에서 경로를 확인하는 순서
새 도메인이 일부 사용자에게만 열리지 않는 상황을 조사해 보겠습니다. 무작정 기다리거나 브라우저 캐시를 지우기 전에 질문을 층별로 나눕니다.
1. 질문 자체를 확인합니다
정확히 어떤 이름과 레코드 유형을 물었는지 확인합니다. example.com과 www.example.com, A와 AAAA 질문은 각각 다릅니다. URL의 경로 오류는 DNS 문제가 아닙니다.
2. 재귀 리졸버의 답을 비교합니다
회사 DNS, VPN DNS, 브라우저 DoH 중 실제로 사용한 재귀 리졸버를 확인합니다. 다른 리졸버의 답과 TTL을 비교하면 특정 캐시 문제인지 좁힐 수 있습니다.
3. 권한 서버의 답을 확인합니다
권한 있는 DNS 서버의 현재 응답과 서버 간 일치 여부를 확인합니다. 관리 화면에 새 값이 보인다는 사실만으로 실제 권한 응답까지 모두 갱신됐다고 단정하지 않습니다.
4. 위임과 DNSSEC을 확인합니다
상위 존이 의도한 권한 서버를 안내하는지 확인합니다. DNSSEC을 사용한다면 서명과 상위 존의 DS 레코드도 검증합니다.
5. 결과의 성격과 남은 시간을 구분합니다
오래된 주소 응답, NXDOMAIN, NODATA, SERVFAIL을 구분합니다. 양성 캐시, 음성 캐시, 실패 캐시는 서로 다른 규칙을 따릅니다.
담당자에게는 호스트 이름, 레코드 유형, 재귀 리졸버, 응답 코드와 TTL, 권한 서버의 답, 발생 시각을 함께 전달합니다. 이 정보가 있으면 같은 현상을 재현하지 못해도 조사할 수 있습니다.
DNS가 끝나도 웹페이지는 아직 오지 않았습니다
재귀 리졸버가 주소를 돌려주면 첫 번째 큰 탐색은 끝납니다. 하지만 브라우저가 받은 것은 웹페이지가 아니라 연결 후보입니다. 해당 IP 주소의 어떤 포트로 갈지, 네트워크 경로가 열려 있는지, 신뢰할 수 있는 통신 상대인지 아직 확인해야 합니다.
DNS 응답이 빠르다고 웹페이지가 반드시 빠른 것도 아니고, DNS가 성공했다고 서버 연결이 보장되는 것도 아닙니다. 주소가 과거 서버를 가리킬 수 있고, 방화벽이 포트를 막을 수 있으며, 서버가 연결을 받지 못할 수도 있습니다. DNS는 릴레이의 첫 구간을 마쳤을 뿐 다음 주자의 성공까지 약속하지 않습니다.
이름은 이제 주소가 됐습니다. 그렇다면 손실되고 순서가 뒤바뀔 수 있는 환경에서 TCP는 어떻게 신뢰할 수 있는 바이트 흐름을 만들어 낼까요. 3장의 질문입니다.
도해 2. 재귀 리졸버와 반복 조회
도해 2. 재귀 리졸버와 반복 조회
사용자는 재귀 리졸버에 답을 맡기고, 재귀 리졸버는 캐시가 없을 때 루트→TLD→권한 있는 DNS 서버의 위임을 따라 반복 질의합니다.
이 장의 근거 문서
- RFC 1034·1035 — 위임 구조와 재귀·반복 질의
- RFC 2308 — 부정 응답의 캐시와 TTL 결정
- RFC 9520 — 해석 실패의 캐시 기준
- RFC 4033·4034·4035 — DNSSEC이 보호하는 것과 보호하지 않는 것
