DNS란 무엇이며 어떻게 작동하는가

DNS는 Domain Name System의 약자로, 인터넷에서 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 처리하는 숫자 IP 주소로 변환하는 분산 데이터베이스 시스템이다. 브라우저 주소창에 naver.com이나 google.com을 입력하면 DNS가 해당 서버의 IP 주소를 찾아 네트워크 연결을 가능하게 한다. 이 과정이 없다면 사용자는 접속하려는 모든 웹사이트의 숫자 조합을 직접 외워야 한다.

이 시스템은 1983년에 처음 설계되었고, 지금까지 인터넷의 핵심 인프라로 작동한다. 기본적으로 UDP 53번 포트를 사용하며, 대부분의 쿼리는 여전히 평문으로 전송된다.

DNS는 인터넷의 전화번호부다

DNS를 인터넷의 전화번호부에 비유하는 이유는 간단하다. 사람은 이름을 기억하지만 전화기는 번호로 연결한다. 마찬가지로 사용자는 naver.com 같은 도메인 이름을 입력하고, 컴퓨터는 223.130.195.95 같은 IPv4 주소나 2001:db8::1 같은 IPv6 주소를 필요로 한다. DNS가 이 간극을 메운다.

도메인 이름은 계층적으로 구성된다. 오른쪽 끝의 .com, .net, .kr 같은 최상위 도메인(TLD)에서 시작해 왼쪽으로 하위 도메인이 붙는다. www.naver.com에서 com은 TLD, naver는 도메인, www는 호스트명이다. 이 트리 구조는 전 세계 수백만 개의 도메인을 효율적으로 관리하게 한다.

DNS는 어떻게 작동하는가

DNS 조회는 단순해 보이지만 뒤에서는 여러 서버가 단계적으로 협업한다. 브라우저에 digtrace.net을 입력했다고 가정해 보자. 먼저 운영체제의 로컬 캐시를 확인한다. 최근 방문 기록이 남아 있다면 즉시 IP를 반환하고 과정이 끝난다.

캐시에 없으면 재귀 리졸버(Recursive Resolver)로 요청이 전달된다. 이 리졸버는 보통 ISP가 운영하거나, Cloudflare의 1.1.1.1이나 Google의 8.8.8.8 같은 공용 DNS를 사용한다. 리졸버는 사용자 대신 전 세계를 뒤져 정답을 찾아낸다.

리졸버도 자체 캐시를 먼저 확인한다. TTL(Time to Live) 값만큼 결과를 저장해 두기 때문이다. 캐시에 없다면 본격적인 조회가 시작된다. 루트 네임서버에 문의하면 .net TLD를 관리하는 서버 위치를 알려준다. TLD 서버는 digtrace.net의 권한 있는 네임서버를 가리킨다. 마지막으로 권한 서버가 A 레코드(IPv4)나 AAAA 레코드(IPv6)를 담아 응답하면, 리졸버는 이를 캐시에 저장한 뒤 사용자의 브라우저에 전달한다.

이 전체 과정은 보통 20밀리초에서 120밀리초 사이에 완료된다. 캐시된 조회는 거의 즉시 끝난다. Cloudflare의 설명에 따르면, 이 계층적 구조는 인터넷의 확장성을 가능하게 하는 핵심 원리다.

권한 있는 서버와 재귀 리졸버의 차이

DNS 서버를 한 덩어리로 이해하면 혼란이 생긴다. 기능적으로 명확히 구분되는 두 종류가 존재한다.

재귀 리졸버는 사용자의 질문을 받아 끝까지 추적하는 중개자다. 여러 서버를 순회하며 최종 답을 찾고, 그 과정에서 비권위 응답(Non-authoritative Answer)을 캐시에 저장한다. 반면 권한 있는 네임서버(Authoritative Name Server)는 특정 도메인의 실제 레코드를 직접 보유한다. 도메인 소유자가 이를 설정하며, 질문이 오면 권위 있는 답변(Authoritative Answer)을 내놓는다.

또한 Forward DNS는 이름에서 IP로의 변환을 의미한다. 이와 반대로 Reverse DNS는 PTR 레코드를 통해 IP에서 도메인 이름을 역으로 찾는다. 메일 서버 스팸 필터링이나 로그 분석에서 자주 쓰인다. IP 주소의 기본 개념이 궁금하다면 IP 주소란 무엇인가를 참고할 수 있다.

