DNS 레코드 유형 목록

List of DNS record types
모든 활성 DNS 레코드 유형에 대한 그래픽 개요

이 DNS 레코드 유형의 목록은 DNS(Domain Name System)의 영역 파일에 허용되는 리소스 레코드(RR)의 개요다.사이비 RR도 포함하고 있다.

리소스 레코드

유형 id를 입력하십시오.(iii) RFC 정의 설명 함수
A 		1 RFC 1035[1] 주소 기록 호스트 이름을 호스트의 IP 주소에 매핑하는 데 가장 일반적으로 사용되는 32비트 IPv4 주소를 반환하지만 DNSBL, RFC 1101에 서브넷 마스크를 저장하는 등에도 사용된다.
아아아.		 28 RFC 3596[2] IPv6 주소 레코드 호스트 이름을 호스트의 IP 주소에 매핑하는 데 가장 일반적으로 사용되는 128비트 IPv6 주소 반환
AFSDB		 18 RFC 1183 AFS 데이터베이스 레코드 AFS 셀의 데이터베이스 서버 위치.이 레코드는 AFS 클라이언트가 지역 도메인 외부의 AFS 셀에 접촉하기 위해 일반적으로 사용된다.이 레코드의 하위 유형은 구식 DCE/DFS 파일 시스템에서 사용된다.
APL		 42 RFC 3123 주소 접두사 목록 다양한 주소 패밀리의 주소 범위 목록(예: CIDR 형식)을 지정하십시오.실험적인.
CAA 		257 RFC 6844 인증 기관 인증 DNS 인증 기관 인증, 호스트/도메인에 대해 허용되는 CA 제한
CDNSKEY		 60 RFC 7344 상위 전송을 위한 DNSKEY 레코드의 하위 복사본
CDS		 59 RFC 7344 차일드 DS DS 레코드의 하위 복사본(상위 전송용)
CER		 37 RFC 4398 인증서 기록 PKIX, SPKI, PGP 등을 저장한다.
CNAME 5 RFC 1035[1] 표준이름기록 다른 이름에 대한 별칭: 새 이름으로 조회를 다시 시도하여 DNS 조회를 계속함
CSYNC		 62 RFC 7477 자식 간 동기화 하위 영역과 상위 DNS 영역 간의 동기화 메커니즘을 지정하십시오.일반적인 예로는 상위 영역과 하위 영역에 동일한 NS 레코드를 선언하는 것이다.
DHCID		 49 RFC 4701 DHCP 식별자 DHCP에 대한 FQDN 옵션과 함께 사용
DLV		 32769 RFC 4431 DNSSEC Lookaside 검증 레코드 DNS 위임 체인 외부에 DNSSEC 신뢰 앵커를 게시하는 경우DS 레코드와 동일한 형식을 사용한다.RFC 5074는 이러한 레코드를 사용하는 방법을 설명한다.
DNAME 		39 RFC 6672 위임 이름 레코드 정확한 이름만을 위한 별칭인 CNAME과 달리 이름 및 모든 하위 이름에 대한 별칭.CNAME 레코드처럼, DNS 조회는 새 이름으로 조회를 재시도하여 계속된다.
DNSKEY		 48 RFC 4034 DNS 키 레코드 DNSSEC에 사용된 키 레코드.KEY 레코드와 동일한 형식을 사용한다.
DS		 43 RFC 4034 위임 서명자 위임된 영역의 DNSSEC 서명 키를 식별하는 데 사용되는 레코드
EUI48 108 RFC 7043 MAC 주소(UI-48) 48비트 IEEE 확장 고유 식별자.
EUI64 109 RFC 7043 MAC 주소(UI-64) 64비트 IEEE 확장 고유 식별자.
힌포		 13 RFC 8482 호스트 정보 QTYPE=Any가 있는 DNS 쿼리에 대한 최소 크기 응답 제공
엉덩이 		55 RFC 8005 호스트 ID 프로토콜 IP 주소의 엔드포인트 식별자와 로케이터 역할을 구분하는 방법.
HTTPS		 65 IETF 드래프트 HTTPS 바인딩 도메인에 액세스하기 위해 많은 리소스를 해결해야 하는 클라이언트의 성능을 향상시키는 RR.DNSOP 작업 그룹 및 Akamai 기술에 의한 이 IETF 초안에 대한 자세한 정보.
IPSECKEY		 45 RFC 4025 IPsec 키 IPsec과 함께 사용할 수 있는 키 레코드
키		 25 RFC 2535[3] 및 RFC 2930[4] 키 레코드 SIG(0) (RFC 2931) 및 TKEY (RFC 2930)에만 사용.[5]RFC 3445는 응용 프로그램 키 사용을 없애고 DNSSEC로 제한했다.[6]RFC 3755는 DNSKEY를 DNSSEC 내의 대체품으로 지정한다.[7]RFC 4025는 IPsec과 함께 사용할 대체품으로 IPSECKEY를 지정한다.[8]
KX		 36 RFC 2230 키 교환기 기록 연결된 도메인 이름의 키 관리 에이전트를 식별하기 위해 일부 암호화 시스템(DNSEC 제외)과 함께 사용된다.이는 DNS 보안과 관련이 없다는 점에 유의하십시오.IETF 표준 트랙에 있는 것이 아니라 Information status이다.그것은 항상 제한적인 배치를 해왔지만, 여전히 사용되고 있다.
LOC 29 RFC 1876 위치기록 도메인 이름과 연결된 지리적 위치를 지정함
MX 15 RFC 1035[1] 및 RFC 7505 메일교환기록 도메인 이름을 해당 도메인의 메시지 전송 에이전트 목록에 매핑
냅트르 35 RFC 3403 이름 지정 권한 포인터 URI로 사용될 수 있는 도메인 이름, 조회할 추가 도메인 이름 등에 대한 정규 표현 기반 재작성 허용
NS		 2 RFC 1035[1] 이름 서버 레코드 지정된 권한 있는 이름 서버를 사용하도록 DNS 영역 위임
NSEC		 47 RFC 4034 다음 보안 레코드 DNSSEC의 일부—이름이 존재하지 않음을 증명하는 데 사용.NXT 레코드와 동일한 형식을 사용한다.
NSEC3		 50 RFC 5155 다음 Secure 레코드 버전 3 존워크를 허용하지 않고 이름에 대해 비존재 증명을 허용하는 DNSSEC 확장
NSEC3PARAM		 51 RFC 5155 NSEC3 매개변수 NSEC3와 함께 사용하기 위한 파라미터 레코드
오픈PGPKEY 61 RFC 7929 OpenPGP 공용 키 레코드 OPENPGPKE DNS 리소스 레코드를 사용하여 특정 전자 메일 주소에 대한 OpenPGP 공용 키를 DNS에 게시하고 찾기 위한 DNS 기반 DANE(Damned Entities) 방법.
PTR		 12 RFC 1035[1] PTR 리소스 레코드[de] 표준 이름에 대한 포인터.CNAME과 달리 DNS 처리가 중지되고 이름만 반환된다.가장 일반적인 용도는 역 DNS 조회를 구현하는 것이지만, 다른 용도는 DNS-SD와 같은 것을 포함한다.
RRSIG		 46 RFC 4034 DNSSEC 서명 DNSSEC 보안 레코드 집합에 대한 서명.SIG 레코드와 동일한 형식을 사용한다.
RP		 17 RFC 1183 책임있는 사람 도메인의 책임자에 대한 정보.일반적으로 @이(가) 로 대체된 이메일 주소.
SIG		 24 RFC 2535 서명 SIG(0) (RFC 2931) 및 TKEY (RFC 2930)에서 사용되는 서명 기록.[7]RFC 3755는 DNSSEC 내에서 사용하기 위해 RRSIG를 SIG의 대체품으로 지정했다.[7]
스미마 53 RFC 8162[9] S/MIME 인증서 연결[10] 보낸 사람 인증을 위해 S/MIME 인증서를 도메인 이름과 연결하십시오.
비상대기상태 6 RFC 1035[1] 및 RFC 2308[11] [지역] 권한 기록 시작 기본 이름 서버, 도메인 관리자의 전자 메일, 도메인 일련 번호 및 영역 새로 고침과 관련된 여러 타이머를 포함하여 DNS 영역에 대한 권한 있는 정보를 지정하십시오.
SRV 33 RFC 2782 서비스 로케이터 일반화된 서비스 위치 레코드, MX와 같은 프로토콜별 레코드를 생성하는 대신 새로운 프로토콜에 사용된다.
SSHFP 		44 RFC 4255 SSH 공용 키 지문 호스트의 신뢰성을 확인하는 데 도움이 되도록 DNS 시스템에 SSH 공용 호스트 키 지문을 게시하기 위한 리소스 레코드.RFC 6594는 ECC SSH 키와 SHA-256 해시를 정의한다.자세한 내용은 IANA SSHFP RR 매개 변수 레지스트리를 참조하십시오.
SVCB		 64 IETF 드래프트 서비스 바인딩 도메인에 액세스하기 위해 많은 리소스를 해결해야 하는 클라이언트의 성능을 향상시키는 RR.DNSOP 작업 그룹 및 Akamai 기술에 의한 이 IETF 초안에 대한 자세한 정보.
TA		 32768 해당 없음 DNSSEC 신뢰 당국 서명된 DNS 루트가 없는 DNSSEC에 대한 배포 제안의 일부.자세한 내용은 IANA 데이터베이스 및 Weiler Spec을 참조하십시오.DS 레코드와 동일한 형식을 사용한다.
TKEY 		249 RFC 2930 트랜잭션 키 레코드 첨부된 KEY RR의 공개 키 아래에 암호화된 TSIG와 함께 사용될 키잉 재료를 제공하는 방법.[12]
TLSA 		52 RFC 6698 TLSA 인증서 연결 DANE. RFC 6698에 대한 레코드는 "TLSA DNS 리소스 레코드는 TLS 서버 인증서 또는 공개 키를 해당 레코드가 발견된 도메인 이름과 연결하여 'TLSA 인증서 연결'을 형성하는 데 사용된다"고 정의한다.
TSIG 		250 RFC 2845 트랜잭션 서명 동적 업데이트를 승인된 클라이언트에서 온 것으로 인증하거나 응답을 DNSSEC와 유사한 승인된 재귀 이름 서버에서[13] 온 것으로 인증하는 데 사용할 수 있다.
TXT 		16 RFC 1035[1] 텍스트 레코드 원래 DNS 레코드의 임의의 사람이 읽을 수 있는 텍스트용.그러나 1990년대 초반부터 이 기록은 RFC 1464, 기회주의적 암호화, 발신자 정책 프레임워크, DKIM, DMARC, DNS-SD 등에 의해 지정된 것과 같이 기계 판독이 가능한 데이터를 더 자주 운반한다.
URI 		256 RFC 7553 균일 리소스 식별자 호스트 이름에서 URI로의 매핑을 게시하는 데 사용할 수 있다.
조넴드 		63 RFC 8976 DNS 영역에 대한 메시지 요약 유휴 DNS 영역 데이터에 대한 암호화 메시지 다이제스트 제공

