DNS 심화 — DNS 서버, 리소스 레코드, 그리고 재귀질의

앞 글에서 "DNS = 네트워크의 전화번호부"라고 했습니다.
이번엔 그 전화번호부가 실제로 어떻게 구성되고(리소스 레코드), 어떤 원리로 이름을 IP로 바꾸는지(재귀질의·캐시)
한 단계 깊이 들어갑니다.

📌 한눈에

키워드 핵심

DNS 서버	호스트명↔IP 등 정보를 등록해 두는 서버
리소스 레코드	DNS에 등록하는 정보(A, AAAA, CNAME, MX, NS, PTR…)
DNS Resolver	OS에 내장된 "DNS에 질의하는 기능"
재귀질의	루트부터 더듬어 반복 질의하는 과정
캐시	한 번 찾은 결과를 저장해 재질의를 줄임

1. DNS 서버와 리소스 레코드

DNS를 쓰려면 DNS 서버가 필요합니다. 이 서버에 미리 호스트명과 IP 주소의 대응 관계를 등록해 둡니다.

단, 대응 관계만이 아니라 여러 종류의 정보를 등록하는데,

이렇게 DNS 서버에 등록하는 정보를 리소스 레코드(Resource Record) 라고 부릅니다.

주요 리소스 레코드 종류:

종류 의미

💡 자주 헷갈리는 짝:
A(이름→IPv4) vs PTR(IP→이름, 역방향).
MX는 메일 라우팅,
NS는 "이 도메인을 누가 관리하나"를 가리킵니다.

이름해석이 동작하려면, 대전제로 DNS 서버에 리소스 레코드가 올바르게 등록돼 있어야 합니다.

그 위에서 다음 구조로 동작합니다.

① DNS 서버는 루트를 정점으로 한 계층 구조 DNS 서버들은 루트(root) 를 꼭짓점으로 하는 계층(트리) 구조로 연결돼 있습니다.

② 호스트에는 DNS 서버 IP가 설정돼 있음 애플리케이션이 도는 호스트(PC 등)에는 질의할 DNS 서버의 IP가 미리 설정돼 있습니다.

③ 사용자가 호스트명을 지정하면 자동 질의 사용자가 호스트명(URL 등)을 입력하면, 대응하는 IP 주소를 자동으로 DNS 서버에 질의합니다.

💡 DNS Resolver(리졸버) — DNS 서버에 질의하는 기능으로, Windows 등 운영체제에 내장돼 있습니다.
사용자가 직접 호출하지 않아도 OS가 알아서 질의합니다.

질의한 호스트명 정보가 항상 가까운 DNS 서버에 있는 건 아닙니다.

내가 관리하는 도메인이 아닌 호스트명을 찾으려면, 루트에서부터 단계적으로 여러 번 질의를 반복해야 합니다.

이렇게 DNS가 이름해석을 위해 반복해서 묻는 과정을 재귀질의(Recursive Query) 라고 합니다.

대략적인 흐름:

리졸버 → 루트 DNS → (TLD: .com 담당 DNS) → (권한 DNS: n-study.com 담당) → IP 응답

매번 루트부터 재귀질의하는 것은 비효율적입니다.

그래서 DNS 서버와 리졸버는 질의 결과를 한동안 캐시(cache)에 보관합니다.

💡 그래서 같은 사이트를 두 번째 접속할 때가 더 빠른 데에는 이 DNS 캐시의 역할도 있습니다.

핵심 한 줄:

"DNS 서버에 리소스 레코드를 등록해 두면,
OS의 리졸버가 루트부터 재귀질의로 IP를 찾아오고,
결과는 캐시로 재사용한다."

시험·실무 포인트

리소스 레코드: A(IPv4)/AAAA(IPv6)/CNAME(별명)/MX(메일)/NS(관리 DNS)/PTR(역방향) — 종류별 의미를 짝으로 암기.
재귀질의 vs 반복질의: 리졸버가 결과를 받을 때까지 대신 물어주는 게 재귀질의의 핵심.
계층 구조: 루트 → TLD(.com) → 권한 DNS 순으로 위임.
캐시(TTL): 성능 핵심이자, DNS 변경이 즉시 반영 안 되는 이유.