DNSSEC과 암호화 DNS

전통적인 DNS는 설계상 보안을 고려하지 않았다.

UDP 53번 포트로 전송되는 평문 데이터는 중간에서 위·변조되기 쉽다. 이를 보완하기 위해 등장한 것이 DNSSEC과 암호화 DNS다.

DNSSEC(DNS Security Extensions)는 전자서명을 통해 레코드의 무결성을 검증한다. RRSIG, DNSKEY, DS 레코드가 연계되어 응답이 신뢰할 수 있는지 확인한다. 한국인터넷진흥원(KISA) 산하 KRNIC은 .kr 도메인에 DNSSEC 적용을 확대하고 있으며, KRNIC의 DNSSEC 원리 설명에서 기술적 세부 사항을 확인할 수 있다.

DNSSEC은 데이터 무결성을 보장하지만, 전송 구간 암호화는 하지 않는다. 따라서 DNSSEC과 DoH/DoT는 상호 보완적인 기술이다.

DoH(DNS over HTTPS)와 DoT(DNS over TLS)는 전송 구간 자체를 암호화한다. DoH는 HTTPS를, DoT는 TLS를 통해 쿼리를 감춰 ISP나 중간자가 사용자가 어떤 사이트에 접속하려는지 쉽게 알 수 없게 한다. 최신 브라우저와 운영체제는 이들 프로토콜을 점차 기본으로 채택하고 있다.

터미널에서 DNS를 확인하는 방법

이론을 직접 검증하는 가장 빠른 방법은 터미널을 여는 것이다. 대부분의 Linux와 macOS에는 dig가 기본 내장되어 있고, Windows에서는 nslookup을 사용할 수 있다.

naver.com의 A 레코드를 조회하려면 다음 명령을 실행한다.

dig naver.com A

출력 결과는 다음과 비슷하다.

; <<>> DiG 9.18 <<>> naver.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
naver.com.		300	IN	A	223.130.195.95

;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jul 21 10:00:00 KST 2026

여기서 ANSWER SECTION의 A 레코드가 권한 있는 서버가 제공하는 실제 IP다. Query time은 해당 조회에 걸린 시간이며, SERVER는 사용한 리졸버를 보여준다.

DNS 전파 상태를 확인하거나 전 세계 여러 지점에서 동일한 도메인의 응답을 비교하려면 DNS 체커 도구를 병행하면 편리하다.

MX 레코드(메일 서버)를 확인하려면 타입을 바꾸기만 하면 된다.

dig naver.com MX

PTR 레코드로 역방향 조회를 수행할 때는 IP 주소를 뒤집어 in-addr.arpa 도메인에 질의한다.

dig -x 223.130.195.95

DNS가 중요한 이유

DNS는 눈에 보이지 않는다.

그러나 인터넷의 모든 통신은 이 시스템 위에서 이루어진다. 잘못된 A 레코드 설정은 웹사이트 접속 장애를, 잘못된 MX 레코드는 메일 수신 실패를 유발한다. TTL 값이 너무 길면 긴급한 IP 변경 시 전파 지연이 생기고, 너무 짧으면 리졸버 부하가 커진다.

기업은 자체 네임서버를 운영하거나 AWS Route 53, Cloudflare 같은 신뢰할 수 있는 제공자를 선택해 가용성을 높여야 한다. Anycast 네트워크를 활용하면 사용자가 물리적으로 가까운 서버로 연결되어 지연을 최소화할 수 있다.

보안 측면에서는 DNSSEC 미적용 도메인이 캐시 포이즈닝 공격에 취약하다. 특히 .kr 도메인을 운영한다면 KRNIC의 DS 레코드 위임 절차를 정확히 따라야 한다. 개인 사용자라도 공용 DNS와 DoH 설정만으로 피싱이나 하이재킹 위험을 줄일 수 있다.

DNS를 이해한다는 것은 인터넷이 어떻게 이름을 찾아 연결하는지를 아는 기초다. 이 지식 없이는 네트워크 장애를 추적하거나 도메인 보안을 제대로 다루기 어렵다.