기타 유형 및 유사 RR

다른 유형의 레코드는 단순히 일부 유형의 정보를 제공하거나(예: HINFO 레코드는 호스트가 사용하는 컴퓨터/OS 유형에 대한 설명을 제공함), 다른 유형의 레코드는 실험 기능에 사용된 데이터를 반환한다.「유형」 필드는, 각종 조작을 위한 프로토콜에서도 이용되고 있다.

유형 id를 입력하십시오. RFC 정의 설명 함수
* 255 RFC 1035[1] 캐시된 모든 레코드 이름 서버에 알려진 모든 유형의 모든 레코드 반환이름 서버에 이름에 대한 정보가 없는 경우, 요청이 전달될 것이다.반환된 기록이 완전하지 않을 수도 있다.예를 들어 이름에 A와 MX가 모두 있지만 이름 서버가 A 레코드만 캐시된 경우 A 레코드만 반환된다.일반적으로 ANY(예: dig, Windows nslookup, Wireshark)라고 한다.2019년 RFC8482 표준 트랙 출판으로 클라우드플레어를 포함한 많은 DNS 제공자가 레코드를 열거하는 대신 "Any" 쿼리에 최소한의 응답만 제공하게 되었다.[15]
AXFR 252 RFC 1035[1] 권한 있는 구역 전송 기본 이름 서버에서 보조 이름 서버로 전체 영역 파일 전송
IXFR		 251 RFC 1996 증분 영역 전송 지정된 영역의 영역 전송을 요청하지만 이전 일련 번호와의 차이만 요청.권한 있는 서버가 구성 또는 필요한 델타 부족으로 요청을 이행할 수 없는 경우 이 요청을 무시하고 응답으로 전체(AXFR)를 보낼 수 있다.
OPT		 41 RFC 6891 옵션 이것은 EDNS를 지원하는 데 필요한 사이비 레코드 유형이다.

