DNS의 원리 (1) - DNS의 탄생과 계층 구조 - soo:bak

작성일 : 2026년 01월 20일

인터넷의 전화번호부

웹 브라우저에 google.com을 입력하면 구글 서버에 연결됩니다.

하지만 IP 주소에서 살펴보았듯이, 실제 통신에는 142.250.196.110 같은 숫자 주소가 필요합니다.

google.com은 어떻게 142.250.196.110이 되는 걸까요?

이 변환을 담당하는 시스템이 DNS(Domain Name System)입니다.

단순한 이름 변환이 아니라, 전 세계 수억 개의 도메인을 처리하는 분산 데이터베이스입니다.

DNS가 등장하기 전에는 어떤 방식으로 이름을 관리했을까요?

HOSTS.TXT 시대

초기 ARPANET

1970년대 ARPANET(미국 국방부가 구축한 초기 컴퓨터 네트워크)에는 수십~수백 대의 컴퓨터가 연결되어 있었습니다. 각 컴퓨터의 이름과 주소는 HOSTS.TXT라는 하나의 파일에 저장되었고, 형식은 다음과 같았습니다.

# HOSTS.TXT 예시
HOST : 10.0.0.73  : SRI-NIC  : FOONLY-F3  : TENEX :
│      │            │          │             └ 운영체제
│      │            │          └ 하드웨어
│      │            └ 호스트 이름
│      └ IP 주소
└ 항목 유형

# 실제 파일에는 이런 항목들이 나열됩니다.
HOST : 10.0.0.73  : SRI-NIC  : FOONLY-F3  : TENEX :
HOST : 10.3.0.77  : MIT-AI   : DEC-2060   : TOPS20 :
HOST : 10.0.0.51  : SRI-KL   : DEC-2060   : TOPS20 :

이 파일은 SRI-NIC(Stanford Research Institute - Network Information Center)라는 기관이 관리했습니다.

새 호스트를 추가하려면 SRI-NIC 관리자에게 이메일이나 전화로 요청해야 했고, 파일이 업데이트되면 각 사이트가 FTP(File Transfer Protocol)로 내려받는 구조였습니다.

확장성의 한계

네트워크가 성장하면서 이 방식은 여러 한계에 부딪혔습니다.

이름 충돌: HOSTS.TXT의 모든 이름은 하나의 목록에 있었으므로, 같은 이름이 두 개 있으면 어느 컴퓨터를 가리키는지 알 수 없었습니다. 이름은 전체에서 유일해야 했지만 분쟁을 조정할 권한을 가진 기관은 없었고, 조직이 늘어날수록 원하는 이름이 이미 등록되어 있을 가능성이 높아졌습니다.

업데이트 지연: 새 호스트 등록에 며칠이 걸렸고, 등록 후에도 모든 사이트가 새 파일을 받기까지 또 시간이 필요했습니다. 호스트가 늘어날수록 등록 요청이 쌓여 대기 시간은 더 길어졌습니다.

트래픽 폭증: 호스트 수가 늘면 파일 크기도 커졌고, 새 호스트가 추가될 때마다 최신 파일을 다시 받아야 했습니다. 호스트가 많을수록 변경도 잦아졌으므로 다운로드 빈도와 트래픽이 함께 증가했습니다.

단일 장애점: SRI-NIC 한 곳이 모든 등록을 처리했으므로, SRI-NIC의 서버에 장애가 발생하면 새 호스트를 등록할 수 없었습니다. 네트워크에 참여하는 조직이 늘어날수록, 이 한 곳의 장애가 미치는 영향도 커졌습니다.

1983년 ARPANET이 기존 통신 규약(NCP)에서 TCP/IP로 전환한 이후, 네트워크는 급속히 성장하고 있었습니다.

수백 대가 아니라 수만, 수십만 대로 늘어날 네트워크를 HOSTS.TXT 방식으로는 감당할 수 없었습니다.

DNS의 탄생

Paul Mockapetris와 RFC 882/883

