DNS Record Reference

DNS 레코드 타입 레퍼런스 - A, CNAME, MX, TXT 등

20개 결과

DNS Record Reference 소개

DNS Record Reference는 주요 DNS 리소스 레코드 타입을 모두 다루는 검색 가능한 종합 가이드입니다. 다섯 가지 핵심 카테고리를 다룹니다. 기본 레코드(IPv4 매핑용 A, IPv6용 AAAA, 별칭용 CNAME, 네임서버용 NS, 존 권한용 SOA, 역방향 조회용 PTR), 메일 레코드(메일 라우팅용 MX, SPF 발신자 정책·DKIM 공개키 서명·DMARC 인증 정책용 TXT), 보안 레코드(인증기관 제한용 CAA, DANE TLS 인증서 바인딩용 TLSA, DNSSEC 공개키용 DNSKEY, 위임 서명자용 DS, 리소스 레코드 서명용 RRSIG), 서비스 레코드(프로토콜/포트 기반 서비스 탐색용 SRV, URI/정규식 기반 라우팅용 NAPTR), 기타 레코드(SSH 호스트 키 지문용 SSHFP, 지리 좌표용 LOC)가 포함됩니다. 모든 항목에는 실제 존 파일 구문 예제가 포함되어 있습니다.

네트워크 관리자, DevOps 엔지니어, 보안 엔지니어, 웹 호스팅 담당자가 DNS 존을 구성하거나, 메일 전달 오류를 디버깅하거나, DNSSEC을 구현하거나, DANE을 설정할 때 주로 참고합니다. 이메일 인증(SPF, DKIM, DMARC)을 통합하거나 CAA 레코드로 SSL/TLS 발급을 제한하는 개발자에게도 유용합니다. 존 정점에서 A 레코드와 CNAME 레코드 중 무엇을 써야 하는지, DMARC TXT 레코드를 어떻게 구성해야 하는지 같은 실무적인 질문에 실제 존 파일 예제로 답변합니다.

레코드는 기본, 메일, 보안, 서비스, 기타 다섯 가지 카테고리로 구분되어 필요한 레코드 타입을 빠르게 찾을 수 있습니다. 검색바는 레코드 타입명과 설명 모두에서 검색하므로 "메일"로 검색하면 메일 관련 레코드 전체를, "발신자"로 검색하면 SPF 상세 내용을 바로 찾을 수 있습니다. 모든 처리는 브라우저 내에서만 이루어집니다.

주요 기능

기본 레코드: A (IPv4), AAAA (IPv6), CNAME (별칭), NS (네임서버), SOA (존 권한), PTR (역방향 조회)
메일 인증: MX 라우팅 레코드와 TXT 기반 SPF, DKIM 공개키, DMARC 정책 레코드
DNSSEC 세트: DNSKEY (공개키), DS (위임 서명자), RRSIG (레코드 서명), CAA (CA 제한)
DANE 보안: TLS 인증서를 DNS에 직접 연결하는 TLSA 레코드
서비스 탐색: 우선순위·가중치·포트가 있는 SRV 레코드, URI 기반 라우팅용 NAPTR
기타: SSH 키 지문 검증용 SSHFP, 지리 좌표 인코딩용 LOC
기본·메일·보안·서비스·기타 5개 카테고리 필터로 원하는 레코드 타입 즉시 접근
bind, AWS Route 53, Cloudflare 등에 바로 적용 가능한 실제 존 파일 구문 예제 제공

자주 묻는 질문

A 레코드와 CNAME 레코드의 차이는 무엇인가요?

A 레코드는 호스트명을 IPv4 주소에 직접 매핑합니다(예: example.com → 93.184.216.34). CNAME 레코드는 IP 주소 대신 다른 호스트명을 가리키는 별칭을 만듭니다(예: www.example.com → example.com). 존 정점(naked domain)에는 NS·SOA와 충돌하므로 CNAME을 사용할 수 없습니다. 대신 A 레코드나 AAAA 레코드를 사용해야 합니다.

