DNS의 구조와 동작

브라우저 주소창에 www.google.com을 입력하면 구글의 웹 페이지가 나타납니다.

하지만 TCP/IP로 패킷을 보내려면 먼저 목적지 IP 주소가 필요합니다.

사람이 쓰는 도메인 이름을 IP 주소나 다른 DNS 데이터로 해석해 주는 분산 시스템이 DNS(Domain Name System)입니다.

DNS는 전화번호부에 비유되곤 하지만, 실제로는 전 세계에 분산된 거대한 계층적 데이터베이스입니다.

도메인 이름 체계

도메인 이름은 오른쪽에서 왼쪽으로 계층 구조를 가집니다.

• 루트(Root): 도메인의 최상위입니다. 보통 표기하지 않지만, 정확히는 www.example.com.처럼 마지막에 점이 하나 더 있습니다. 이 마지막 점이 루트를 의미합니다.

• TLD(Top-Level Domain): com, org, net, kr 등 최상위 도메인입니다. .com은 일반 TLD(gTLD), .kr은 국가 코드 TLD(ccTLD)입니다.

• SLD(Second-Level Domain): example처럼 일반적으로 조직이나 서비스를 식별하는 부분입니다. .com 같은 gTLD에서는 보통 이 레벨을 등록하지만, co.kr처럼 국가 코드 도메인 정책에 따라 더 아래 레벨을 등록하는 경우도 있습니다.

• 서브도메인(Subdomain): www, api, mail 등 도메인 소유자가 자유롭게 설정하는 부분입니다.

이름 계층의 일부 경계에서 관리 영역(zone)을 위임합니다. 모든 label마다 별도 서버나 zone이 필요한 것은 아닙니다.

DNS 서버 종류

DNS 질의에서 자주 만나는 역할을 나누어 보겠습니다. 루트와 TLD 서버도 자신이 맡은 zone의 권한 서버입니다.

DNS 리졸버(Recursive Resolver): 클라이언트의 stub resolver가 보낸 질의를 받아, 답을 찾을 때까지 다른 DNS 서버들에게 반복 질의를 수행하는 서버입니다.

ISP가 운영하거나, 8.8.8.8(Google), 1.1.1.1(Cloudflare) 같은 공개 리졸버를 사용할 수 있습니다.

"대리 조회자" 역할입니다.

루트 DNS 서버(Root Name Server): 도메인 계층의 최상위를 담당합니다.

.com이면 어디로, .kr이면 어디로 가야 하는지를 알려줍니다.

루트 서버는 A부터 M까지 13개의 이름을 가지며, 각 이름은 애니캐스트를 통해 여러 물리적 인스턴스로 전 세계에 분산됩니다.

TLD DNS 서버: .com, .org, .kr 같은 최상위 도메인을 담당합니다.

example.com에 대한 질의를 받으면 해당 zone의 권한 NS 위임 정보를 알려주며, 필요한 주소 정보가 함께 올 수 있습니다.

권한 DNS 서버(Authoritative Name Server): 특정 DNS zone의 내용을 알고 있는 서버입니다.

example.com의 IP 주소가 무엇인지, 메일 서버는 어디인지 등의 권한 있는 답변을 제공합니다.

도메인 소유자나 DNS 호스팅 사업자가 레코드를 관리합니다.

루트 서버 이름과 물리적 설치 지점은 다른 수입니다. 위 표는 운영자 예시이며, 루트 서버 운영자 공동 목록에서 이름별 운영자를 확인할 수 있습니다. 인스턴스 수는 계속 달라지므로 여기서는 고정된 최신 총수를 외우지 않습니다.

재귀 질의 vs 반복 질의

브라우저가 www.example.com의 IP 주소를 알아내는 전체 과정을 따라가 보겠습니다.

재귀 질의는 리졸버에게 끝까지 해석해 달라는 요청입니다. 리졸버는 반복 질의의 답이나 위임 정보를 따라가고, 클라이언트에는 최종 답변·부정 응답(NXDOMAIN 등)·오류를 돌려줍니다.

얻은 레코드는 TTL 범위에서 캐시할 수 있으므로 이후 질의에서는 관련 서버를 다시 방문하지 않을 수 있습니다.

예시 도식의 주소 192.0.2.44는 실제 서비스 조회 결과가 아닌 학습용 값입니다. 답과 위임 정보가 없는 리졸버가 www.example.com. A를 묻는다고 가정합니다. 루트는 최종 웹 서버 주소 대신 .com의 NS 위임 정보를 줍니다. 리졸버가 그 정보를 사용해 .com 서버에 묻고, example.com 권한 서버의 위치를 얻은 다음 그 서버에 같은 목적의 질의를 보냅니다. 루트가 TLD에 질문을 대신 전달하는 흐름은 아닙니다.