[1] 구식 레코드 유형

진보는 원래 정의된 기록 유형 중 일부를 쓸모 없게 만들었다.IANA에 등재된 기록 중 일부는 다양한 이유로 사용이 제한되어 있다.어떤 것은 목록에서 쓸모없다고 표시되고, 어떤 것은 매우 불명확한 서비스를 위한 것이고, 어떤 것은 오래된 버전의 서비스를 위한 것이고, 어떤 것은 그들이 "맞지 않다"고 말하는 특별한 메모를 가지고 있다.

유형 id를 입력하십시오.
(iii)		 RFC 정의 폐기 대상 설명
MD 3 RFC 883 RFC 973 메일 수신처(MD) 및 메일 전달자(MF) 레코드. MAILA는 실제 레코드 유형이 아니라 MF 및/또는 MD 레코드를 반환하는 쿼리 유형이다.RFC 973은 이 기록들을 MX 기록으로 대체했다.
MF 4
메일라 254
MB 7 RFC 883 공식적으로 폐기된 것은 아니다.채택될 가능성이 낮다(RFC 2505). MB, MG, MR, MINFO는 가입자 메일링 리스트를 게시하기 위한 기록이다.MAILB는 해당 레코드 중 하나를 반환하는 쿼리 코드다.목적은 MB와 MG가 SMTP VRFY와 EXPN 명령을 대체하는 것이었다.MR은 "551 User Not Local" SMTP 오류를 대체하기로 되어 있었다.이후 RFC 2505는 VRFY와 EXPN을 모두 비활성화할 것을 권고해 MB와 MG가 불필요해졌다.그것들은 RFC 1035에 의해 실험으로 분류되었다.
MG 8
미스터 9
민포 14
메일B 253
WKS 11 RFC 883, RFC 1035 RFC 1123(RFC 1127에 더 있음)에 의해 "기존하지 않을 것"으로 선언. 호스트가 지원하는 잘 알려진 서비스를 설명하려면 기록하십시오.실제 사용 안 함.현재의 권고와 실천은 서비스를 IP주소에 접속해 지원 여부를 결정하는 것이다.SMTP는 심지어 MX 프로세싱에서 WKS 레코드를 사용하는 것을 금지하고 있다.[16]
NB 32 RFC 1002 실수(RFC 1002부터), NIMLOC와 SRV에 번호가 할당된다.
NBSTAT 33
NULL 10 RFC 883 RFC 1035 RFC 1035에 의해 폐기됨.RFC 883은 이 기록을 사용하는 "완료 쿼리"(opcode 2 및 아마도 3)를 정의했다.RFC 1035는 나중에 opcode 2를 "상태"로 재지정하고 opcode 3을 예약했다.
A6 38 RFC 2874 RFC 6563 초기 IPv6의 일부로 정의되었지만 RFC 3363에 의해 실험으로 다운그레이드되었으며, 이후 RFC 6563에 의해 과거로 다운그레이드되었다.
NXT 30 RFC 2065 RFC 3755 DNSSEC(RFC 2065)의 첫 번째 버전의 일부.NXT는 DNSSEC 업데이트(RFC 3755)에 의해 폐기되었다.동시에, KEY와 SIG에 대한 적용성의 영역도 DNSSEC 사용을 포함하지 않는 것으로 제한되었다.
키 25
SIG 24
힌포 13 RFC 883 RFC 8482에 의해 노출되지 않음.현재 Cloudflare에서 ANE 유형의 쿼리에 응답하여 사용 중.[17] 호스트 CPU 유형 및 운영 체제에 대한 정보를 제공하기 위한 레코드.프로토콜이 유사한 피어와 통신할 때 처리를 최적화할 수 있도록 하기 위한 것이었다.
RP 17 RFC 1183 RP는 SOA 기록에 사용된 것과 별도로 특정 호스트, 서브넷 또는 다른 도메인 수준 레이블에 대한 다른 접점과 관련하여 사람이 읽을 수 있는 특정 정보에 사용될 수 있다.
X25년 19 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
ISDN 20 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
RT 21 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
NSAP 22 RFC 1706 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
NSAP-PTR 23 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
PX 26 RFC 2163 주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
EID 31 해당 없음 Nimrod DNS 인터넷 드래프트에 의해 정의되었지만 RFC 상태에 도달하지 못했다.주목할 만한 응용 프로그램이 현재 사용하고 있지 않음
님록 32 해당 없음
ATMA 34 해당 없음 ATM 포럼 위원회에서 정의함.[18]
APL 42 RFC 3123 다양한 주소 패밀리의 주소 범위 목록(예: CIDR 형식)을 지정하십시오.실험적인.
싱크 40 해당 없음 키친 싱크 인터넷 드래프트에 의해 정의되지만 RFC 상태에 도달하지 못함
GPOS 27 RFC 1712 LOC 레코드의 더 제한된 초기 버전
UINFO 100 해당 없음 IANA는 예약되었으며, RFC는 [1]을 문서화하지 않았으며, 90년대 초에 BIND에서 지원이 제거되었다.
UID 101 해당 없음
GID 102 해당 없음
UNSPEC 103 해당 없음
SPF 99 RFC 4408 RFC 7208 동일한 형식을 사용하여 SPF 데이터를 TXT 레코드에 저장하는 대안으로 송신자 정책 프레임워크 프로토콜의 일부로 지정된다.광범위한 지원 부족으로 RFC 7208에서 지원이 중단되었다.[19][20]
닌포 56 해당 없음 영역에 대한 상태 정보를 제공하는 데 사용됨.2008년에 IETF 초안 "The Zone Status (ZS) DNS Resource Record"에 대한 요청이 있었다.채택 없이 만료됨.[21]
RKEY 57 해당 없음 NAPTR 레코드 암호화에 사용.2008년에 IETF 초안 "The RKEY DNS Resource Record"에 대한 요청이 있었다.채택 없이 만료됨.[22]
탈링크 58 해당 없음 DNSSEC Trust Anchor History Service 인터넷 초안에 의해 정의되지만 RFC 상태로 만들지 않음
NID 104 RFC 6742 주목할 만한 애플리케이션에서 사용하지 않으며 "실험적"으로 표시됨
L32 105
L64 106
LP 107
도아 259 해당 없음 DNS 인터넷 초안을 통해 DOA에 의해 정의되지만 RFC 상태에 도달하지 않음