1983년 11월, Paul Mockapetris는 RFC 882와 RFC 883을 통해 DNS를 제안했습니다.

DNS는 HOSTS.TXT의 문제를 근본적으로 해결하기 위해 설계된 새로운 시스템이며, 세 가지 핵심 아이디어를 기반으로 합니다.

계층적 네임스페이스(Hierarchical Namespace): 이름 충돌을 해결합니다. 평면적 목록 대신 계층 구조로 이름을 체계화하면, mit.edu와 stanford.edu는 별개의 도메인이 됩니다. 각각 mailserver.mit.edu와 mailserver.stanford.edu를 자유롭게 사용할 수 있습니다.

분산 데이터베이스(Distributed Database): 단일 장애점과 업데이트 지연을 해결합니다. 하나의 서버가 모든 정보를 갖는 대신, 각 도메인의 관리 주체가 자신의 서버에서 해당 정보를 직접 관리합니다.

캐싱(Caching): 트래픽 폭증을 해결합니다. 조회 결과에 유효 기간을 두어 재사용하므로, 수천 명이 같은 도메인에 접속하더라도 원본 서버에는 처음 한 번만 질의가 전달됩니다.

Mockapetris는 최초의 DNS 서버를 직접 구현했습니다.

1984년에는 UC Berkeley에서 Unix용 구현체인 BIND(Berkeley Internet Name Domain)가 만들어졌으며, 오늘날에도 가장 널리 사용되는 DNS 서버 중 하나입니다.

RFC 1034/1035

1987년에는 RFC 1034(개념과 기능)와 RFC 1035(구현과 명세)가 발표되어 DNS의 표준이 정립되었습니다. 이후 수많은 확장 표준이 추가되었지만, 이 두 문서가 여전히 DNS의 기반입니다.

계층적 네임스페이스

도메인 이름의 구조

HOSTS.TXT에서는 모든 이름이 하나의 목록에 있었습니다. DNS는 이 목록을 트리 구조로 바꿨습니다.

이 트리 구조는 도메인 이름에서 바로 확인할 수 있습니다. 점(.)이 계층을 구분하고, 점 사이의 각 부분을 레이블(label)이라고 합니다.

www . example . com .
└─┘   └──────┘  └─┘ │
 │       │       │   └── 루트(보통 생략)
 │       │       └────── 최상위 도메인(TLD)
 │       └────────────── 2차 도메인
 └────────────────────── 3차 도메인

www.example.com.에서 마지막 점이 루트(root)입니다. 루트에서 왼쪽으로 갈수록 더 구체적인 이름이 됩니다. 일반적인 표기에서는 이 마지막 점을 생략합니다.

각 레이블은 최대 63자, 전체 이름은 최대 253자이며, 대소문자를 구분하지 않습니다(Example.COM = example.com).

도메인 트리

모든 도메인 이름은 하나의 거대한 트리(나무) 구조로 연결됩니다. 루트를 꼭대기에 놓고 아래로 내려갈수록 더 구체적인 이름이 되는 형태입니다.

                        . (root)
                        │
         ┌──────────────┼──────────────┐
         │              │              │
        com            org            kr
         │              │              │
    ┌────┴────┐        │         ┌────┴────┐
    │         │        │         │         │
  google   example  wikipedia   co       go
    │         │        │         │         │
   www       www      www      naver    korea
                                 │
                                www

위 트리에서 리프(leaf)부터 루트까지 거슬러 올라가면 우리가 아는 도메인 이름이 됩니다.

예를 들어, 왼쪽 아래 www에서 위로 올라가면 www.google.com.이 되고, 오른쪽 아래 www에서 올라가면 www.naver.co.kr.이 됩니다.

루트(Root): 트리의 최상위이며, 모든 도메인 이름 조회의 출발점입니다. 전 세계에 13개의 루트 서버(A-root ~ M-root)가 있고, 각 루트 서버는 여러 지역에 복제본을 두어 분산 운영되고 있습니다.