반복 질의도 최종 답을 얻으면 그 답을 받을 수 있습니다. 언제나 “다음 서버 주소만 받는다”는 뜻은 아닙니다. 재귀와 반복의 차이는 처음 질문받은 서버가 나머지 조회를 대신 수행하느냐입니다. 서버를 찾는 위임 정보와 원하는 A 레코드는 서로 다른 캐시 항목이므로, A의 TTL이 끝나도 살아 있는 NS 정보를 활용해 곧바로 권한 서버에 물을 수 있습니다. RFC1034의 리졸버 모델에서 이 역할을 확인할 수 있습니다.

DNS 캐시 계층

실제로는 매번 루트 서버부터 질의하지 않습니다.

브라우저나 애플리케이션, 운영체제 stub resolver, hosts 파일, 재귀 리졸버 등 여러 지점에서 캐시나 로컬 규칙이 개입할 수 있습니다.

정확한 순서는 운영체제와 애플리케이션 설정에 따라 달라집니다.

아래 명령 묶음은 한 운영체제에서 모두 실행하는 스크립트가 아닙니다. 자기 운영체제의 줄만 선택합니다. resolvectl은 systemd-resolved를 사용하는 환경의 도구이며, 캐시 초기화에는 필요한 권한이 있어야 합니다. OS 캐시를 비워도 브라우저나 별도 재귀 리졸버의 캐시를 함께 지우는 것은 아닙니다.

# Windows: OS DNS 캐시 확인
ipconfig /displaydns | findstr "Record Name"

# Windows: OS DNS 캐시 초기화
ipconfig /flushdns

# Linux: systemd-resolved 캐시 통계
resolvectl statistics

# macOS: DNS 캐시 초기화
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# hosts 파일 확인 (로컬 DNS 오버라이드)
# Windows: type C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: cat /etc/hosts

import socket

def resolve_domain(domain):
    """도메인 이름을 IP 주소로 해석"""
    try:
        # getaddrinfo: IPv4 + IPv6 모두 조회
        results = socket.getaddrinfo(domain, None)

        seen = set()
        for family, _, _, _, sockaddr in results:
            ip = sockaddr[0]
            if ip not in seen:
                seen.add(ip)
                version = "IPv4" if family == socket.AF_INET else "IPv6"
                print(f"  {version}: {ip}")

        # gethostbyname: IPv4만 (간단한 조회)
        ipv4 = socket.gethostbyname(domain)
        print(f"\n  기본 IPv4: {ipv4}")

    except socket.gaierror as e:
        print(f"  해석 실패: {e}")

# 여러 도메인 조회
domains = ["google.com", "naver.com", "github.com"]
for domain in domains:
    print(f"\n{domain}:")
    resolve_domain(domain)

이 과정에서 재귀 리졸버가 대리 조회자로서 여러 권한 서버를 따라가며 답을 찾아오기 때문에, 클라이언트는 복잡한 위임 구조를 직접 순회하지 않고 하나의 질문만 던질 수 있습니다.

캐시 시간을 직접 판단하기 리졸버가 0초에 A 레코드 192.0.2.44와 TTL 60을 저장했고, 권한 서버에서 20초에 주소를 192.0.2.45로 바꾸었다고 가정합니다. 이 문제에서는 다른 캐시, 사전 갱신, TTL 상한 조정, serve-stale을 사용하지 않습니다. 35초에 질문한 클라이언트는 어느 주소를 받을 수 있으며, 기존 항목의 남은 재사용 시간은 얼마일까요? 권한 서버에서 20초에 새 TTL을 5로 낮추었다면 기존 캐시도 그때 즉시 만료될까요?

Python 출력의 범위 dns_resolver.py는 DNS 패킷을 직접 만들어 루트부터 추적하는 프로그램이 아닙니다. OS의 이름 해석 API를 호출하므로 hosts나 캐시 같은 로컬 규칙도 결과에 개입할 수 있습니다. 먼저 IPv4·IPv6 후보를 출력한 뒤, 별도의 IPv4 전용 gethostbyname을 호출합니다. IPv6만 있는 가상의 입력에서는 앞 조회가 성공해 IPv6를 출력한 뒤 뒷 조회가 실패해 “해석 실패”를 출력할 수 있습니다. 그 경우를 이름의 모든 해석이 실패했다거나 IPv6가 무효라는 뜻으로 읽지 마세요. 중복 제거는 같은 주소 문자열을 한 번 보여 주기 위한 것이며, 출력된 주소로 실제 TCP 연결이 성공했는지도 이 코드에서는 확인하지 않습니다.

DNS 면접 포인트

다음 절에서는 DNS 서버가 저장하는 구체적인 레코드 유형과 실습 도구를 살펴보겠습니다.