본문으로 건너뛰기

안동민 개발노트

본문 시작

DNS 레코드와 실습

A·AAAA·CNAME·MX·NS·TXT 레코드의 의미와 제약을 익히고 nslookup·dig으로 응답과 TTL을 확인합니다.

DNS 서버가 도메인에 대한 정보를 저장한다는 것을 알았습니다.

이제 그 정보가 어떤 리소스 레코드(Resource Record) 형태로 표현되는지, 그리고 nslookupdig으로 직접 확인하는 방법을 살펴보겠습니다.


주요 DNS 레코드 유형

DNS 레코드는 “도메인 이름에 연결된 데이터”입니다.

표준적인 리소스 레코드는 보통 이름, TTL, 클래스, 타입, 데이터로 읽습니다.

예를 들어 example.com. 3600 IN A 93.184.216.34example.com 이름의 IPv4 주소를 3600초 동안 캐시할 수 있다는 뜻입니다.

DNS 레코드 한 줄은 다섯 칸으로 읽는다

`example.com. 3600 IN A 93.184.216.34`는 이름, 캐시 시간, 클래스, 타입, 실제 값으로 분해된다.

  1. NAME

    example.com. 레코드가 붙는 소유 이름

  2. TTL

    3600 캐시 가능한 초

  3. CLASS

    IN 인터넷 클래스

  4. TYPE

    값 해석 방식

  5. RDATA

    93.184.216.34 타입별 실제 데이터

가장 자주 만나는 레코드 유형은 아래와 같습니다.

레코드 타입은 RDATA를 어떻게 읽을지 정한다

같은 DNS 한 줄이라도 TYPE이 달라지면 값의 의미와 검증할 항목이 달라진다.

  1. 주소와 이름

    름을 IPv4 주소로 연결한다. AAAA 이름을 IPv6 주소로 연결한다. CNAME 별칭 이름을 canonical name으로 넘긴다. PTR IP 주소에서 역방향 이름을 찾는다.

  2. 영역과 전달

    NS 이 영역의 권한 네임서버를 가리킨다. SOA serial과 refresh 등 영역 메타데이터를 담는다. MX 메일을 받을 서버와 우선순위를 지정한다. SRV 서비스 위치, 포트, 가중치를 표현한다.

  3. 정책과 검증

    TXT SPF, DKIM, DMARC 같은 문자열 정책을 싣는다. CAA 인증서를 발급할 수 있는 CA를 제한한다. DNSKEY DNSSEC 검증에 필요한 공개키를 제공한다. DS 부모 영역에서 자식 영역의 DNSSEC 키를 연결한다.

레코드용도예시읽을 때 주의할 점
A이름 → IPv4 주소example.com. A 93.184.216.34하나의 이름에 여러 A가 있을 수 있음
AAAA이름 → IPv6 주소example.com. AAAA 2606:2800:220:1::IPv6 주소용 레코드
CNAME별칭 이름 → canonical namewww CNAME example.com.같은 이름에 일반 레코드와 공존 불가
MX메일 교환 서버 지정example.com. MX 10 mail.example.com.숫자가 낮을수록 우선순위가 높음
NS영역의 권한 네임서버 지정example.com. NS ns1.example.com.위임과 권한 서버 확인에 사용
TXT텍스트 기반 정책/검증 정보v=spf1 include:_spf.example.net -allSPF, DKIM, DMARC 등 형식별 규칙 확인 필요
SRV서비스 위치와 포트 지정_sip._tcp.example.com. SRV 10 60 5060 host지원하는 프로토콜에서만 의미가 있음
SOA영역 시작과 관리 메타데이터ns1.example.com. hostmaster.example.com.serial, refresh, retry, expire 포함
PTR역방향 이름 → canonical name34.216.184.93.in-addr.arpa. PTR ...IP 소유자가 관리하는 역방향 영역 필요
CAA인증서 발급 가능한 CA 제한example.com. CAA 0 issue "letsencrypt.org"CA의 오발급 위험을 줄이는 정책

CNAME의 제약과 대안

CNAME은 별칭을 만들 때 편하지만, 같은 이름에 다른 일반 레코드와 함께 둘 수 없습니다.

예를 들어 zone apex인 example.com에는 보통 SOA와 NS가 반드시 필요하므로 표준 DNS 관점에서 example.com CNAME ... 형태는 맞지 않습니다.

CNAME은 같은 이름의 다른 일반 레코드와 함께 둘 수 없다