SPF, DKIM, DMARC는 어떻게 함께 동작하나요?

SPF(TXT 레코드)는 도메인을 대신해 메일을 보낼 수 있는 IP 주소 목록을 지정합니다. DKIM(셀렉터 서브도메인 아래 TXT 레코드)은 수신 서버가 각 이메일 헤더의 암호화 서명을 검증할 때 사용할 공개키를 제공합니다. DMARC(_dmarc.도메인 TXT 레코드)는 SPF 또는 DKIM 정렬에 실패한 메시지에 대한 정책(none/quarantine/reject)과 집계 보고서를 받을 이메일 주소를 지정하여 두 인증을 연결합니다.

DNSSEC이란 무엇이며 어떤 레코드 타입을 사용하나요?

DNSSEC은 DNS 응답에 암호화 인증을 추가합니다. DNSKEY는 존의 공개 서명 키를 저장하고, RRSIG는 각 리소스 레코드 세트의 디지털 서명을 보유합니다. DS(위임 서명자)는 부모 존에 저장되어 자식 존으로의 신뢰 체인을 구성하고, NSEC/NSEC3는 레코드의 비존재를 증명합니다. 이를 통해 리졸버는 DNS 데이터가 변조되지 않았음을 검증할 수 있습니다.

CAA 레코드란 무엇이고 왜 중요한가요?

CAA(Certification Authority Authorization) 레코드는 도메인에 SSL/TLS 인증서를 발급할 수 있는 인증기관을 지정합니다. 예를 들어 CAA 0 issue "letsencrypt.org"를 설정하면 Let's Encrypt 외의 다른 CA는 인증서를 발급할 수 없습니다. 이를 통해 침해되거나 불량한 CA로 인한 잘못된 인증서 발급 위험을 줄입니다.

SRV 레코드는 어떤 용도로 사용하나요?

SRV 레코드는 특정 서비스와 프로토콜을 제공하는 서버의 호스트명, 포트, 우선순위, 가중치를 알립니다. 예를 들어 _sip._tcp.example.com SRV 10 60 5060 sip.example.com은 SIP 클라이언트에게 SIP 서버 위치를 알려줍니다. VoIP(SIP), XMPP 채팅, Microsoft 서비스(Active Directory, Teams) 등 동적 서비스 탐색이 필요한 프로토콜에서 사용됩니다.

PTR 레코드란 무엇이고 언제 필요한가요?

PTR 레코드는 역방향 DNS 조회를 수행하여 IP 주소를 호스트명으로 매핑합니다. IPv4의 경우 in-addr.arpa., IPv6의 경우 ip6.arpa. 존에 위치하며 일반적으로 ISP나 호스팅 업체가 관리합니다. 메일 서버는 스팸 방지 목적으로 PTR 레코드를 확인하므로, 누락되거나 불일치하는 PTR 레코드는 정상 이메일이 거부되는 원인이 될 수 있습니다.

TLSA 레코드(DANE)란 무엇인가요?

TLSA 레코드는 DANE(DNS 기반 명명된 엔터티 인증) 표준의 일부로, DNSSEC으로 보호된 DNS에 특정 TLS 인증서나 공개키를 서비스에 직접 고정합니다. 예를 들어 _443._tcp.example.com TLSA 3 1 1 <해시>는 브라우저에게 HTTPS 연결 시 해당 해시와 일치하는 인증서만 수락하도록 지시하여 불량 CA의 잘못된 인증서 발급을 방지합니다.

DNS를 구성하면서 이 레퍼런스로 구문을 확인할 수 있나요?

네, 그것이 주요 사용 사례입니다. 각 항목은 레코드 타입의 정확한 존 파일 형식(이름, TTL, 클래스, 타입, rdata 순서와 데이터 형식)을 보여줍니다. 예제는 실제 값을 사용하여 bind 스타일 존 파일, AWS Route 53, Cloudflare 등에 바로 적용할 수 있습니다.