본문으로 건너뛰기
AZ Tools

DNS 레코드 참조

DNS 레코드 타입 검색 가능한 치트시트 — A·AAAA·CNAME·MX·TXT·NS·SOA·PTR·SRV·CAA·DNSSEC·SVCB / HTTPS — 예시 포함.

A

호스트 이름을 IPv4 주소에 연결합니다. 가장 흔한 레코드로, 서버로 연결되는 도메인이라면 최소 하나는 있습니다.

Zone-file 예시

example.com.   IN  A      93.184.216.34
AAAA

호스트 이름을 IPv6 주소에 연결합니다. "쿼드 A"라고 읽습니다.

Zone-file 예시

example.com.   IN  AAAA   2606:2800:220:1:248:1893:25c8:1946
CNAME

한 호스트 이름을 다른 호스트 이름의 별칭으로 만듭니다. 대상은 그 자체로 조회가 되어야 하고, CNAME은 같은 이름의 다른 레코드와 공존할 수 없으며 존의 최상단(루트)에는 둘 수 없습니다.

Zone-file 예시

www.example.com.   IN  CNAME  example.com.
MX

메일 교환기 — 도메인으로 오는 SMTP를 어디로 배달할지 정합니다. 우선순위가 붙으며 값이 낮을수록 먼저 쓰입니다.

Zone-file 예시

example.com.   IN  MX  10 mail.example.com.
TXT

임의의 텍스트입니다. SPF(메일 위조 방지), DKIM 키, 도메인 소유 확인(Google, Facebook 등), 사람이 읽는 메모에 씁니다.

Zone-file 예시

example.com.   IN  TXT  "v=spf1 include:_spf.google.com ~all"
NS

(하위) 도메인을 권한 있는 네임 서버 묶음에 위임합니다. 모든 존은 최상단에 NS 레코드를 가집니다.

Zone-file 예시

example.com.   IN  NS  ns1.example.com.
SOA

Start of Authority — 존의 관리 정보입니다: 주 네임 서버, 관리자 이메일, 일련번호, 그리고 부정 응답 캐싱용 TTL.

Zone-file 예시

example.com.   IN  SOA  ns1.example.com. hostmaster.example.com. 2025010101 7200 3600 1209600 3600
PTR

역방향 조회 — IP를 다시 호스트 이름으로 연결합니다. in-addr.arpa(v4) 또는 ip6.arpa(v6) 존 아래에 둡니다.

Zone-file 예시

34.216.184.93.in-addr.arpa.   IN  PTR  example.com.
SRV

이름 붙은 서비스의 호스트와 포트를 우선순위·가중치와 함께 알려 줍니다. XMPP, SIP, Microsoft AD가 모두 SRV를 씁니다.

Zone-file 예시

_sip._tcp.example.com.   IN  SRV  10 60 5060 sipserver.example.com.
CAA

Certification Authority Authorization — 이 도메인의 TLS 인증서를 발급할 수 있는 CA를 제한합니다. 요즘 CA는 발급 전에 CAA를 반드시 확인해야 합니다.

Zone-file 예시

example.com.   IN  CAA  0 issue "letsencrypt.org"
DNSKEY

존의 서명을 검증하는 데 쓰는 DNSSEC 공개 키입니다. RRSIG 레코드와 짝을 이룹니다.

Zone-file 예시

example.com.   IN  DNSKEY  257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d…
DS

Delegation Signer — 상위 존에 게시해 하위 존 DNSKEY의 지문을 남깁니다. DNSSEC 신뢰 사슬을 이룹니다.

Zone-file 예시

example.com.   IN  DS  31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE…
RRSIG

Resource Record Signature — 레코드 집합에 대한 암호 서명으로, 존의 DNSKEY로 검증합니다. 존에 서명하면 자동으로 추가됩니다.

Zone-file 예시

example.com.   IN  RRSIG  A 13 2 300 20260101000000 …
NSEC / NSEC3

DNSSEC의 "인증된 부재 증명" — 레코드가 존재하지 않음을 증명합니다. NSEC3는 이름을 해시해 존 워킹을 어렵게 만듭니다.

Zone-file 예시

example.com.   IN  NSEC  www.example.com. A NS SOA MX TXT RRSIG NSEC
TLSA

DANE — DNSSEC를 통해 TLS 인증서(또는 그 공개 키)를 호스트 이름에 묶습니다. 클라이언트가 CA를 믿지 않고도 인증서를 검증할 수 있게 합니다.

Zone-file 예시

_443._tcp.example.com.   IN  TLSA  3 1 1 ABCD…
SVCB / HTTPS

Service Binding — 서비스의 대체 엔드포인트, ALPN, 포트, ECH 설정을 알립니다. HTTPS는 HTTP/3과 ECH를 가능하게 하는 HTTPS 전용 하위 타입입니다.

Zone-file 예시

example.com.   IN  HTTPS  1 . alpn="h3,h2"
NAPTR

이름을 URI나 정규식 결과로 다시 씁니다. ENUM과 SIP가 서비스 탐색에 씁니다.

Zone-file 예시

example.com.   IN  NAPTR  100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
LOC

지리적 위치 — 위도, 경도, 고도. 실제로는 거의 쓰이지 않습니다.

Zone-file 예시

example.com.   IN  LOC  37 30 N 127 0 E 30m
ALIAS / ANAME

