DNS 레코드 종류와 읽는 법: A·AAAA·CNAME·MX·NS·TXT·SOA

DNS 레코드는 “도메인을 IP 주소로 바꾸는 값”보다 범위가 넓다. 이름, 타입, 클래스, TTL, 타입별 데이터로 구성된 리소스 레코드가 DNS 데이터의 기본 단위다. 장애를 볼 때는 이름이 존재하는지와 원하는 타입의 레코드가 존재하는지를 구분해야 한다.

재귀 리졸버가 권한 서버까지 답을 구하는 흐름은 DNS 조회 과정에서 다뤘다. 이 글은 권한 zone에 어떤 레코드를 두고 dig 결과를 어떻게 읽는지에 집중한다.

리소스 레코드 한 줄의 구조

다음은 www.example.com의 IPv4 주소를 표현한 zone file 형식의 예다.

www.example.com.  300  IN  A  192.0.2.10

필드	예	의미
Owner name	`www.example.com.`	레코드가 붙는 DNS 이름
TTL	`300`	캐시에 보관할 수 있는 시간(초)
Class	`IN`	Internet 클래스
Type	`A`	데이터 형식과 의미
RDATA	`192.0.2.10`	타입에 맞는 실제 값

끝의 점은 루트까지 적은 완전한 도메인 이름임을 나타낸다. zone 편집기에서 점을 생략하면 현재 zone 이름이 뒤에 붙을 수 있으므로 제공자의 입력 규칙을 확인한다.

TTL을 낮추면 변경 전파를 준비하기 쉬울 수 있지만 재귀 질의와 권한 서버 부하는 늘어난다. TTL을 올리면 캐시 효율은 좋아지지만 변경 뒤 이전 값이 오래 남을 수 있다.

A와 AAAA: 호스트 주소

A: 이름에 IPv4 주소를 연결한다.
AAAA: 이름에 IPv6 주소를 연결한다.

api.example.com.  300  IN  A     192.0.2.20
api.example.com.  300  IN  AAAA  2001:db8::20

dig api.example.com A
dig api.example.com AAAA

한 이름에 A와 AAAA가 모두 있으면 클라이언트는 네트워크 상태와 구현 정책에 따라 주소를 선택한다. “ping은 되는데 애플리케이션은 안 된다”면 애플리케이션이 IPv4와 IPv6 중 어느 주소로 연결했는지 확인한다.

CNAME: 다른 이름의 별칭

CNAME은 owner name이 canonical name의 별칭임을 나타낸다.

docs.example.com.  300  IN  CNAME  service.example.net.

클라이언트는 docs.example.com의 CNAME을 따라가 service.example.net의 A·AAAA 같은 최종 데이터를 다시 찾는다. CNAME 대상은 IP 주소가 아니라 DNS 이름이다.

CNAME owner에는 CNAME과 함께 다른 데이터가 존재하면 안 된다. 그래서 zone apex인 example.com에는 같은 이름에 필요한 SOA와 NS가 이미 있어 일반적인 CNAME을 둘 수 없다. 일부 DNS 제공자가 apex에서 제공하는 ALIAS·ANAME·flattening은 편의 기능이지 표준 CNAME 레코드 타입은 아니다. 반환되는 실제 레코드와 장애 시 동작을 제공자 문서에서 확인한다.

MX: 메일을 받을 서버와 우선순위

MX는 도메인의 메일 교환 서버를 지정한다.

example.com.  300  IN  MX  10  mx1.example.com.
example.com.  300  IN  MX  20  mx2.example.com.
mx1.example.com.  300  IN  A  192.0.2.30
mx2.example.com.  300  IN  A  192.0.2.31

우선순위 숫자가 작을수록 먼저 시도하는 대상이다. 같은 숫자가 여러 개면 송신 측이 그중 하나를 고를 수 있다. MX 대상은 주소가 아니라 호스트 이름이며, 다시 A·AAAA로 해석할 수 있어야 한다.

dig example.com MX
dig mx1.example.com A

SMTP가 MX를 이용해 메일을 전달하는 전체 흐름은 이메일 전송 과정에서 이어진다.

NS: zone을 담당하는 권한 서버

NS 레코드는 해당 zone에 권한을 가진 name server를 나타낸다.

example.com.  86400  IN  NS  ns1.example.net.
example.com.  86400  IN  NS  ns2.example.net.

