생각을 정리하는 마인드맵, 풀맵 →
기술 딥다이브마지막 수정

[기술 딥다이브] DNS: 도메인 이름이 IP 주소가 되기까지


한 줄 요약: DNS는 재귀 해석기가 루트→TLD→권한 있는 서버로 계층을 따라가며 이름을 IP로 바꾸고, 그 결과를 TTL 동안 캐싱하는 시스템이다.

브라우저에 주소를 입력하면, 컴퓨터는 그 이름을 IP 주소로 변환해요. 이 변환을 DNS(Domain Name System)가 수행해요. 인터넷의 전화번호부라고 불리는 이유예요. 어떻게 작동하는지 도식과 실제 조회 응답으로 풀어 설명하겠어요. DNS로 IP를 찾은 다음 일어나는 일이 바로 TCP 3-way handshake이므로, 두 글을 이어 읽으면 웹 연결의 전체 흐름이 돼요.

도메인의 계층 구조: 루트, TLD, 권한 있는 서버

도메인은 역트리(뒤집힌 트리) 구조예요. blog.app.gslump.com이라면 다음과 같이 분해돼요:

  • .(루트): 최상위, 보통 생략됨
  • com: TLD(Top-Level Domain), 최상위 도메인
  • gslump.com: 권한 있는 서버가 관리하는 영역
  • app.gslump.com, blog.app.gslump.com: 하위 도메인

각 계층마다 그 아래를 관리하는 권한 있는 서버(authoritative server)가 존재해요.

재귀 해석기: 대신 찾아주는 서버

브라우저가 도메인을 전달하면, 먼저 재귀 해석기(recursive resolver)에 조회해요. 보통 ISP나 Google DNS(8.8.8.8), Cloudflare DNS(1.1.1.1) 같은 서버예요. 부르는 곳마다 아는 부서가 다르니, 사용자 대신 전화를 돌려 주는 안내 데스크라고 보면 돼요.

조회 과정: 위임을 따라 내려가기

아래 도식은 해석기가 계층을 따라 질문을 넘기는 과정을 보여줘요. 답을 아는 서버는 자기 바로 아래 계층의 담당자만 알려주고, 해석기는 그 담당자에게 다시 묻어요. 이것이 위임(delegation)예요.

DNS 재귀 해석 과정 도식 클라이언트가 재귀 해석기에 질의하면, 해석기가 루트 서버, com TLD 서버, 권한 있는 서버 순서로 위임을 따라 내려가며 IP를 찾아 돌려주는 과정. 브라우저 재귀 해석기 루트 서버 com TLD 서버 gslump.com 권한 서버 ① blog.app.gslump.com의 IP? ② gslump.com 담당은? com TLD 주소 알려줌 ③ 권한 서버 주소 알려줌 ④ blog.app.gslump.com? 115.71.237.101 ⑤ 응답: 115.71.237.101 ②~④ 위임(delegation): 답을 아는 쪽은 바로 아래 계층 담당자만 알려준다

단계별로 보면 다음과 같아요:

  1. 해석기가 루트 서버에 ’gslump.com을 아는가?’라고 묻어요. 루트는 ‘com TLD 담당 서버’ 주소를 알려줘요.
  2. 해석기가 com TLD 서버에 같은 질문을 해요. TLD는 ‘gslump.com 권한 있는 서버’ 주소를 알려줘요.
  3. 해석기가 gslump.com 권한 있는 서버에 ’blog.app.gslump.com을 아는가?’라고 묻어요. 여기서 비로소 IP를 받아요.

실제 조회 응답: TTL이 살아 움직이는 모습

직접 확인할 수 있어요. 아래는 Cloudflare의 공개 해석기(1.1.1.1)에 DNS over HTTPS로 물어본 실제 응답이에요(가독성을 위해 필드를 정리했어요).

$ curl 'https://1.1.1.1/dns-query?name=blog.app.gslump.com&type=A' \
     -H 'accept: application/dns-json'

Status: 0          (NOERROR — 조회 성공)
blog.app.gslump.com  type A  →  115.71.237.101   TTL 300

이 사이트의 실제 IP가 응답으로 돌아왔어요. 여기서 주목할 값은 TTL 300예요. 이 사이트의 DNS 레코드는 5분(300초) 유효 기간으로 설정돼 있고, 같은 주소를 조회하는 시점에 따라 TTL이 298, 287처럼 조금씩 줄어 있는 것을 볼 수 있어요. 줄어 있는 이유는 1.1.1.1이 이전 조회 결과를 캐시해 두었기 때문이에요. 즉 이 한 줄의 응답 안에 ’캐싱이 실제로 일어난다’는 증거가 함께 들어 있어요.

캐싱과 TTL: 한 번 찾으면 잠시 기억

매번 위 과정을 전부 거치면 느려요. 그래서 각 단계(브라우저, 운영체제, 해석기)가 결과를 캐싱해요. 자주 걸던 번호를 주소록에 저장해 두는 것과 같고, TTL(Time To Live)은 그 항목의 유효 기간이에요. TTL이 짧으면 서버 주소 변경이 빨리 반영되지만 조회가 많아지고, 길면 빠르지만 변경 반영이 느려져요. DNS 레코드를 옮길 때 전파가 조금씩 늦게 일어나는 이유가 바로 이 캐시 유효 기간이에요.

DNS over HTTPS/TLS: 암호화된 조회

기존 DNS는 평문으로 동작해요. 중간에서 누가 어떤 도메인을 조회하는지 엿볼 수 있어요. 그래서 DoH(DNS over HTTPS)와 DoT(DNS over TLS)가 등장했어요. 조회 자체를 암호화해요. 위 예시에서 제가 쓴 방법이 바로 DoH예요. HTTPS 요청 한 줄로 DNS 응답을 JSON으로 받을 수 있어서, 별도 도구 없이도 DNS 동작을 직접 관찰할 수 있어요. Chrome과 Firefox 등 주요 브라우저도 기본 지원을 시작했어요.

어떻게 연결되는가

한 줄로 요약하면: 재귀 해석기가 루트→TLD→권한 있는 서버로 위임을 따라 내려가며 IP를 찾고, 결과를 TTL 동안 캐싱하는 시스템이에요. ’이름에서 IP로’의 변환 하나에 전 세계 서버들이 계층적으로 협력하는 것이 DNS의 본질이에요. IP를 손에 넣은 다음에는 그 주소로 연결을 맺어요. 그 첫 절차가 TCP 3-way handshake예요.

출처: RFC 1035: DNS · 위키백과: Domain Name System · Cloudflare 1.1.1.1 DoH API

이미지: Pavel.satrapa, Wikimedia Commons (CC-BY-SA 2.5) — 원본