CS2026.09.239 min read

DNS: 도메인 이름을 IP 주소로 해석하는 분산 계층 시스템

도메인 이름 시스템(DNS)은 사람이 읽는 도메인 이름을 서버의 IP 주소 같은 자원 정보로 변환한다. 재귀 질의, 반복 질의, 계층적 위임, 캐시를 결합해 전 세계 도메인을 분산 관리한다. 레코드 종류, TTL, 캐시 계층을 이해하면 접속 장애와 배포 지연을 빠르게 진단할 수 있다.

By 송민성

1. 개념

도메인 이름 시스템(DNS, Domain Name System)은 도메인 이름과 관련 자원 정보를 저장하고 조회하는 분산 데이터베이스다.

웹 브라우저가 www.example.com에 접속하려면 먼저 서버의 IP 주소를 알아야 한다. DNS는 다음과 같은 이름을 주소로 해석한다.

text

www.example.com → 93.184.216.34

이 과정을 이름 해석(name resolution)이라고 한다. DNS는 IP 주소 외에도 메일 서버, 별칭, 인증용 문자열 같은 정보를 관리한다.

도메인 이름은 오른쪽부터 왼쪽으로 계층을 이룬다.

text

www.example.com.
│   │       │
│   │       └─ 루트(root)
│   └───────── 최상위 도메인(TLD)
└───────────── 호스트 또는 하위 도메인

끝의 점은 루트 도메인을 나타낸다. 보통 애플리케이션에서는 생략한다.

주요 구성 요소는 다음과 같다.

스텁 리졸버(stub resolver): 운영체제나 애플리케이션에서 DNS 조회를 요청한다.
재귀 리졸버(recursive resolver): 최종 답을 찾을 때까지 다른 DNS 서버에 질의한다.
루트 네임 서버(root name server): 최상위 도메인 네임 서버의 위치를 안내한다.
최상위 도메인 네임 서버(TLD name server): 권한 네임 서버의 위치를 안내한다.
권한 네임 서버(authoritative name server): 특정 도메인의 실제 레코드를 제공한다.

대표적인 자원 레코드(resource record)는 다음과 같다.

레코드	역할
A	도메인을 IPv4 주소에 연결
AAAA	도메인을 IPv6 주소에 연결
CNAME	이름을 다른 도메인 이름의 별칭으로 연결
MX	메일을 받을 서버 지정
NS	도메인의 권한 네임 서버 지정
TXT	도메인 소유권 검증, SPF 같은 문자열 정보 저장
SOA	영역(zone)의 기본 관리 정보 저장
PTR	IP 주소를 도메인 이름으로 역방향 조회
CAA	인증서 발급을 허용할 인증 기관 지정

2. 왜 사용하는가

IP 주소만으로 서비스를 운영하면 서버 이전이나 인프라 변경 때마다 사용자가 새 주소를 알아야 한다. DNS는 서비스 이름과 물리적 주소를 분리한다.

text

사용자 → api.example.com → 현재 서버 IP

서버 IP가 바뀌어도 DNS 레코드만 수정하면 사용자는 같은 이름을 계속 사용할 수 있다.

DNS는 다음 문제를 해결한다.

사람이 기억하기 쉬운 이름을 제공한다.
도메인 관리 권한을 계층별로 위임한다.
캐시를 이용해 반복 조회 비용을 줄인다.
여러 IP 주소를 반환해 트래픽을 분산할 수 있다.
메일 라우팅과 도메인 소유권 검증 정보를 제공한다.

DNS는 중앙 서버 하나가 모든 도메인을 관리하지 않는다. 루트, 최상위 도메인, 개별 도메인 운영자가 각 계층을 나눠 관리한다. 일부 서버에 장애가 생겨도 전체 이름 체계가 한꺼번에 멈추지 않도록 만든 구조다.

3. 동작 원리

재귀 질의와 반복 질의

클라이언트는 보통 재귀 리졸버에 재귀 질의(recursive query)를 보낸다. 재귀 리졸버는 캐시에 답이 없으면 여러 권한 계층에 반복 질의(iterative query)를 보낸다.

www.example.com의 A 레코드를 찾는 흐름은 다음과 같다.

text

1. 브라우저가 운영체제에 www.example.com 조회 요청
2. 운영체제가 재귀 리졸버에 최종 답 요청
3. 재귀 리졸버가 루트 서버에 질의
4. 루트 서버가 .com 네임 서버 정보 반환
5. 재귀 리졸버가 .com 네임 서버에 질의
6. .com 네임 서버가 example.com 권한 네임 서버 정보 반환
7. 재귀 리졸버가 권한 네임 서버에 질의
8. 권한 네임 서버가 www.example.com의 레코드 반환
9. 재귀 리졸버가 답을 캐시하고 클라이언트에 전달