참조

  1. ^ a b c d e f g h i j Paul Mockapetris (November 1987). "RFC 1035: Domain Names - Implementation and Specification". Network Working Group of the IETF (Internet Engineering Task Force). p. 12.
  2. ^ "RFC 3596: DNS Extensions to Support IP Version 6". The Internet Society. October 2003. Archived from the original on 14 April 2021.
  3. ^ RFC 2535, §3
  4. ^ RFC 3445, §1. "KEY RR는 RFC 2930에 정의되었다.."
  5. ^ RFC 2931, §2.4. "반면 SIG(0)는 공개키 인증을 사용하며, 공개키는 DNS에 KEY RR로 저장되고 개인키는 서명자에 저장된다."
  6. ^ RFC 3445, §1. "DNSSEC는 KEY RR에 허용되는 유일한 하위 타입이 될 것이다..."
  7. ^ a b c RFC 3755, §3. "DNSKEY는 RFC3445에 따라 이러한 키가 응용 프로그램용이 아님을 나타내는 니모닉과 함께 KEY의 대체품이 될 것이다. RRSIG(리소스 레코드 SIGnature)는 SIGH를 대체하고 NSEC(다음 SECure)는 NXT를 대체한다.SIG(0) RFC2931과 TKEY RFC2930이 SIG와 KEY를 계속 사용한다는 점을 제외하면 이러한 새로운 타입은 구 타입을 완전히 대체한다.
  8. ^ RFC 4025, 추상적이다."이 레코드는 RFC 3445에 의해 폐기된 KEY 리소스 레코드의 하위 타입 #4의 기능을 대체한다."
  9. ^ "RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME". Internet Engineering Task Force. May 2017. Retrieved 17 October 2018.
  10. ^ "Domain Name System (DNS) Parameters". Internet Assigned Numbers Authority. September 2018. Retrieved 17 October 2018.
  11. ^ SOA 레코드의 최소 필드는 RFC 2308에서 NXDOMIN 회신의 TTL로 재정의된다.
  12. ^ RFC 2930, §6. "키잉 소재는 첨부된 KEY RR RFC 2535의 공개 키 아래에 암호화된 TKEY RR의 키 데이터 필드 내에 전송된다."
  13. ^ RFC 2845, 추상적
  14. ^ J. Abley, Afilias, O. Gudmundsson, M. Majkowski, Cloudflare Inc., E. Hunt, ISC (January 2019). "RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY". Internet Engineering Task Force.{{cite web}}: CS1 maint : 복수이름 : 작성자 목록(링크)
  15. ^ "What happened next: the deprecation of ANY". Cloudflare. 16 March 2019. Retrieved 19 September 2021.
  16. ^ RFC 1123 섹션 2.2, 5.2.12, 6.1.3.6
  17. ^ "What happened next: the deprecation of ANY". Cloudflare. 13 April 2016. Retrieved 9 March 2019.
  18. ^ "ATM Name System, V2.0" (PDF). ATM Forum Technical Committee. July 2000. Archived from the original (PDF) on 2019-03-14. Retrieved 14 March 2019.
  19. ^ Kucherawy, M. (July 2012). "Background on the RRTYPE Issue". Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments. IETF. sec. A. doi:10.17487/RFC6686. RFC 6686. Retrieved August 31, 2013.
  20. ^ Kitterman, S. (April 2014). "The SPF DNS Record Type". Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF. sec. 3.1. doi:10.17487/RFC7208. RFC 7208. Retrieved 26 April 2014.
  21. ^ Reid, Jim (4 July 2008). "draft-reid-dnsext-zs-01 - The Zone Status (ZS) DNS Resource Record". IETF. Retrieved 9 March 2019.
  22. ^ Reid, Jim; Schlyter, Jakob; Timms, Ben (4 July 2008). "draft-reid-dnsext-rkey-00 - The RKEY DNS Resource Record". IETF. Retrieved 9 March 2019.

추가 읽기