일부 사업자가 지원하는 비표준 "평탄화된 CNAME"입니다(Route 53 alias, Cloudflare CNAME flattening). 존 최상단을 다른 호스트 이름으로 가리킬 수 있게 합니다.

Zone-file 예시

example.com.   IN  ALIAS  app.example.cdn.com.

사용법

  1. 검색창에 레코드 타입(mx) 또는 키워드(mail·dnssec) 입력.
  2. 설명과 zone-file 예시 확인.
  3. 타입 칩의 복사 버튼으로 zone file에 레코드 이름 드롭.

자세한 설명

펼치기

실제로 마주치는 DNS 레코드 종류를 검색할 수 있는 요약표입니다. 각 항목마다 용도, 따라붙는 함정, 그리고 가져다 고쳐 쓸 수 있는 구체적인 존 파일 예시가 들어 있습니다. 일상적으로 쓰는 것들부터 DNSSEC, 그리고 HTTP/3과 암호화된 클라이언트 헬로 뒤에 있는 최신 SVCB·HTTPS 레코드까지 다룹니다. 이 표를 열어 둘 이유는 바로 그 함정들입니다. CNAME은 존 최상단에 올 수 없는데, 그 자리에 반드시 있어야 하는 SOA·NS 레코드와 공존할 수 없기 때문입니다. MX 우선순위는 높은 값이 아니라 낮은 값이 이깁니다. 그리고 TXT 문자열 하나는 255자로 제한되어 있어서, 긴 DKIM 키는 따옴표로 묶인 여러 조각으로 도착하고 리졸버가 그것을 다시 이어 붙입니다.

자주 묻는 질문

CNAME이 apex에 못 사는 이유?

모든 zone이 apex에 SOA와 NS를 서빙해야 하는데 CNAME은 같은 이름에 다른 레코드와 공존 불가. ALIAS / ANAME(제공자별 flattening)이나 HTTPS 레코드로 우회.

SVCB와 HTTPS 차이?

둘 다 Service Binding 레코드. HTTPS는 브라우저가 자동 조회하는 HTTPS 전용 서브타입 — HTTP/3(alpn=h3)·대체 포트·Encrypted Client Hello(ECH) 설정 광고. SVCB는 다른 프로토콜용 일반형.

CAA 필요?

기술적으로는 선택이지만 강력 권장 — 없으면 어떤 공용 CA든 도메인 인증서 발급 가능. 0 issue "letsencrypt.org"(또는 사용 중인 CA) 추가로 해당 기관으로 발급 제한.

레코드를 바꿨는데 아무 일도 안 일어난다. 얼마나 기다려야 하나?

최소한 이전 레코드의 TTL만큼이다. 리졸버는 만료될 때까지 옛 응답을 계속 내줄 수 있고, 긴 TTL이 이미 배포된 뒤에 바꿨다면 모든 캐시에서 사라지기까지 그 시간이 통째로 걸린다. 보통은 예정된 변경 하루 전에 TTL을 낮추고, 변경한 뒤, 새 값이 자리 잡으면 다시 올린다.

TXT 레코드가 거부되거나 잘리는 이유는?

TXT 레코드의 문자열 하나는 255바이트를 넘을 수 없기 때문이다. 그보다 긴 값은 — DKIM 키가 대표적이다 — 한 레코드 안에서 따옴표로 묶인 여러 문자열로 쪼개야 하고, 리졸버가 그것을 도로 이어 붙인다. 대신 여러 개의 별도 레코드로 나누는 것은 전혀 다른 이야기이며, 대개 설정하려던 검증을 망가뜨린다.

관련 도구

DNSSEC 계산기 — DS 레코드와 NSEC3 해시

DNSKEY를 등록기관이 요구하는 DS 레코드로 바꿉니다. 키 태그와 세 가지 다이제스트 종류 전부, 또는 NSEC3 방식으로 이름을 해시합니다.

네트워크

DNS 존 파일 검사기

BIND 존 파일을 붙여넣으면 실제 의미를 보여줍니다. 모든 이름을 완전한 형태로 펼치고 SOA를 해설하며 파서만으로는 드러나지 않는 함정을 짚어 줍니다.

네트워크

CAA 레코드 빌더 (DNS 인증 기관 권한 제한)

CAA (Certificate Authority Authorization) DNS 레코드 생성 — 신뢰하는 CA만 도메인의 TLS 인증서를 발급할 수 있도록 제한.

네트워크

DNS 메시지 디코더

DNS 패킷을 16진수나 DoH base64url로 붙여넣고 읽어 보세요. 헤더 플래그, opcode와 rcode, 모든 레코드, EDNS0 OPT 옵션까지 보여 줍니다.

네트워크

TLSA 레코드 생성기 (DANE)와 검사기

인증서를 TLSA 레코드로 바꿉니다. 셀렉터와 매칭 종류 전부를 보여 주고, 이미 게시한 레코드가 지금 서비스하는 인증서와 맞는지 확인합니다.

네트워크

TXT 레코드 분할기 (255바이트 청크)

긴 SPF·DKIM·DMARC TXT 레코드를 DNS 프로토콜이 요구하는 255바이트 청크로 분할 — BIND·일반 zone 파일·Cloudflare·Route 53 문법 출력.

네트워크