142.250.196.110을 외우는 대신 google.com을 치면 되는 이유. 1983년 HOSTS.TXT 파일 하나로 시작된 DNS가 어떻게 인터넷의 전화번호부가 되었는지, 그 계층 구조와 질의 과정, 보안 위협과 대응, 클라우드 시대의 DNS 활용법까지 완전 정복한다.
지금 바로 브라우저 주소창에 142.250.196.110을 입력해 보자. Google 검색 페이지가 뜬다. 223.130.200.104를 입력하면? 네이버가 나온다.
이것이 인터넷의 진짜 주소다. 우리가 매일 쓰는 google.com, naver.com은 사실 인간을 위한 별명(alias)에 불과하다. 컴퓨터와 컴퓨터가 통신할 때는 오직 숫자로 된 IP 주소만 이해한다.
상상해 보자. 자주 가는 웹사이트 10개의 IP 주소를 전부 외워야 한다면?
142.250.196.110 → Google223.130.200.104 → Naver31.13.70.36 → Facebook151.101.1.140 → Reddit104.244.42.193 → X (Twitter)185.199.108.153 → GitHub52.78.231.108 → 배달의민족13.225.103.59 → Netflix... 그리고 수천 개 더
불가능하다. 전화번호부 없이 전화번호를 외우던 시대를 떠올려 보라. 엄마 번호, 친구 번호 몇 개는 외울 수 있어도, 피자집 번호까지 외울 수는 없다.
DNS(Domain Name System)는 인터넷의 전화번호부다. "이 이름의 IP 주소가 뭐야?"라는 질문에 답하는 시스템. 우리가 google.com을 입력하면 DNS가 142.250.196.110으로 번역해 주는 것이다.
이 글에서는 DNS의 탄생 배경, 계층 구조, 질의 과정, 레코드 타입, 보안 위협, 실전 도구, 그리고 클라우드 시대의 DNS 활용법까지 하나도 빠짐없이 다룬다. 주소창에 URL을 칠 때마다 보이지 않는 곳에서 벌어지는 일을 이해하고 나면, 네트워킹에 대한 시야가 완전히 달라질 것이다.
1970년대, 인터넷의 전신인 ARPANET에 연결된 컴퓨터는 수십 대에 불과했다. 이 시절에는 이름과 IP 주소를 매핑하는 방법이 단순했다. HOSTS.TXT라는 텍스트 파일 하나에 모든 호스트 정보를 적어 두고, SRI-NIC(Stanford Research Institute의 Network Information Center)에서 관리했다.
HOST : 10.0.0.1 : MIT-AI : PDP-10 : MIT ::HOST : 10.0.0.2 : SRI-NIC : PDP-11 : SRI ::HOST : 10.1.0.1 : UCLA-CCN : SIGMA7 : UCLA ::HOST : 10.2.0.1 : UTAH : PDP-10 : UTAH ::... (수십 줄이면 충분)
네트워크에 새 컴퓨터가 추가되면? SRI-NIC에 전화해서 "우리 컴퓨터 추가해 주세요"라고 요청하면 됐다. 그러면 SRI-NIC가 HOSTS.TXT를 업데이트하고, 각 기관에서 FTP로 최신 파일을 다운로드했다.
1980년대에 접어들면서 ARPANET에 연결된 호스트가 수백 대로 늘어났다. HOSTS.TXT 시스템의 문제가 드러나기 시작했다.
Paul Mockapetris가 설계한 DNS는 세 가지 핵심 원칙을 가지고 있다.
www.example.com처럼 점(.)으로 구분된 트리 구조. 각 레벨을 독립적으로 관리 가능이 세 가지 원칙 덕분에 DNS는 40년이 지난 지금도 3.5억 개의 도메인을 안정적으로 서비스하고 있다. 인터넷에서 가장 오래되고, 가장 안정적인 분산 시스템 중 하나다.
DNS는 거꾸로 뒤집은 나무(inverted tree) 구조다. 꼭대기에 루트(Root)가 있고, 아래로 내려가면서 가지가 나뉜다. 이 구조를 이해하면 DNS의 모든 것이 명확해진다.
DNS 트리의 꼭대기. 전 세계 13개 루트 서버 클러스터가 존재한다. A부터 M까지 알파벳으로 이름이 붙어 있다.
"13개면 너무 적은 거 아닌가?"라고 생각할 수 있다. 하지만 "13개"는 논리적 서버 수다. 실제로는 Anycast 기술을 사용하여 전 세계 수백 개 지점에 분산 배치되어 있다. 예를 들어, F-Root(ISC 운영)는 전 세계 300개 이상의 노드에서 운영된다.
| 루트 서버 | 운영 기관 | Anycast 노드 수 |
|---|---|---|
| A-Root | Verisign | 다수 |
| B-Root | USC-ISI | 소수 |
| F-Root | ISC (Internet Systems Consortium) | 300+ |
| J-Root | Verisign | 다수 |
| K-Root | RIPE NCC | 90+ |
| L-Root | ICANN | 200+ |
| M-Root | WIDE Project (일본) | 10+ |
루트 서버가 하는 일은 단 하나다: "이 TLD를 담당하는 서버는 누구인가?"에 대답하는 것. google.com을 질의하면 루트 서버는 .com을 담당하는 TLD 서버의 주소를 알려준다.
TLD는 도메인 이름의 마지막 부분이다. 크게 세 종류로 나뉜다.
.com, .net, .org 등 일반적인 TLD. Verisign이 .com과 .net을 관리한다. 2012년부터 ICANN이 새로운 gTLD를 대량 허용하면서 .app, .dev, .io 등이 등장했다..kr(한국), .jp(일본), .uk(영국) 등 국가 코드 TLD. 한국의 .kr은 한국인터넷진흥원(KISA)이 관리한다..arpa는 역방향 DNS(IP → 도메인) 조회에 사용되는 특수 TLD.실제 도메인의 DNS 레코드를 보관하고 있는 서버. google.com의 경우 Google이 직접 운영하는 네임서버(ns1.google.com 등)가 권한 있는 네임서버다.
도메인을 등록하면, 그 도메인의 네임서버를 지정해야 한다. 보통 도메인 등록 대행사(가비아, AWS Route 53 등)가 네임서버를 제공한다. 이 네임서버가 "이 도메인의 IP 주소는 뭐야?"라는 질문에 최종적으로 대답하는 주체다.
브라우저 주소창에 www.example.com을 입력하고 Enter를 누르면, 화면에 웹페이지가 나타나기까지 뒤에서 무슨 일이 벌어지는가? DNS 질의 과정을 한 단계씩 따라가 보자.
Step 1: 로컬 캐시 확인
브라우저는 먼저 자체 DNS 캐시를 확인한다. Chrome의 경우 chrome://net-internals/#dns에서 캐시된 DNS 레코드를 볼 수 있다. 캐시에 없으면 OS의 DNS 캐시를 확인한다.
Step 2: DNS 리졸버에게 질의
로컬 캐시에도 없으면, 컴퓨터에 설정된 DNS 리졸버(Recursive Resolver)에게 질의한다. 보통 ISP(인터넷 서비스 제공자)가 자동으로 리졸버를 제공하지만, 직접 설정할 수도 있다.
| DNS 리졸버 | IP 주소 | 특징 |
|---|---|---|
| Google Public DNS | 8.8.8.8 / 8.8.4.4 | 가장 널리 사용. 빠르고 안정적 |
| Cloudflare DNS | 1.1.1.1 / 1.0.0.1 | 개인정보 중심. 가장 빠른 응답 속도 |
| KT DNS | 168.126.63.1 | 한국 ISP 기본 설정. 국내 도메인에 최적화 |
| SK DNS | 210.220.163.82 | 한국 ISP 기본 설정 |
| Quad9 | 9.9.9.9 | 보안 중심. 악성 도메인 자동 차단 |
Step 3: 재귀 질의 (Recursive Query)
리졸버가 답을 모르면, 계층 구조를 따라 위에서부터 아래로 질의를 시작한다.
DNS 질의에는 두 가지 방식이 있다.
실제로는 이 두 방식이 조합되어 사용된다. 클라이언트는 리졸버에게 재귀 질의를 하고, 리졸버는 다른 서버들에게 반복 질의를 한다.
DNS 서버에 저장되는 정보를 레코드(Record)라고 한다. 도메인 하나에 여러 종류의 레코드가 존재할 수 있다. 각 레코드 타입은 서로 다른 역할을 한다.
| 레코드 타입 | 용도 | 예시 값 |
|---|---|---|
| A | 도메인 → IPv4 주소 | example.com → 93.184.216.34 |
| AAAA | 도메인 → IPv6 주소 | example.com → 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | 도메인 → 다른 도메인 (별칭) | www.example.com → example.com |
| MX | 메일 서버 지정 | example.com → mail.example.com (우선순위 10) |
| TXT | 텍스트 정보 (SPF, DKIM 등) | "v=spf1 include:_spf.google.com ~all" |
| NS | 네임서버 지정 | example.com → ns1.example.com |
| SOA | 도메인 권한 정보 (시리얼, 갱신 주기 등) | ns1.example.com admin.example.com 2026040101 ... |
A 레코드 (Address Record)
가장 기본적인 레코드. 도메인 이름을 IPv4 주소로 매핑한다. 하나의 도메인에 여러 A 레코드를 지정하면 라운드 로빈 방식으로 트래픽이 분산된다.
google.com. 300 IN A 142.250.196.110google.com. 300 IN A 142.250.196.113google.com. 300 IN A 142.250.196.100
Google은 여러 A 레코드를 가지고 있다. 요청할 때마다 다른 IP가 반환될 수 있으며, 이를 통해 트래픽을 분산한다.
AAAA 레코드 (Quad-A Record)
A 레코드의 IPv6 버전. IPv4 주소가 32비트인 반면, IPv6 주소는 128비트로 거의 무한한 주소 공간을 제공한다. "AAAA"라는 이름은 IPv6 주소가 IPv4의 4배 길이이기 때문에 A를 4개 쓴 것이다.
CNAME 레코드 (Canonical Name)
하나의 도메인을 다른 도메인의 별칭(alias)으로 설정한다. www.example.com을 example.com으로 가리키게 하면, www 서브도메인이 메인 도메인과 같은 IP를 자동으로 따라간다.
MX 레코드 (Mail Exchange)
이메일을 받을 메일 서버를 지정한다. 우선순위(priority) 값이 있어, 숫자가 낮을수록 우선적으로 사용된다. 우선순위가 높은 서버에 장애가 생기면 다음 서버로 자동 전환된다.
google.com. 600 IN MX 10 smtp.google.com.google.com. 600 IN MX 20 smtp2.google.com.google.com. 600 IN MX 30 smtp3.google.com.google.com. 600 IN MX 40 smtp4.google.com.
TXT 레코드 (Text Record)
임의의 텍스트 데이터를 저장한다. 원래는 범용이었지만, 현재는 주로 이메일 인증에 활용된다.
NS 레코드 (Name Server)
해당 도메인의 DNS 질의를 처리할 네임서버를 지정한다. 도메인을 등록하면 반드시 NS 레코드를 설정해야 한다.
SOA 레코드 (Start of Authority)
도메인의 권한 정보를 담고 있다. 시리얼 번호, 갱신 주기, 재시도 주기, 만료 시간 등 DNS 관리에 필요한 메타데이터가 들어 있다.
매번 루트 서버 → TLD → 권한 있는 서버를 거쳐야 한다면 DNS 질의에 수백 ms가 걸릴 것이다. 하지만 실제로는 대부분의 DNS 질의가 수 ms 안에 끝난다. 비밀은 캐싱이다.
모든 DNS 레코드에는 TTL 값이 붙어 있다. "이 정보를 캐시에 얼마나 오래 보관해도 되는가"를 초(second) 단위로 지정한다.
DNS 질의 결과는 여러 계층에서 캐싱된다. 위에서부터 순서대로 확인하며, 캐시에 있으면 더 아래로 내려가지 않는다.
chrome://net-internals/#dns에서 확인 가능.
dscacheutil -flushcache, Windows는 ipconfig /flushdns로 초기화. /etc/hosts 파일도 여기서 참조.
| 상황 | 권장 TTL | 이유 |
|---|---|---|
| 안정적인 프로덕션 서비스 | 3600 (1시간) | 캐시 효율과 변경 용이성의 균형 |
| 마이그레이션/변경 예정 | 300 (5분) | 변경 전 TTL을 미리 낮춰 빠른 전파 준비 |
| 페일오버 대비 | 60 (1분) | 장애 시 빠르게 다른 서버로 전환 |
| CDN 서비스 (CloudFront 등) | 60~300 | CDN이 자체 라우팅하므로 짧은 TTL 권장 |
| 거의 변경 안 하는 레코드 (NS 등) | 86400 (24시간) | 안정성 극대화, 서버 부하 최소화 |
DNS는 1983년에 설계되었다. 당시에는 보안이 주요 고려사항이 아니었다. DNS 질의와 응답은 기본적으로 평문(plaintext) UDP로 전송된다. 이것이 다양한 보안 위협의 원인이 된다.
공격자가 DNS 리졸버의 캐시에 가짜 IP 주소를 주입하는 공격. 사용자가 bank.com을 방문하려 하면 공격자의 피싱 사이트로 연결된다.
2008년, 보안 연구자 Dan Kaminsky가 DNS 캐시 포이즈닝의 치명적인 취약점을 발견했다. 이 발견은 인터넷 역사상 가장 큰 보안 사건 중 하나로, DNS 보안 개선의 계기가 되었다.
DNSSEC은 DNS 응답에 디지털 서명을 추가하여 응답의 진위를 검증하는 프로토콜이다. 1997년에 처음 제안되었고(RFC 2065), 2005년에 현재 표준(RFC 4033-4035)이 확립되었다.
DNSSEC의 한계: 응답의 무결성(integrity)은 보장하지만, 기밀성(confidentiality)은 보장하지 않는다. DNS 질의 내용 자체는 여전히 평문으로 전송된다. 즉, 누군가 도청하면 "이 사용자가 어떤 사이트를 방문하는가"를 알 수 있다.
DNSSEC이 응답의 무결성을 보장한다면, DoH와 DoT은 기밀성을 보장한다.
| 방식 | 포트 | 암호화 | 특징 |
|---|---|---|---|
| 일반 DNS | UDP 53 | 없음 (평문) | 전통적 방식. 도청, 조작 가능 |
| DoT (DNS over TLS) | TCP 853 | TLS 암호화 | 전용 포트 사용. 차단 감지 쉬움 |
| DoH (DNS over HTTPS) | TCP 443 | HTTPS 암호화 | 일반 HTTPS 트래픽과 구별 불가. 차단 어려움 |
DoH는 DNS 질의를 일반 HTTPS 트래픽에 섞어 보내므로, ISP나 네트워크 관리자가 DNS 질의를 감시하거나 차단하기 어렵다. Chrome, Firefox, Safari 등 주요 브라우저가 DoH를 기본 지원하며, Cloudflare(1.1.1.1)와 Google(8.8.8.8)이 DoH 서비스를 제공한다.
DNS를 이해하는 가장 좋은 방법은 직접 질의해 보는 것이다. 터미널에서 사용할 수 있는 핵심 도구 세 가지를 소개한다.
가장 기본적인 DNS 조회 도구. Windows, macOS, Linux 모두에서 사용 가능하다.
$ nslookup google.comServer: 168.126.63.1 ← 사용 중인 DNS 리졸버Address: 168.126.63.1#53Non-authoritative answer: ← 캐시된 결과 (권한 있는 서버에서 직접 온 게 아님)Name: google.comAddress: 142.250.196.110
특정 레코드 타입을 조회하려면:
$ nslookup -type=MX google.com ← 메일 서버 조회$ nslookup -type=TXT google.com ← TXT 레코드 조회$ nslookup -type=NS google.com ← 네임서버 조회$ nslookup google.com 8.8.8.8 ← 특정 DNS 서버로 질의
DNS 전문가들이 가장 많이 쓰는 도구. 상세한 정보를 제공하며, 스크립팅에도 유용하다. macOS와 Linux에 기본 설치되어 있다.
$ dig google.com;; QUESTION SECTION:;google.com. IN A;; ANSWER SECTION:google.com. 300 IN A 142.250.196.110;; Query time: 12 msec ← 질의 소요 시간;; SERVER: 168.126.63.1#53 ← 사용된 DNS 서버;; MSG SIZE rcvd: 55
dig의 진정한 파워는 +trace 옵션에 있다. DNS 질의 과정을 루트부터 단계별로 추적할 수 있다.
$ dig +trace www.example.com;; Received 239 bytes from 168.126.63.1 in 5 ms ← 리졸버에서 루트 서버 목록 수신. 518400 IN NS a.root-servers.net.. 518400 IN NS b.root-servers.net....com. 172800 IN NS a.gtld-servers.net. ← 루트가 .com TLD 서버를 알려줌example.com. 172800 IN NS a.iana-servers.net. ← TLD가 권한 있는 서버를 알려줌www.example.com. 86400 IN A 93.184.216.34 ← 최종 응답!
가장 간결한 DNS 조회 도구. 빠른 확인에 적합하다.
$ host google.comgoogle.com has address 142.250.196.110google.com has IPv6 address 2404:6800:4004:81f::200egoogle.com mail is handled by 10 smtp.google.com.$ host -t NS google.com ← 네임서버만 조회google.com name server ns1.google.com.google.com name server ns2.google.com.google.com name server ns3.google.com.google.com name server ns4.google.com.
| 상황 | 추천 도구 | 이유 |
|---|---|---|
| 빠르게 IP 확인 | host | 한 줄로 결과 출력. 스크립트에서 파싱 쉬움 |
| Windows에서 DNS 조회 | nslookup | Windows 기본 내장. 별도 설치 불필요 |
| 상세한 DNS 디버깅 | dig | TTL, 응답 시간, 섹션별 상세 정보 제공 |
| DNS 질의 경로 추적 | dig +trace | 루트부터 최종 서버까지 단계별 추적 가능 |
| DNSSEC 검증 | dig +dnssec | RRSIG 레코드와 서명 검증 상태 확인 |
DNS가 얼마나 중요한 인프라인지는 장애가 발생했을 때 적나라하게 드러난다.
인터넷 역사상 가장 유명한 DNS 사건. Mirai 봇넷이 DNS 서비스 업체 Dyn에 대규모 DDoS 공격을 감행했다.
Cloudflare가 1.1.1.1을 공개 DNS로 출시한 것은 단순한 기술 이벤트가 아니었다.
1.1.1.1은 원래 APNIC(아시아태평양 인터넷 주소 관리 기관)이 보유한 IP 주소였지만, 너무 많은 사람이 테스트 용도로 아무 곳에나 1.1.1.1을 입력하는 바람에 "쓰레기 트래픽"에 파묻혀 사실상 사용 불가능한 주소였다. Cloudflare는 APNIC과 협력하여 이 "버린 IP"를 세계에서 가장 빠른 DNS 서비스로 탈바꿈시켰다.
Cloudflare 1.1.1.1의 핵심 가치:
2019년 2월, 한국 정부가 HTTPS 차단을 위해 SNI(Server Name Indication) 필드 감시를 도입했다. 이전까지는 DNS 차단만으로 불법 사이트를 차단했지만, 사용자들이 DNS를 변경하면 우회가 가능했다.
이 사건은 DNS와 인터넷 자유에 대한 대중의 관심을 크게 높였다. DNS 변경(8.8.8.8, 1.1.1.1)이 "IT 팁"으로 포털 검색 순위에 오르기도 했으며, DoH에 대한 관심도 급증했다.
클라우드 환경에서 DNS는 단순한 이름 해석을 넘어 트래픽 관리, 장애 대응, 서비스 디스커버리의 핵심 도구가 된다.
AWS의 관리형 DNS 서비스. 이름은 DNS가 사용하는 포트 번호 53에서 따왔다. "Route"는 미국의 유명한 도로 Route 66에서 영감을 받았다.
Route 53의 진짜 파워는 라우팅 정책(Routing Policy)에 있다. 단순히 "이 도메인 = 이 IP"가 아니라, 다양한 조건에 따라 다른 IP를 반환할 수 있다.
| 라우팅 정책 | 동작 | 사용 예시 |
|---|---|---|
| 단순 (Simple) | 하나의 IP 반환 | 소규모 서비스, 단일 서버 |
| 가중치 (Weighted) | 비율에 따라 트래픽 분배 | 블루/그린 배포 (90%:10%) |
| 지연 시간 (Latency) | 가장 빠른 리전으로 라우팅 | 글로벌 서비스 최적화 |
| 페일오버 (Failover) | 헬스 체크 실패 시 백업으로 전환 | 고가용성(HA) 아키텍처 |
| 지리적 (Geolocation) | 사용자 위치에 따라 다른 IP 반환 | 국가별 콘텐츠, 규제 준수 |
| 다중값 (Multivalue) | 여러 IP를 반환 + 헬스 체크 | 간이 로드밸런싱 |
클라우드에서 서비스를 배포할 때 가장 먼저 하는 일 중 하나가 커스텀 도메인을 연결하는 것이다. 전형적인 흐름은 다음과 같다.
앞서 CNAME은 루트 도메인에 사용할 수 없다고 했다. 그렇다면 example.com(www 없이)을 CloudFront나 ALB에 연결하려면? Route 53의 ALIAS 레코드가 답이다.
ALIAS 레코드는 AWS 전용 기능으로, CNAME처럼 다른 도메인을 가리키면서도 루트 도메인에 사용할 수 있다. 또한 Route 53 → AWS 리소스 간 ALIAS 질의에는 추가 비용이 없다.
Route 53은 전 세계 여러 위치에서 주기적으로 엔드포인트의 상태를 확인한다. 헬스 체크 실패가 감지되면 DNS 응답에서 해당 엔드포인트를 제거하여 트래픽을 정상 서버로 자동 전환한다.
이 메커니즘은 서버 장애뿐 아니라 리전 장애(DR, Disaster Recovery)에도 적용된다. 서울 리전 전체가 다운되면 DNS 레벨에서 도쿄나 싱가포르로 자동 전환할 수 있다.
반은 맞고 반은 틀리다. DNS 레코드를 변경하면 전 세계 캐시가 모두 갱신되는 데 최대 TTL 만큼 시간이 걸릴 수 있다. TTL이 48시간(172800초)이면 이론적으로 48시간까지 걸릴 수 있지만, 현대 DNS 설정에서 TTL을 48시간으로 설정하는 경우는 드물다. 일반적으로 TTL이 300~3600초이므로, 실제 전파는 5분~1시간 내에 완료된다.
"구글 DNS(8.8.8.8)로 바꾸면 인터넷이 빨라진다"는 말을 들어본 적이 있을 것이다. 정확히 말하면, DNS 응답 속도가 빨라질 수 있다. 하지만 DNS 질의는 웹페이지 로딩의 극히 일부이므로, 체감 속도 변화는 미미한 경우가 많다. 다만, ISP의 DNS가 불안정하거나 느린 경우에는 확실한 개선 효과가 있다.
클라우드/DX 전문가를 목표로 한다면, 개인 도메인을 하나 구매하고 DNS를 직접 설정해 보는 것을 강력히 권한다. .com 도메인은 연간 약 12,000~15,000원, .kr은 약 18,000원 정도다. DNS 레코드를 직접 생성하고, 서브도메인을 나누고, SSL 인증서를 발급하는 과정이 최고의 학습이다.
우리가 주소창에 URL을 입력하고 Enter를 누르는 그 순간, DNS는 수십 ms 안에 이 모든 일을 처리한다. 루트 서버에서 시작해 TLD를 거쳐 권한 있는 네임서버에 도달하고, 그 결과를 여러 계층의 캐시에 저장한다. 1983년 Paul Mockapetris가 설계한 이 시스템은 40년이 지난 지금도 인터넷의 근간을 이루고 있다.
DNS를 이해한다는 것은 단순히 "도메인을 IP로 바꾼다"는 것을 아는 수준을 넘어선다. 그것은 인터넷이 어떻게 동작하는가의 첫 번째 조각을 이해하는 것이다.
클라우드와 DX를 공부하면서 가장 먼저 만나게 되는 기술이 DNS다. EC2를 만들면 도메인을 연결해야 하고, S3 정적 웹사이트를 배포하면 CNAME을 설정해야 하고, 이메일을 보내려면 MX와 TXT 레코드를 다뤄야 한다.
지금 당장 할 수 있는 것: 터미널을 열고 dig google.com +trace를 실행해 보자. DNS 질의가 루트 서버에서 시작해서 최종 응답에 도달하는 전체 여정을 눈으로 확인할 수 있다. 그 과정을 한 번 직접 보면, DNS는 더 이상 추상적인 개념이 아니라 손에 잡히는 기술이 된다.
인터넷의 전화번호부, DNS. 이제 당신은 그 전화번호부가 어떻게 만들어지고, 어떻게 작동하며, 왜 중요한지를 안다.