DNS Record 종류와 조회법: A·AAAA·CNAME·MX·NS·TXT·PTR

DNS record는 이름에 관한 정보를 NAME, TTL, CLASS, TYPE, RDATA로 표현한 resource record다. 운영할 때는 record 이름만 외우기보다 누가 authoritative answer를 주는지, cache에 얼마나 남는지, target에 어떤 제약이 있는지까지 함께 봐야 한다.

자주 쓰는 DNS Record 한눈에 보기

Type	저장하는 정보	운영할 때 볼 점
A	이름에 대응하는 IPv4 address	같은 이름에 여러 주소를 둘 수 있음
AAAA	이름에 대응하는 IPv6 address	IPv4와 별개로 client 경로를 확인
CNAME	다른 canonical name을 가리키는 alias	alias owner에 다른 일반 data를 함께 두지 않음
MX	mail exchanger와 preference	숫자가 낮을수록 우선, target은 hostname이어야 함
NS	zone의 authoritative name server	delegation이면 glue record 필요 여부 확인
TXT	임의 text	SPF·domain verification 등 목적별 문법을 별도 검증
PTR	IP address의 reverse name	IP block을 관리하는 provider 쪽 설정이 필요할 수 있음

모든 이름이 IP address로 끝나는 것은 아니다. MX, NS, CNAME처럼 다른 DNS name을 가리키는 record도 있고, TXT처럼 정책이나 verification 값을 전달하는 record도 있다.

A와 AAAA: 주소를 찾는 record

A는 IPv4, AAAA는 IPv6 address를 반환한다.

www.example.com.  300  IN  A     192.0.2.10
www.example.com.  300  IN  AAAA  2001:db8::10

192.0.2.0/24와 2001:db8::/32는 문서 예시에 예약된 범위다. 실제 service 설정에는 provider가 할당한 주소를 사용한다.

같은 hostname에 A와 AAAA가 모두 있다고 해서 두 경로의 품질이 같다는 뜻은 아니다. 접속 문제를 조사할 때는 IPv4·IPv6 응답과 실제 routing을 따로 확인한다.

CNAME: 별칭을 다른 이름에 연결하기

blog.example.com.  300  IN  CNAME  sites.example.net.

resolver는 blog.example.com을 조회한 뒤 canonical name을 따라간다. 여기에는 두 가지 중요한 제한이 있다.

• CNAME이 있는 owner name에는 DNSSEC 관련 예외를 제외한 다른 data를 함께 두지 않는다.
• zone apex에는 이미 SOA, NS record가 필요하므로 일반적인 CNAME을 둘 수 없다.

일부 DNS provider가 제공하는 ALIAS, ANAME, flattening은 이 문제를 우회하는 provider 기능이다. 표준 CNAME record와 동일하다고 가정하지 말고 provider 문서를 확인한다.

MX와 NS: target name의 제약

MX record의 preference 값은 작을수록 먼저 시도한다.

example.com.  3600  IN  MX  10 mail1.example.net.
example.com.  3600  IN  MX  20 mail2.example.net.

MX target에는 IP address가 아니라 hostname을 쓴다. RFC 2181 기준으로 MX와 NS의 target이 alias가 되면 안 되므로 target name이 A 또는 AAAA record로 직접 해석되는지도 확인한다.

NS는 zone에 authoritative한 name server를 나타낸다. parent zone에서 child zone으로 delegation할 때 name server 주소를 찾기 위해 순환 의존이 생기면 parent에 glue A·AAAA record가 필요하다.

TXT, SPF와 DMARC를 구분하기

TXT는 범용 text container다. SPF나 DMARC는 TXT를 운반 형식으로 사용하지만 각각 별도의 정책 문법을 가진다.

example.com.         300 IN TXT "v=spf1 include:_spf.example.net ~all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine"