최상위 도메인(TLD, Top-Level Domain): 루트 바로 아래의 첫 번째 계층으로, 도메인 이름의 가장 큰 분류입니다.

유형	예시	설명
gTLD(generic)	com, org, net	용도별로 구분한 일반 최상위 도메인
ccTLD(country-code)	kr, jp, uk	국가·지역별 최상위 도메인
sTLD(sponsored)	edu, gov, mil	특정 기관이 사용 자격을 관리하는 최상위 도메인
new gTLD	blog, app, dev	2013년 이후 추가된 일반 최상위 도메인

2차 도메인(Second-Level Domain): TLD 아래에서 조직이나 개인이 등록하는 이름입니다. google.com에서 google에 해당합니다.

서브도메인(Subdomain): 2차 도메인 아래로 도메인 소유자가 자유롭게 만들 수 있습니다. mail.google.com, maps.google.com 등이 있습니다.

FQDN

DNS 이름은 절대적 이름과 상대적 이름으로 나뉩니다.

마지막에 점(.)을 붙여 루트 도메인까지 명시한 전체 이름을 FQDN(Fully Qualified Domain Name)이라고 하며, 어떤 맥락에서든 항상 같은 대상을 가리킵니다.

반면 상대적 이름(relative name)은 불완전한 이름으로, 현재 도메인에 따라 가리키는 대상이 달라집니다.

같은 www라도 example.com 안에서는 www.example.com.이 되고, google.com 안에서는 www.google.com.이 됩니다.

www.example.com.     ← FQDN (마지막 점이 루트를 나타냄)
www.example.com      ← 일반적인 표기 (마지막 점 생략)
www                  ← 상대적 이름 (현재 도메인에 따라 대상이 달라짐)

DNS 설정 파일(Zone File)에서는 이 구분이 중요합니다. 마지막 점이 없는 이름은 상대적 이름으로 취급되어, 현재 도메인이 자동으로 붙기 때문입니다.

예를 들어, example.com의 Zone File에서 www.example.com에 IP 주소를 연결하려고 다음과 같이 작성했다고 가정합니다:

www.example.com   IN  A  93.184.216.34

의도는 “www.example.com의 IP 주소는 93.184.216.34이다”입니다.

하지만 www.example.com 뒤에 마지막 점이 없으므로, 이 이름 역시 상대적 이름으로 취급됩니다.

점이 중간에 포함되어 있더라도, 마지막 점이 없으면 FQDN이 아니기 때문입니다.

따라서 현재 도메인인 example.com이 자동으로 붙어, 실제로는 다음과 같이 해석됩니다:

www.example.com.example.com.   IN  A  93.184.216.34

의도한 www.example.com이 아니라 www.example.com.example.com이라는 엉뚱한 이름에 IP가 연결됩니다.

올바른 표기는 마지막 점을 포함한 FQDN입니다:

www.example.com.   IN  A  93.184.216.34

그렇다면 우리가 브라우저에 www.example.com이라고 입력할 때는 왜 문제가 없을까요?

운영체제에 내장된 리졸버(resolver)가 대신 처리해 주기 때문입니다.

리졸버는 도메인 이름을 IP 주소로 변환하는 DNS 클라이언트 소프트웨어입니다. 사용자가 입력한 이름에 마지막 점을 자동으로 붙여 FQDN으로 만든 뒤, DNS 서버에 질의합니다.

덕분에 일상적인 사용에서는 마지막 점을 생략해도 됩니다.

권한 위임(Delegation)

분산 관리의 핵심

HOSTS.TXT에서는 SRI-NIC 한 곳이 모든 이름을 관리했습니다. DNS는 이 관리 권한을 계층에 따라 나눕니다. 이것이 권한 위임(Delegation)입니다.

ICANN (인터넷 이름과 주소를 총괄하는 국제 기구)
    │
    │  "com의 관리를 Verisign에 위임"
    ▼
