DNS 레코드 유형
가장 많이 쓰이는 DNS 레코드 유형에 대한 참고 자료입니다. 이름, 용도, 값 예시를 보여줍니다.
18
AAddressRFC 1035주소

도메인을 IPv4 주소에 연결합니다.

example.com → 93.184.216.34
AAAAIPv6 AddressRFC 3596주소

도메인을 IPv6 주소에 연결합니다.

example.com → 2606:2800:220:1:248:1893:25c8:1946
CAACertification Authority AuthorizationRFC 8659보안

도메인의 TLS 인증서를 발급할 수 있는 인증 기관입니다.

0 issue "letsencrypt.org"
CNAMECanonical NameRFC 1035별칭

IP 대신 다른 도메인 이름을 가리키는 별칭입니다.

www.example.com → example.com
DNSKEYDNS KeyRFC 4034보안

DNSSEC가 영역 레코드에 서명하는 데 사용하는 공개 키입니다.

256 3 8 AwEAAb…
DSDelegation SignerRFC 4034보안

영역을 상위 영역의 DNSSEC 키에 연결합니다(서명된 위임).

2371 13 2 8ACBB0CD…
HINFOHost InformationRFC 1035텍스트

호스트 정보: CPU와 운영 체제. 요즘은 거의 사용되지 않습니다.

"Intel" "Linux"
HTTPSHTTPS Service BindingRFC 9460서비스

HTTPS 접속을 빠르게 하기 위한 연결 매개변수(ALPN, 포트, IP).

1 . alpn="h2,h3"
MXMail ExchangeRFC 1035메일

도메인의 메일 서버로, 우선순위가 있습니다(숫자가 작을수록 우선).

10 mail.example.com
NAPTRNaming Authority PointerRFC 3403서비스

서비스 검색을 위한 재작성 규칙입니다(ENUM과 SIP에서 사용).

100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
NSName ServerRFC 1035영역

도메인의 영역을 관리하는 권한 있는 네임 서버입니다.

ns1.example.com
PTRPointerRFC 1035역방향

역방향 DNS: IP 주소를 도메인 이름에 연결합니다.

34.216.184.93.in-addr.arpa → example.com
SOAStart of AuthorityRFC 1035영역

영역의 권한 정보: 기본 서버, 연락처, 갱신 주기.

ns1.example.com admin.example.com 2024010101
SRVServiceRFC 2782서비스

SIP나 XMPP 같은 서비스의 위치(호스트와 포트)입니다.

_sip._tcp 10 5 5060 sip.example.com
SSHFPSSH FingerprintRFC 4255보안

연결을 확인하기 위한 호스트의 SSH 공개 키 지문입니다.

1 1 123456789abcdef…
SVCBService BindingRFC 9460서비스

일반 서비스 바인딩 레코드로, HTTPS 레코드의 기반입니다.

1 svc.example.com alpn="h2"
TLSATLS AssociationRFC 6698보안

DANE를 통해 TLS 인증서를 도메인에 연결합니다.

3 1 1 0b87ad…
TXTTextRFC 1035텍스트

자유 형식 텍스트로, SPF, DKIM, DMARC 및 소유권 확인에 사용됩니다.

v=spf1 include:_spf.google.com ~all

작동 방식

DNS 레코드는 도메인 존에 들어 있는 항목으로, 하나의 구체적인 질문에 답합니다. 어떤 IP 주소를 가리키는지, 어떤 서버가 메일을 받는지, 누가 존을 관리하는지, 어떤 기관이 인증서를 발급할 수 있는지 같은 것입니다. 레코드 유형마다 답하는 질문이 다르며, 잘 구성된 존은 여러 개를 함께 씁니다.

이 참고 자료는 일상적으로 마주치는 레코드 유형을 모았습니다. 기본인 A, AAAA, CNAME, MX, TXT부터 CAA, DNSKEY, DS, TLSA, SSHFP 같은 보안 레코드까지, 정식 명칭과 각각의 용도, 존에 어떻게 적히는지 예시를 함께 담았습니다.

이것은 조회용 표입니다. 질의를 보내지도, 도메인을 분석하지도 않습니다. 도메인의 실제 레코드를 봐야 한다면 DNS 조회 도구가 실시간으로 확인해 줍니다.

예시

Aejemplo.com. 3600 IN A 192.0.2.10이름을 IPv4 주소로 향하게 합니다. 3600은 초 단위 TTL로, 리졸버가 응답을 캐시할 수 있는 시간입니다.
MXejemplo.com. 3600 IN MX 10 mail.ejemplo.com.숫자는 우선순위입니다. 값이 낮은 쪽을 먼저 시도합니다. 보통 예비용으로 여러 MX를 선언합니다.
TXTejemplo.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"TXT 레코드는 자유로운 텍스트를 담습니다. 주로 SPF, DKIM, DMARC와 도메인 소유 확인에 쓰입니다.

활용 사례

  • 운영 중인 도메인의 존을 건드리기 전에 어떤 레코드 유형이 맞는지 확인하기.
  • DNS 조회 결과나 메일 진단 결과를 이해하기.
  • MX와 SPF·DKIM·DMARC의 TXT를 조합해 도메인 메일 설정하기.
  • 존의 보안 레코드 점검하기: 인증서 발급 주체를 제한하는 CAA, DNSSEC를 위한 DS와 DNSKEY.

자주 묻는 질문

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

A 레코드는 IPv4 주소를 직접 가리킵니다. CNAME은 다른 이름을 가리키고, 그 이름이 다시 확인됩니다. 목적지 IP가 자주 바뀔 때 CNAME이 편리하지만 확인 단계가 하나 늘고 제약이 있습니다. 같은 이름의 다른 레코드와 공존할 수 없고, 도메인 루트에는 쓸 수 없습니다.

왜 도메인 루트에 CNAME을 둘 수 없나요?

존 루트에는 반드시 SOA와 NS 레코드가 있는데, 표준은 CNAME이 같은 이름의 다른 레코드와 공존하는 것을 허용하지 않기 때문입니다. 이를 우회하려고 많은 사업자가 ALIAS나 ANAME 같은 자체 대안을 제공합니다. CNAME처럼 동작하지만 주소를 바로 돌려줍니다.

TTL이란 무엇이고 얼마로 두는 것이 좋나요?

TTL(time to live)은 리졸버가 응답을 캐시할 수 있는 초 수입니다. TTL이 크면 질의가 줄고 확인이 빨라지며, 작으면 변경이 더 빨리 퍼집니다. 보통은 이전 몇 시간 전에 낮췄다가 변경이 안정된 뒤 다시 올립니다.

DNS를 바꿨는데 왜 아직 반영되지 않나요?

이전 값이 아직 캐시에 남아 있기 때문입니다. 앞선 응답이 전달될 때의 TTL이 끝날 때까지 중간 리졸버와 운영체제가 옛 데이터를 계속 돌려줄 수 있습니다. 브라우저 자체 캐시도 영향을 주어 때로는 TTL을 넘겨서까지 결과를 보관합니다.

CAA 레코드는 어디에 쓰나요?

그 도메인에 인증서를 발급할 수 있는 인증 기관을 명시합니다. 인증 기관은 발급 전에 이를 확인할 의무가 있으므로, 제3자가 다른 기관에서 당신의 도메인에 유효한 인증서를 받는 일을 막는 간단한 방법입니다.

관련 항목