루트 서버와 최상위 도메인 서버는 대개 최종 IP 주소 대신 다음 질의 대상을 알려준다. 이를 위임(delegation)이라고 한다.

캐시와 TTL

각 DNS 레코드에는 생존 시간(TTL, Time To Live)이 들어간다.

text

example.com.  300  IN  A  192.0.2.10

300은 해당 응답을 최대 300초 동안 캐시할 수 있다는 뜻이다. TTL이 지나면 리졸버는 새 응답을 조회해야 한다.

캐시는 여러 위치에 존재할 수 있다.

브라우저 내부 캐시
운영체제 DNS 캐시
로컬 네트워크 장비 캐시
인터넷 서비스 제공자나 공용 재귀 리졸버 캐시

존재하지 않는 이름에 대한 응답도 캐시될 수 있다. 이를 부정 캐시(negative caching)라고 한다. 잘못 만든 도메인을 바로 수정해도 한동안 NXDOMAIN 응답이 남을 수 있다.

전송 방식

일반 DNS 조회는 주로 사용자 데이터그램 프로토콜(UDP, User Datagram Protocol)의 53번 포트를 사용한다. 응답이 크거나 잘렸다는 표시가 있으면 전송 제어 프로토콜(TCP, Transmission Control Protocol)로 다시 질의할 수 있다.

DNS 영역 전송(zone transfer)은 일반적으로 TCP를 사용한다. 최신 DNS는 확장 메커니즘(EDNS, Extension Mechanisms for DNS)을 통해 UDP에서도 더 큰 메시지를 처리할 수 있다.

DNS 자체는 기본적으로 질의 내용을 암호화하지 않는다. 다음 방식은 클라이언트와 재귀 리졸버 사이의 질의를 암호화한다.

HTTPS 기반 DNS(DoH, DNS over HTTPS)
TLS 기반 DNS(DoT, DNS over TLS)

DNS 보안 확장(DNSSEC, DNS Security Extensions)은 응답에 디지털 서명을 추가해 데이터의 출처와 무결성을 검증한다. DNS 질의 내용을 암호화하는 기술은 아니다.

CNAME 해석

CNAME은 현재 이름이 다른 정규 이름(canonical name)의 별칭임을 나타낸다.

text

www.example.com.  IN  CNAME  web.example.net.
web.example.net.  IN  A      192.0.2.20

리졸버는 CNAME 대상의 주소 레코드를 추가로 해석해야 한다. 별칭 연결이 길어질수록 추가 질의와 지연이 발생할 수 있다.

4. 코드 예제

다음 파이썬 코드는 운영체제의 이름 해석 기능을 사용해 도메인의 IPv4와 IPv6 주소를 조회한다.

python

import socket


def resolve(domain: str) -> list[tuple[str, str]]:
    results = socket.getaddrinfo(
        domain,
        443,
        family=socket.AF_UNSPEC,
        type=socket.SOCK_STREAM,
    )

    addresses = {
        (
            "IPv6" if family == socket.AF_INET6 else "IPv4",
            sockaddr[0],
        )
        for family, _, _, _, sockaddr in results
    }
    return sorted(addresses)


def main() -> None:
    domain = "example.com"

    try:
        addresses = resolve(domain)
    except socket.gaierror as error:
        print(f"DNS 조회 실패: {error}")
        return

    for address_type, address in addresses:
        print(f"{address_type}: {address}")


if __name__ == "__main__":
    main()

터미널에서는 dig로 응답 레코드와 조회 경로를 확인할 수 있다.

shell

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig +short example.com A
dig +trace example.com

특정 재귀 리졸버에 직접 질의할 수도 있다.

shell

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

응답에서 자주 확인하는 항목은 다음과 같다.

text

status: NOERROR       질의 처리 성공
status: NXDOMAIN      도메인 이름이 존재하지 않음
ANSWER SECTION        최종 응답 레코드
AUTHORITY SECTION     권한 서버 또는 부정 응답 정보
ADDITIONAL SECTION    추가 주소 정보
Query time            조회에 걸린 시간
SERVER                응답한 재귀 리졸버

5. 시간 복잡도 또는 성능 특성

DNS 조회는 배열 탐색처럼 입력 크기만으로 시간 복잡도를 표현하기 어렵다. 성능은 캐시 적중 여부, 위임 단계, 네트워크 왕복 시간(RTT, Round-Trip Time), 재전송 여부에 크게 좌우된다.

캐시에 답이 있으면 재귀 리졸버가 즉시 응답할 수 있다. 캐시에 답이 없으면 루트, 최상위 도메인, 권한 서버를 거치는 여러 번의 네트워크 왕복이 필요하다.

개념적인 지연 시간은 다음처럼 볼 수 있다.

text