Verisign (.com TLD 관리 기관)
    │
    │  "example.com의 관리를 Example Inc.에 위임"
    ▼
Example Inc. (example.com 소유자)
    │
    │  "api.example.com의 관리를 클라우드 팀에 위임"
    ▼
클라우드 팀 (api.example.com 관리)

이처럼 ICANN(Internet Corporation for Assigned Names and Numbers)이 모든 도메인을 직접 관리하는 것이 아니라, 각 단계에서 하위 관리자에게 책임을 넘겨 최종적으로 각 조직이 자신의 도메인을 관리합니다.

그렇다면 각 관리자가 책임지는 범위는 어떻게 정해질까요?

Zone과 Zone File

한 관리자가 책임지는 도메인 트리의 연속된 부분을 Zone(존)이라고 합니다.

example.com Zone
┌─────────────────────────────────────┐
│                                     │
│  example.com (SOA, NS, MX, A...)    │
│       │                             │
│  ┌────┴────┬────────┐               │
│  │         │        │               │
│  www      mail    api ──────────────│──→ 별도 Zone으로
│  (A)      (A)                       │     위임 가능
│                                     │
└─────────────────────────────────────┘

Zone과 도메인은 다른 개념입니다. 도메인은 이름의 계층 구조이고, Zone은 한 관리자가 실제로 책임지는 범위입니다.

예를 들어, example.com 도메인 아래에 api.example.com이 있다고 합시다.

api.example.com을 별도 팀에 위임하면, example.com 도메인 하나에 두 개의 Zone이 생깁니다. example.com Zone(본사 관리)과 api.example.com Zone(클라우드 팀 관리)입니다.

Zone의 데이터는 Zone File이라는 텍스트 파일에 저장됩니다. 다음은 example.com Zone File의 주요 내용입니다:

; example.com Zone File

@   IN  SOA   ns1.example.com. admin.example.com. ( ... )  ; Zone 관리 정보(주 네임서버, 관리자 등)
    IN  NS    ns1.example.com.   ; 이 Zone을 담당하는 네임서버
    IN  NS    ns2.example.com.   ; 네임서버(보조)
    IN  MX    10 mail.example.com.  ; 메일 서버
    IN  A     93.184.216.34      ; Zone 자체의 IP 주소

www  IN  A    93.184.216.34      ; www.example.com의 IP 주소
mail IN  A    93.184.216.35      ; mail.example.com의 IP 주소

각 줄은 이름 IN 레코드타입 값 형식입니다. @는 Zone 자체의 이름(여기서는 example.com)을 나타내고, 이름이 생략된 줄은 바로 위의 이름(@)을 이어받습니다.

SOA는 Zone의 관리 정보(주 네임서버, 관리자 연락처, 갱신 주기 등), NS는 네임서버, MX는 메일 서버, A는 IP 주소를 가리키는 레코드입니다.

각 레코드 타입은 뒤에서 자세히 설명합니다.

네임서버와 권한 있는 서버

Zone File을 저장하고 DNS 질의에 응답하는 서버를 네임서버(Name Server)라고 합니다.

그중에서도 해당 Zone의 원본 데이터를 직접 관리하는 네임서버를 권한 있는 서버(Authoritative Server)라고 합니다.

DNS 질의를 처리하는 과정에서 다른 서버가 응답을 임시로 저장(캐시)해 두는 경우가 있는데, 권한 있는 서버는 그런 복사본이 아니라 원본 데이터로 응답합니다.

유형	역할
Primary(Master)	Zone File의 원본을 가진 서버
Secondary(Slave)	Primary로부터 Zone을 복제한 서버

참고: Master/Slave는 RFC 1034/1035 이래 사용된 원래 용어이며, Primary/Secondary는 RFC 8499(2019)에서 권장하는 새 용어입니다. 실제 DNS 소프트웨어와 문서에서 두 용어가 혼용되고 있습니다.

Secondary 서버는 Zone Transfer(존 전송)라는 절차를 통해 Primary로부터 Zone 데이터를 복제합니다.