상위 zone의 위임 NS와 하위 zone 권한 서버가 제공하는 apex NS가 일치하는지 확인하는 것이 좋다. 하위 NS 이름이 위임받는 zone 안에 있다면 상위 zone에 연결을 시작할 수 있는 glue 주소가 필요할 수 있다.

dig example.com NS
dig +trace example.com NS

+trace는 위임 경로를 학습하고 끊긴 지점을 찾는 데 유용하지만, 평소 사용하는 재귀 리졸버의 캐시와 정책을 그대로 재현하는 것은 아니다.

TXT: 애플리케이션이 정의한 텍스트 데이터

TXT는 하나 이상의 character-string을 담을 수 있는 범용 타입이다. SPF, DKIM, 도메인 소유권 검증 등 여러 애플리케이션이 정해진 형식으로 사용한다.

example.com.  300  IN  TXT  "v=spf1 include:_spf.example.net -all"

TXT 자체가 문자열의 의미를 검증해 주지는 않는다. 같은 이름에 여러 TXT 레코드가 있을 수 있고, 긴 값은 하나의 TXT RDATA 안에서 여러 문자열 조각으로 저장될 수 있다. 사용 중인 프로토콜이 여러 레코드와 문자열 조각을 어떻게 해석하는지 따로 확인해야 한다.

dig example.com TXT

SOA: zone의 관리와 갱신 정보

SOA(Start of Authority)는 zone의 시작과 관리 정보를 담는다.

example.com.  3600  IN  SOA  ns1.example.net. hostmaster.example.com. (
  2026080201 ; serial
  3600       ; refresh
  600        ; retry
  1209600    ; expire
  300        ; minimum / negative caching 관련 값
)

MNAME: 이 zone의 primary source로 지정된 name server
RNAME: 관리 담당자의 mailbox를 DNS 이름 형식으로 표현한 값
SERIAL: zone 데이터 버전
REFRESH·RETRY·EXPIRE: secondary server의 갱신 판단에 쓰이는 시간
MINIMUM: 현재 표준에서는 negative response의 TTL 계산에 사용되는 값

SERIAL을 잘못 관리하면 secondary server가 변경을 가져가지 못할 수 있다. DNS 제공자가 자동으로 관리한다면 임의로 날짜 형식을 가정하지 말고 실제 값과 제공자 동작을 따른다.

NXDOMAIN과 NODATA를 구분한다

NXDOMAIN: 질의한 이름 자체가 존재하지 않는다.
NODATA 응답: 이름은 존재하지만 요청한 타입의 데이터가 없다. 보통 응답 코드는 NOERROR이고 Answer가 비어 있다.

예를 들어 example.com에 MX는 있지만 AAAA가 없을 수 있다. 이때 AAAA 응답이 비었다고 도메인 전체가 존재하지 않는 것은 아니다. Authority 섹션의 SOA는 negative caching 판단에 쓰일 수 있다.

dig 결과를 읽는 순서

dig example.com A

status가 NOERROR, NXDOMAIN, SERVFAIL 중 무엇인지 본다.
flags의 aa, rd, ra, ad, tc를 확인한다.
Question의 이름과 타입이 의도와 맞는지 본다.
Answer에서 owner, TTL, type, RDATA를 읽는다.
Answer가 비면 Authority의 SOA 또는 위임 NS를 확인한다.
응답한 SERVER와 Query time을 기록해 다른 리졸버 결과와 비교한다.

간단한 값만 보고 싶을 때 +short를 쓸 수 있지만, 장애 분석에서는 상태 코드와 Authority가 사라지므로 전체 출력을 먼저 보는 편이 낫다.

dig +short example.com A
dig +short example.com MX

참고 자료

저작자표시 (새창열림)

'배움과 성장 > 네트워크·보안' 카테고리의 다른 글

DNS 루트 서버는 13대가 아니다: 13개 식별자와 Anycast 위치 (0)	2023.03.31
DNS CNAME 레코드란: alias와 canonical name, 설정 제약 (0)	2023.03.31
OSI 7계층 읽는 법: 캡슐화와 네트워크 장애 구간 찾기 (0)	2023.03.28
이메일 전송 과정: SMTP·IMAP·POP3와 MX 레코드 역할 (0)	2023.03.28
HTTP 쿠키와 캐시 차이: 상태 저장·Cache-Control·보안 속성 (0)	2023.03.28