전체 지연 ≈ 재귀 리졸버 왕복 시간
          + 캐시 미스 때 발생한 외부 DNS 질의 왕복 시간의 합

TTL에 따른 특성은 다음과 같다.

설정	장점	비용
긴 TTL	권한 서버 부하와 반복 조회 감소	레코드 변경 반영이 느림
짧은 TTL	장애 전환과 주소 변경 반영이 빠름	질의량과 캐시 미스 증가

DNS에서 여러 IP 주소를 반환해도 클라이언트가 항상 같은 순서로 접속하거나 균등하게 분산된다고 보장할 수 없다. 운영체제, 브라우저, 리졸버가 주소 선택과 재정렬에 관여한다.

6. 실무 사용 사례

서비스 주소 관리

애플리케이션은 서버 IP 대신 도메인을 사용한다.

text

프런트엔드 → api.example.com
메일 발송기 → smtp.example.com
데이터 수집기 → ingest.example.com

인프라를 교체할 때 애플리케이션 설정을 모두 수정하지 않고 DNS 대상만 바꿀 수 있다.

콘텐츠 전송 네트워크 연결

CNAME을 사용해 정적 파일 도메인을 콘텐츠 전송 네트워크(CDN, Content Delivery Network)에 연결할 수 있다.

text

static.example.com → service.cdn-provider.example

콘텐츠 전송 네트워크는 클라이언트 위치와 네트워크 상태 등을 바탕으로 적절한 서버 주소를 응답할 수 있다.

메일 전달과 인증

MX 레코드는 도메인의 수신 메일 서버를 지정한다. TXT 레코드는 발신자 정책 프레임워크(SPF, Sender Policy Framework), 도메인키 식별 메일(DKIM, DomainKeys Identified Mail), 도메인 기반 메시지 인증(DMARC, Domain-based Message Authentication, Reporting and Conformance) 설정에 사용된다.

장애 전환

주 서버 장애 시 DNS 레코드를 대체 서버 주소로 변경할 수 있다. 다만 기존 캐시가 TTL 동안 남으므로 DNS 변경만으로 즉시 전환된다고 가정하면 안 된다.

배포 장애 진단

도메인 접속이 실패하면 다음 순서로 범위를 좁힌다.

dig로 원하는 레코드가 반환되는지 확인한다.
여러 재귀 리졸버의 응답을 비교한다.
권한 네임 서버에 직접 질의한다.
TTL과 부정 캐시를 확인한다.
DNS가 정상이면 방화벽, 전송 계층 보안(TLS), 웹 서버 설정을 확인한다.

7. 주의할 점

DNS 전파는 단일 작업이 아니다

“DNS가 전파된다”는 표현은 여러 캐시가 각자의 TTL에 따라 만료되고 새 값을 조회하는 과정을 뜻한다. 모든 서버에 변경 사항을 복사하는 중앙 전파 작업이 아니다.

TTL을 변경 직전에 낮춰도 늦을 수 있다

기존 레코드가 긴 TTL로 이미 캐시됐다면 새 TTL도 기존 캐시가 만료된 뒤에야 적용된다. 계획된 이전에서는 기존 TTL이 만료될 시간을 고려해 미리 낮춰야 한다.

CNAME 사용 위치에 제약이 있다

표준 DNS에서는 같은 이름에 CNAME과 다른 레코드를 함께 둘 수 없다. 영역 정점(zone apex)은 보통 NS와 SOA 레코드를 가져야 하므로 일반적인 CNAME을 둘 수 없다. 일부 DNS 사업자는 별도 기능으로 정점 별칭을 제공한다.

DNSSEC와 암호화를 혼동하면 안 된다

DNSSEC는 응답 변조 여부를 검증한다. DoH와 DoT는 클라이언트와 재귀 리졸버 사이의 질의를 암호화한다. 해결하는 문제가 다르다.

애플리케이션의 DNS 캐시를 확인해야 한다

운영체제 캐시가 만료돼도 자바 가상 머신, 웹 브라우저, 프록시, 연결 풀 같은 구성 요소가 주소나 기존 연결을 더 오래 유지할 수 있다. 장애 전환 시간을 계산할 때 DNS TTL만 보면 안 된다.

8. 핵심 정리

DNS는 도메인 이름과 IP 주소 같은 자원 정보를 연결하는 분산 계층 시스템이다.
재귀 리졸버는 캐시가 없을 때 루트, 최상위 도메인, 권한 네임 서버를 차례로 조회한다.
TTL은 캐시 가능 시간을 정하며 조회 성능과 변경 반영 속도 사이의 균형을 만든다.
A, AAAA, CNAME, MX, NS, TXT 레코드는 서로 다른 역할을 담당한다.
실무에서는 dig로 응답값, 권한 서버, TTL, 상태 코드, 리졸버별 차이를 확인한다.