┌──────────────┐    Zone Transfer    ┌──────────────┐
│   Primary    │ ──────────────────▶ │  Secondary   │
│              │                     │              │
│  Zone File   │                     │  Zone 복제본  │
│  (원본)      │                     │              │
└──────────────┘                     └──────────────┘

Primary 서버에 장애가 발생해도 Secondary 서버가 응답할 수 있으므로, 서비스가 중단되지 않습니다.

Secondary의 복제본은 캐시와는 다릅니다. 캐시는 리졸버가 질의 결과를 일정 시간 임시로 보관하는 것이지만, Secondary는 Zone 전체를 복제하여 Primary와 동등한 권한 있는 응답을 합니다.

DNS 레코드 타입

기본 레코드 타입

Zone File은 레코드(Record)의 모음입니다. 각 레코드는 “이 이름은 이 주소다”, “이 도메인의 메일 서버는 여기다” 같은 정보를 하나씩 담고 있습니다.

앞서 Zone File에서 본 각 줄이 하나의 레코드이며, 구성 요소는 다음 다섯 부분입니다:

이름            TTL   클래스  타입   값
example.com.    3600  IN      A     93.184.216.34

이름: 이 레코드가 속하는 도메인
TTL(Time To Live): 리졸버가 이 레코드를 캐시에 보관할 수 있는 시간(초 단위). 이 값이 3600이면 리졸버는 조회 결과를 1시간 동안 재사용하며, 같은 질의를 네임서버에 다시 보내지 않습니다. Zone File에서는 기본값을 별도로 설정할 수 있어, 개별 레코드에서 생략되는 경우가 많습니다.
클래스: 앞서 Zone File에서 본 IN이 바로 이 필드입니다. Internet을 의미하며, 사실상 항상 IN입니다.
타입: 어떤 종류의 정보인지 (A, AAAA, MX, NS 등)
값: 실제 데이터 (IP 주소, 도메인 이름 등)

타입에 따라 값의 의미가 달라집니다.

A (Address): 도메인을 IPv4 주소로 매핑합니다. 가장 기본적인 레코드입니다.

www.example.com.    IN  A     93.184.216.34

AAAA (IPv6 Address): 도메인을 IPv6 주소로 매핑합니다. A 레코드의 IPv6 버전입니다.

www.example.com.    IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

CNAME (Canonical Name): 한 도메인 이름을 다른 도메인 이름의 별칭(alias)으로 설정합니다. 별칭이란, 자체 IP 주소를 갖지 않고 다른 도메인의 주소를 그대로 따라가는 이름을 말합니다.

blog.example.com.   IN  CNAME www.example.com.

위 레코드는 blog.example.com이 www.example.com의 별칭임을 선언합니다. blog.example.com을 조회하면, 리졸버는 www.example.com의 A 또는 AAAA 레코드를 다시 조회하여 최종 IP 주소를 얻습니다.

단, CNAME 레코드가 존재하는 이름에는 다른 유형의 레코드를 함께 둘 수 없습니다.

CNAME은 “이 이름에 대한 모든 조회를 다른 이름으로 대체하라”는 의미이므로, 같은 이름에 다른 레코드가 공존하면 어느 쪽을 따라야 할지 모호해지기 때문입니다.

예를 들어, 다음과 같이 설정했다고 가정합니다:

example.com.   IN  CNAME  other.com.
example.com.   IN  MX     10 mail.example.com.

example.com의 MX 레코드를 조회하면, CNAME 규칙에 따라 other.com의 MX를 찾아야 할까요, 아니면 바로 아래 줄의 mail.example.com을 사용해야 할까요? 이처럼 CNAME과 다른 레코드가 공존하면 응답이 모호해집니다.

이 제약 때문에 example.com처럼 Zone의 최상위 이름(Zone apex)에는 CNAME을 사용할 수 없습니다. Zone apex에는 NS, SOA 등 필수 레코드가 반드시 존재하므로, CNAME을 추가하면 규칙에 위배되기 때문입니다.