CNAME은 “이 이름의 모든 질의를 canonical name으로 넘긴다”는 뜻이라 같은 owner name에 A, MX, TXT를 함께 둘 수 없다.

  1. 표준 DNS에서 충돌

    www.example.com. CNAME app.example.net. www.example.com. A 203.0.113.10 판정 불가 같은 owner name에 CNAME과 일반 레코드가 섞였다.

  2. apex에서 쓰는 대안

    example.com. SOA / NS 영역 운영에 필요 example.com. ALIAS / ANAME 제공자 기능으로 A/AAAA처럼 응답 판정 가능 표준 CNAME이 아니라 권한 DNS가 값을 펼쳐 준다.

클라우드 DNS 서비스의 ALIAS, ANAME, CNAME flattening, Route 53 Alias 같은 기능은 이 제약을 우회하기 위한 제공자별 기능입니다.

이것들은 표준 CNAME 레코드라기보다 권한 DNS 서버가 대상 이름을 해석한 뒤 A/AAAA 응답처럼 돌려주는 방식에 가깝습니다.


MX 레코드와 이메일 보안 레코드

MX 레코드는 메일을 어느 서버로 전달할지 알려줍니다.

MX의 숫자는 “선호도(preference)”이며, 낮은 숫자가 먼저 시도됩니다.

같은 선호도의 MX가 여러 개라면 메일 전송 서버는 그 후보들을 나누어 시도할 수 있습니다.

MX 우선순위는 숫자가 낮은 서버부터 시도한다

메일 전송 서버는 preference가 가장 낮은 MX를 먼저 선택하고, 실패하면 다음 후보로 넘어간다.

  1. mail-a.example.com.

    장 먼저 시도

  2. mail-b.example.com.

    첫 후보 실패 시 시도

  3. mail-c.example.com.

    같은 preference 후보는 나누어 시도 가능

  4. 장애 분석에서 보는 항목

    항목 정상 확인 포인트 preference 낮은 숫자 우선 백업 MX가 의도보다 먼저 선택되지 않는지 확인 target 호스트 이름 MX target 자체의 A/AAAA 조회가 성공해야 함 TTL 변경 전파 시간 메일 전환 작업 전에는 TTL을 미리 낮춘다

이메일 보안에서는 TXT 레코드를 정책 저장소처럼 많이 사용합니다.

단, TXT는 단순한 문자열 컨테이너일 뿐이고, SPF/DKIM/DMARC는 각각 별도 규칙을 가진 프로토콜입니다.

SPF, DKIM, DMARC는 TXT에 실리지만 검증 대상이 다르다

TXT는 문자열 저장소이고, 실제 규칙은 SPF, DKIM, DMARC 프로토콜이 각각 해석한다.

  1. SPF example.com TXT envelope

    sender의 허용 발신원 같은 이름에 SPF 정책을 두 개 이상 게시

  2. DKIM

    selector._domainkey.example.com 메일 서명의 공개키와 selector selector 오타 또는 긴 TXT 분할 오류

  3. _dmarc.example.com TXT

    From 도메인 alignment와 정책 SPF/DKIM 통과와 DMARC alignment를 혼동

항목DNS 위치 예시하는 일자주 나는 실수
SPFexample.com TXT "v=spf1 ..."envelope sender 도메인의 허용 발신원 선언같은 이름에 SPF 레코드를 여러 개 게시
DKIMselector._domainkey.example.com공개키로 메일 서명 검증selector 이름이나 긴 TXT 문자열 오류
DMARC_dmarc.example.com TXT "v=DMARC1"SPF/DKIM alignment와 정책, 리포트 주소 선언SPF/DKIM과 From 도메인 alignment 혼동

nslookup과 dig 실습

DNS 레코드를 직접 조회할 때는 nslookupdig을 많이 사용합니다.

nslookup은 기본 확인에 편하고, dig은 응답 섹션, 플래그, TTL, 권한 서버 추적을 더 자세히 보여줍니다.

nslookup 기본 사용법
# 기본 A 레코드 조회
nslookup example.com

# 특정 레코드 유형 조회
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=AAAA example.com

# 특정 DNS 서버를 지정하여 조회
nslookup example.com 1.1.1.1

# 역방향 DNS 조회
nslookup 93.184.216.34
nslookup은 빠른 확인, dig은 응답 해부에 맞다