SPF의 ~all은 softfail 결과를 뜻한다. 그 한 줄만으로 message가 자동으로 spam 처리된다고 단정할 수 없다. receiver는 SPF 결과뿐 아니라 DKIM, DMARC, local policy와 reputation 등을 함께 판단할 수 있다.

DMARC는 2026년에 RFC 9989로 표준이 갱신되어 RFC 7489를 대체했다. 실제 mail 설정은 현재 RFC와 사용하는 provider의 요구 사항을 같이 확인한다.

PTR: IP에서 이름을 찾는 reverse DNS

forward lookup이 이름에서 address를 찾는다면 PTR은 address에서 name을 찾는다. IPv4는 in-addr.arpa, IPv6는 ip6.arpa tree를 사용한다.

dig -x 192.0.2.10

PTR은 일반 domain zone에 A record를 추가하는 것만으로 설정되지 않는다. public IP를 보유한 ISP나 cloud provider가 reverse zone을 관리한다면 그 provider console이나 support 절차를 거쳐야 한다.

dig로 record와 응답 경로 확인하기

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
dig -x 192.0.2.10

짧은 값만 보고 싶으면 +short가 편하지만, 장애 분석에서는 full output의 다음 항목이 중요하다.

• status: NOERROR, NXDOMAIN, SERVFAIL 등
• ANSWER: 최종 answer
• AUTHORITY: authoritative information
• SERVER: 답을 준 recursive resolver
• Query time: 이번 resolver까지의 응답 시간

delegation 경로를 따라가려면 다음처럼 확인할 수 있다.

dig +trace example.com NS

+trace는 local recursive resolver의 평소 결과와 다른 관점을 준다. 실제 client 문제라면 client가 쓰는 resolver의 결과와 authoritative server의 답을 각각 확인한다. 이어서 네트워크 트러블슈팅 명령어의 dig, tcpdump, curl을 함께 보면 DNS 다음 단계까지 좁힐 수 있다.

TTL과 이른바 전파 시간

DNS 변경이 전 세계로 한 번에 복사되는 단일 “전파 완료 시각”은 없다. recursive resolver와 client cache가 기존 answer를 TTL 동안 보관할 수 있어 관찰 시점이 달라진다.

변경 전에는 TTL을 미리 낮추고, 변경 후에는 다음을 분리해서 본다.

1. authoritative server에 새 값이 올라갔는가
2. 각 recursive resolver가 어떤 cached answer를 주는가
3. application이나 OS가 별도 cache를 갖는가
4. negative answer의 cache가 남았는가

DNSSEC는 DNS data의 출처 인증과 무결성을 돕지만 내용을 암호화하지 않는다. DoT·DoH는 client와 resolver 사이 transport를 암호화하는 기술이라 책임 범위가 다르다. URI 구조와 HTTP request의 경계는 URI·URL·URN 차이에서 이어서 정리했다.

자주 묻는 질문

CNAME과 A record를 같은 이름에 둘 수 있나

일반적으로 안 된다. CNAME owner에는 다른 일반 DNS data를 함께 둘 수 없다. zone apex의 CNAME이 곤란한 이유도 SOA·NS record와 충돌하기 때문이다.

DNS 변경이 바로 안 보이면 실패한 건가

아니다. authoritative answer는 바뀌었지만 recursive·OS·application cache에 이전 값이 남아 있을 수 있다. 어디에서 어떤 resolver로 조회했는지부터 구분한다.

DNSSEC를 켜면 DNS 조회 내용이 숨겨지나

아니다. DNSSEC의 주된 목적은 authenticity와 integrity다. transport confidentiality는 DoT·DoH 같은 별도 mechanism의 영역이다.

참고 자료

• RFC 1034: Domain Names—Concepts and Facilities
• RFC 1035: Domain Names—Implementation and Specification
• RFC 2181: Clarifications to the DNS Specification
• RFC 7208: Sender Policy Framework
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• IANA Domain Name System Parameters