MX (Mail Exchange): 해당 도메인으로 수신되는 이메일을 처리할 메일 서버를 지정합니다.

example.com.        IN  MX    10 mail1.example.com.
example.com.        IN  MX    20 mail2.example.com.

10, 20은 우선순위(preference) 값으로, 낮을수록 우선순위가 높습니다. 메일 전송 시 먼저 mail1에 접속을 시도하고, 접속할 수 없으면 mail2로 넘어갑니다.

NS (Name Server): 도메인의 권한 있는 네임서버를 지정합니다. 앞서 살펴본 권한 위임이 이 레코드를 통해 이루어집니다.

example.com.        IN  NS    ns1.example.com.
example.com.        IN  NS    ns2.example.com.

리졸버가 www.example.com을 찾을 때, .com TLD 서버는 example.com에 대한 NS 레코드를 참조하여 “그 정보는 ns1.example.com에 물어보세요”라고 안내합니다. 이처럼 상위 서버가 NS 레코드를 통해 하위 네임서버로 질의를 넘기는 것이 권한 위임의 핵심입니다.

TXT (Text): 도메인에 임의의 텍스트 데이터를 연결합니다. 사람이 아닌 외부 시스템이 해당 도메인의 정책이나 소유 여부를 확인할 때 읽어 가는 레코드입니다.

example.com.        IN  TXT   "v=spf1 include:_spf.google.com ~all"

이메일은 발신자 주소를 자유롭게 설정할 수 있으므로, 누구든 example.com을 사칭하여 메일을 보낼 수 있습니다. 위 예시는 이를 방지하기 위한 SPF(Sender Policy Framework) 레코드입니다.

v=spf1은 이 레코드가 SPF 버전 1 형식임을 선언합니다. include:_spf.google.com은 _spf.google.com에 등록된 서버가 이 도메인의 메일을 발송할 수 있음을 허가합니다. 마지막 ~all은 허가 목록에 없는 서버에서 온 메일은 의심스러운 것으로 처리하라는 의미입니다.

수신 메일 서버는 메일을 받으면 발신 도메인의 SPF 레코드를 조회하여, 실제로 메일을 보낸 서버가 허가 목록에 있는지 확인합니다. 목록에 없으면 해당 메일을 스팸으로 분류하거나 거부할 수 있습니다.

SPF 외에도 DKIM(메일 본문의 전자서명 검증), DMARC(SPF와 DKIM 결과를 종합하는 정책) 등 이메일 인증과 도메인 소유권 검증에 TXT 레코드가 활용됩니다.

인프라 레코드

SOA (Start of Authority): Zone의 관리 정보를 담으며, 모든 Zone에 반드시 하나씩 존재해야 합니다. 앞서 Zone File 예시에서 ( ... )로 생략했던 부분을 펼치면 다음과 같습니다:

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                    2026012001  ; Serial
                    7200        ; Refresh
                    3600        ; Retry
                    1209600     ; Expire
                    3600 )      ; Negative TTL

admin.example.com.은 Zone 관리자의 이메일 주소입니다. 실제 주소는 admin@example.com이지만, 앞서 보았듯이 @는 Zone File에서 Zone 자체의 이름을 의미하므로 그대로 쓸 수 없습니다. 대신 @를 .으로 바꾸어 표기합니다:

admin@example.com   →   admin.example.com.
     ^                       ^
     @를 .으로 교체

ns1.example.com.은 이 Zone의 주 네임서버입니다. 이어지는 숫자 필드들은 앞서 설명한 Zone Transfer의 동작을 제어합니다:

필드	위 예시의 값	역할
Serial	`2026012001`	Zone이 변경될 때마다 증가하는 버전 번호. Secondary는 이 값을 비교하여 변경을 감지. `YYYYMMDDNN` 형식으로 날짜와 당일 변경 횟수를 조합하는 관례
Refresh	`7200`(2시간)	Secondary가 Primary의 Serial을 확인하는 주기
Retry	`3600`(1시간)	Refresh 실패 시 재시도 간격
Expire	`1209600`(14일)	Primary와 연결이 끊긴 채 이 시간이 지나면, Secondary는 응답을 중단

마지막 필드인 Negative TTL(3600, 1시간)은 Zone Transfer와는 관계없이, “해당 레코드 없음” 응답을 리졸버가 캐시하는 시간입니다.

PTR (Pointer): A 레코드가 도메인에서 IP 주소를 찾는다면, PTR 레코드는 IP 주소에서 도메인을 찾습니다.

예를 들어, 이메일의 발신자 주소는 자유롭게 설정할 수 있으므로 누구든 다른 도메인을 사칭할 수 있습니다. 하지만 TCP 연결의 출발지 IP는 네트워크 계층에서 결정되므로 위조할 수 없습니다. 수신 메일 서버는 이 IP의 PTR 레코드를 조회하여, 해당 IP가 실제로 발신 도메인의 서버인지 확인할 수 있습니다.

34.216.184.93.in-addr.arpa.  IN  PTR  mail.example.com.

위 레코드는 IP 주소 93.184.216.34가 mail.example.com에 속한다는 것을 의미합니다. in-addr.arpa는 이러한 역방향 조회를 위한 특수 도메인입니다.

IP 주소가 역순으로 배치되는 이유는 DNS와 IP의 계층 방향이 반대이기 때문입니다.

DNS 이름:  mail . example . com . (root)
           ←── 구체적           상위 ──→

IP 주소:    93  .  184  .  216  .  34
           상위 ──→            구체적 ──→

DNS 이름은 오른쪽(루트)이 상위이고 왼쪽으로 갈수록 구체적입니다. 반면 IP 주소는 왼쪽(93)이 상위 네트워크 블록이고 오른쪽(34)이 개별 호스트입니다. 방향이 반대이므로, IP 주소를 DNS 트리에 넣으려면 옥텟 순서를 뒤집어 34.216.184.93.in-addr.arpa.로 표기합니다.

SRV (Service): 특정 서비스가 실행 중인 호스트와 포트를 지정합니다. A 레코드는 도메인을 IP 주소로만 매핑하므로, 클라이언트가 포트 번호를 미리 알고 있어야 합니다. SRV 레코드는 포트 번호까지 DNS에서 알려줍니다.

_sip._tcp.example.com.  IN  SRV  10 60 5060 sipserver.example.com.

레코드 이름은 _서비스._프로토콜.도메인 형식입니다. 위 예시의 _sip._tcp는 TCP 기반 SIP(Session Initiation Protocol, 인터넷 전화 등에 사용) 서비스를 의미합니다. 이어지는 필드는 순서대로:

10 — 우선순위. 낮을수록 먼저 시도
60 — 가중치. 같은 우선순위의 서버가 여럿일 때 트래픽 분배 비율
5060 — 포트 번호
sipserver.example.com. — 대상 호스트

우선순위가 다른 SRV 레코드를 여러 개 등록하면, 첫 번째 서버에 장애가 발생했을 때 다음 서버로 자동 전환됩니다.

현대적 레코드 타입

CAA (Certification Authority Authorization): 도메인에 대해 SSL/TLS 인증서를 발급할 수 있는 인증 기관(CA, Certificate Authority)을 지정합니다.

example.com.        IN  CAA   0 issue "letsencrypt.org"

0은 플래그, issue는 인증서 발급 허용을 의미하는 태그, "letsencrypt.org"는 허용할 CA입니다. 즉 이 레코드는 “이 도메인의 인증서는 Let’s Encrypt만 발급할 수 있다”고 선언합니다.

CA는 인증서 발급 전에 도메인의 CAA 레코드를 확인하며, 자신이 허용 목록에 없으면 발급을 거부합니다.