둘 다 DNS를 조회하지만, 장애 분석에서는 dig의 섹션, 플래그, TTL, 권한 경로가 더 많은 단서를 준다.

  1. nslookup

    type=MX example.com 강점 빠르게 특정 타입 응답을 확인한다. 한계 응답 섹션과 권한 경로를 자세히 보기 어렵다. 적합 로컬 PC에서 이름 해석 여부를 빠르게 볼 때

  2. dig

    @1.1.1.1 example.com A +trace 강점 ANSWER, AUTHORITY, TTL, 플래그를 분리해 본다. 한계 옵션이 많아 처음에는 출력 해석이 필요하다. 적합 캐시와 권한 서버 원본을 나누어 확인할 때

dig 기본 사용법
# A 레코드 조회
dig example.com A

# 특정 레코드 유형 조회
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com AAAA

# 간결한 출력
dig +short example.com A

# 특정 리졸버 지정
dig @1.1.1.1 example.com A

# 권한 서버 경로 추적
dig +trace example.com

# 역방향 DNS
dig -x 93.184.216.34

Non-authoritative answer는 응답이 해당 영역의 권한 서버에서 직접 온 것이 아니라 재귀 리졸버를 통해 온 응답이라는 뜻입니다.

꼭 “오래된 캐시”라는 뜻은 아니므로, 원본 상태를 확인하려면 dig +trace나 권한 NS 직접 조회를 함께 봐야 합니다.


TTL과 DNS 캐시 동작

DNS 응답의 TTL(Time To Live)은 해당 레코드를 캐시에 얼마나 오래 보관할 수 있는지 초 단위로 나타냅니다.

TTL이 길면 반복 질의가 줄어 안정적이지만 변경 반영이 느리고, TTL이 짧으면 전환은 빠르지만 리졸버와 권한 서버 질의량이 늘어납니다.

TTL은 변경 속도와 캐시 부하의 균형이다

TTL이 남아 있으면 재귀 리졸버, OS, 브라우저가 예전 응답을 계속 줄 수 있다.

  1. TTL 선택

    짧은 TTL 전환은 빠르지만 권한 서버와 리졸버 질의가 늘어난다. 긴 TTL 질의 부하는 줄지만 변경 반영이 늦어진다.

  2. 짧은 TTL

    전환은 빠르지만 권한 서버와 리졸버 질의가 늘어난다.

  3. 긴 TTL

    질의 부하는 줄지만 변경 반영이 늦어진다.

  4. 변경이 안 보일 때 확인 순서

    위치 남는 이유 확인 방법 브라우저/OS 로컬 DNS 캐시 브라우저 재시작, OS 캐시 초기화 재귀 리졸버 TTL 만료 전 캐시 응답 다른 리졸버와 비교 조회 권한 서버 원본 레코드 미변경 권한 NS 직접 조회

dns_query.py
import socket

def resolve_all(domain):
    """운영체제 리졸버를 통해 IPv4/IPv6 후보를 확인하는 간단한 예시"""
    results = socket.getaddrinfo(domain, 80, type=socket.SOCK_STREAM)
    seen = set()

    for family, _, _, _, address in results:
        ip = address[0]
        if ip in seen:
            continue
        seen.add(ip)
        version = "IPv6" if family == socket.AF_INET6 else "IPv4"
        print(f"{domain:<24} {version:<4} {ip}")

resolve_all("example.com")

캐시는 리졸버뿐 아니라 운영체제와 브라우저에도 존재합니다.

DNS 변경 후 예상과 다른 응답을 보면 브라우저 캐시, OS 캐시, 재귀 리졸버 캐시, 권한 서버 원본 레코드를 분리해서 확인해야 합니다.

존재하지 않는 이름(NXDOMAIN)도 SOA 정보와 함께 negative caching 될 수 있습니다.


DNS 실습 체크리스트

상황명령어확인 사항
기본 IP 조회dig example.com AANSWER 섹션의 A 레코드와 TTL
IPv6 조회dig example.com AAAAAAAA 응답 여부
메일 서버 확인dig example.com MX낮은 preference 우선, MX target
네임서버 확인dig example.com NS위임된 권한 서버
이메일 인증 확인dig example.com TXTSPF, DKIM, DMARC 위치별 TXT
해석 경로 추적dig +trace example.com루트 → TLD → 권한 서버
특정 리졸버 비교dig @1.1.1.1 example.com A리졸버별 캐시/응답 차이
권한 서버 직접 확인dig @ns1.example.com name A원본 레코드와 재귀 응답 차이
로컬 캐시 초기화ipconfig /flushdnsWindows OS DNS 캐시 제거

다음 절에서는 DNS의 심화 활용과 실무에서 마주치는 보안 이슈를 살펴보겠습니다.