HTTPS/SVCB (Service Binding): 서버에 연결하기 전에 필요한 정보를 DNS 단계에서 미리 알려줍니다. 이 레코드가 없으면 클라이언트는 먼저 서버에 접속한 뒤에야 지원하는 프로토콜 등을 알 수 있지만, HTTPS 레코드가 있으면 DNS 조회만으로 이 정보를 얻을 수 있습니다. HTTP의 진화 (2)에서 설명한 HTTP/3 연결에도 활용됩니다.

example.com.        IN  HTTPS 1 . alpn="h3,h2" ipv4hint=93.184.216.34

1 — 우선순위
. — 대상 호스트가 도메인 자체(example.com)임을 의미
alpn="h3,h2" — 지원하는 프로토콜. 여기서는 HTTP/3(h3)과 HTTP/2(h2)
ipv4hint=93.184.216.34 — 추가 DNS 조회 없이 바로 연결할 수 있도록 IP 주소를 미리 제공

레코드 조회 예시

dig 명령어

dig는 터미널에서 DNS 레코드를 직접 질의할 수 있는 도구입니다.

$ dig example.com A

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

dig 출력에는 여러 섹션이 있지만, 주로 두 가지를 확인하게 됩니다.

QUESTION: 질의한 내용 (example.com의 A 레코드)
ANSWER: 응답받은 레코드

ANSWER의 내용은 앞서 설명한 레코드 구성 요소와 같은 순서입니다:

example.com.   3600   IN   A   93.184.216.34
    이름        TTL  클래스 타입      값

3600은 TTL로, 리졸버가 이 응답을 1시간 동안 캐시함을 의미합니다.

다른 레코드 타입도 같은 방식으로 조회할 수 있습니다.

$ dig example.com MX

;; ANSWER SECTION:
example.com.            3600    IN      MX      10 mail.example.com.

앞서 설명한 대로 10은 우선순위이며, mail.example.com.이 이 도메인의 메일 서버임을 알 수 있습니다.

$ dig example.com NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      ns1.example.com.
example.com.            86400   IN      NS      ns2.example.com.

NS 레코드의 TTL은 86400(24시간)으로, A 레코드의 3600(1시간)보다 깁니다. 네임서버는 자주 변경되지 않으므로 더 오래 캐시해도 되기 때문입니다.

권한 있는 서버 직접 조회

위 NS 조회에서 example.com의 네임서버가 ns1.example.com임을 확인했습니다. @서버 옵션으로 이 네임서버에 직접 질의할 수 있습니다.

$ dig @ns1.example.com example.com A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

권한 있는 서버에 직접 질의하면, 리졸버의 캐시를 거치지 않고 원본 데이터에서 응답을 받습니다. DNS 레코드를 변경한 직후, 변경이 원본 서버에 반영되었는지 확인할 때 유용합니다.

마무리

HOSTS.TXT의 한계에서 출발하여 DNS의 구조를 살펴보았습니다.

HOSTS.TXT의 문제	DNS의 해결
이름 충돌	계층적 네임스페이스
단일 장애점 · 업데이트 지연	분산 데이터베이스 + 권한 위임
트래픽 폭증	캐싱

이 구조 위에서 Zone과 Zone File이 관리 범위를 나누고, 네임서버가 레코드를 저장하고 질의에 응답합니다. 레코드 타입(A, NS, MX, SOA 등)은 각각 IP 주소, 네임서버, 메일 서버, Zone 관리 정보 등 서로 다른 역할을 담당합니다.

이 글에서는 DNS의 데이터가 어떻게 구성되어 있는지를 다루었습니다. 다음 글에서는 이 데이터를 실제로 어떻게 찾아가는지, 리졸버의 질의 과정과 캐싱의 동작을 살펴봅니다.

시리즈

DNS의 원리 (1) - DNS의 탄생과 계층 구조 (현재 글)
DNS의 원리 (2) - DNS 질의와 해석 과정
DNS의 원리 (3) - DNS 보안과 현대적 발전

관련 글