PROFILPELAJAR.COM

DNSレコードタイプの一覧を以下に示す。Domain Name System（DNS）のゾーンファイル（英語版）内のリソースレコード（RR）の概要である。また、擬似RR（pseudo-RRs）を含んでいる。

リソースレコード

タイプ	値 (10進)	RFC定義	説明	機能
A	1	RFC 1035^[1]	IPv4 IPアドレスレコード	32ビットのIPv4 IPアドレスを回答する。ホストのIPアドレスにホスト名をマッピングするために使用する。また、RFC 1101でサブネットマスクを保存するためにDNSBLで使う。他
AAAA	28	RFC 3596^[2]	IPv6 IPアドレスレコード	128ビットのIPv6 IPアドレスを回答する。ホストのIPアドレスにホスト名をマッピングするために使用する。
AFSDB	18	RFC 1183	AFS データベースレコード	Location of database servers of an AFS cell. This record is commonly used by AFS clients to contact AFS cells outside their local domain. A subtype of this record is used by the obsolete DCE/DFS file system.
APL	42	RFC 3123	アドレスのプレフィックスリスト	さまざまなアドレスファミリのアドレス範囲（例えばCIDR形式）のリストを指定する。実験的。
CAAレコード（英語版）	257	RFC 6844	認証局の認可	DNS Certification Authority Authorization, constraining acceptable CAs for a host/domain
CDNSKEY	60	RFC 7344	子DNSKEY	Child copy of DNSKEY record, for transfer to parent
CDS	59	RFC 7344	子 DS	Child copy of DS record, for transfer to parent
CERT	37	RFC 4398	証明書レコード	Stores PKIX, SPKI, PGP, etc.
CNAMEレコード（英語版）	5	RFC 1035^[1]	別名レコード（Canonical name record）	他の名称へのエイリアス（別名）で使用する。: the DNS lookup will continue by retrying the lookup with the new name.
DHCID	49	RFC 4701	DHCP識別子	Used in conjunction with the FQDN option to DHCP
DLV	32769	RFC 4431	DNSSEC Lookaside Validation レコード	For publishing DNSSEC trust anchors outside of the DNS delegation chain. Uses the same format as the DS record. RFC 5074 describes a way of using these records.
DNAME（英語版）	39	RFC 2672	Delegation 名	Alias for a name and all its subnames, unlike CNAME, which is an alias for only the exact name. Like a CNAME record, the DNS lookup will continue by retrying the lookup with the new name.
DNSKEY	48	RFC 4034	DNS キー record	The key record used in DNSSEC. Uses the same format as the KEY record.
DS	43	RFC 4034	Delegation signer	The record used to identify the DNSSEC signing key of a delegated zone
HIP（英語版）	55	RFC 5205	Host Identity プロトコル	Method of separating the end-point identifier and locator roles of IP addresses.
HTTPS	65	IETF ドラフト	HTTPS 割り当て	RR that improves performance for clients that need to resolve many resources to access a domain. More info in this IETF Draft by DNSOP Working group and Akamai technologies.
IPSECKEY	45	RFC 4025	IPsec キー	Key record that can be used with IPsec
KEY	25	RFC 2535^[3] and RFC 2930^[4]	キーレコード	Used only for SIG(0) (RFC 2931) and TKEY (RFC 2930).^[5] RFC 3445 eliminated their use for application keys and limited their use to DNSSEC.^[6] RFC 3755 designates DNSKEY as the replacement within DNSSEC.^[7] RFC 4025 designates IPSECKEY as the replacement for use with IPsec.^[8]
KX	36	RFC 2230	鍵交換レコード	Used with some cryptographic systems (not including DNSSEC) to identify a key management agent for the associated domain-name. Note that this has nothing to do with DNS Security. It is Informational status, rather than being on the IETF standards-track. It has always had limited deployment, but is still in use.
LOCレコード（英語版）	29	RFC 1876	位置レコード	Specifies a geographical location associated with a domain name
MX	15	RFC 1035^[1] and RFC 7505	電子メール交換レコード	ドメインのメール転送エージェント（MTA）のリストとドメイン名をマッピングする。
NAPTRレコード（英語版）	35	RFC 3403	Naming Authority Pointer	Allows regular-expression-based rewriting of domain names which can then be used as URIs, further domain names to lookups, etc.
NS	2	RFC 1035^[1]	ネームサーバーレコード	DNSゾーン（英語版）自身や下位ドメインの権威DNSサーバ（英語版）を指定するために使用する
NSEC	47	RFC 4034	Next-Secure record	Part of DNSSEC—used to prove a name does not exist. Uses the same format as the (obsolete) NXT record.
NSEC3	50	RFC 5155	NSEC record version 3	An extension to DNSSEC that allows proof of nonexistence for a name without permitting zonewalking
NSEC3PARAM	51	RFC 5155	NSEC3 parameters	Parameter record for use with NSEC3
PTR	12	RFC 1035^[1]	ポインタレコード	canonical nameへのポインタ。CNAMEとは異なり、DNS処理が停止し、名前のみ回答される。最も一般的な用途は、DNSの逆引きである。他の用途として、DNS-SD（英語版）が含まれる。
RRSIG	46	RFC 4034	DNSSEC署名	Signature for a DNSSEC-secured record set. Uses the same format as the SIG record.
RP	17	RFC 1183	担当者	Information about the responsible person(s) for the domain. Usually an email address with the @ replaced by a .
SIG	24	RFC 2535	署名	Signature record used in SIG(0) (RFC 2931) and TKEY (RFC 2930).^[7] RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.^[7]
SOA	6	RFC 1035^[1] and RFC 2308^[9]	Start of [a zone of] authority レコード	DNSゾーン（英語版）に関する特定のauthoritative情報。プライマリネームサーバ、ドメイン管理者の電子メール、ドメインのシリアル番号、ゾーンのリフレッシュに関連するいくつかのタイマーを含む。
SRVレコード（英語版）	33	RFC 2782	Service locator	Generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX.
SSHFP	44	RFC 4255	SSH公開鍵フィンガープリント	Resource record for publishing SSH public host key fingerprints in the DNS System, in order to aid in verifying the authenticity of the host. RFC 6594 defines ECC SSH keys and SHA-256 hashes. See the IANA SSHFP RR parameters registry for details.
SVCB	64	IETF ドラフト	サービス割り当て	RR that improves performance for clients that need to resolve many resources to access a domain. More info in this IETF Draft by DNSOP Working group and Akamai technologies.
TA	32768	N/A	DNSSEC Trust Authorities	Part of a deployment proposal for DNSSEC without a signed DNS root. See the IANA database and Weiler Spec for details. Uses the same format as the DS record.
TKEYレコード（英語版）	249	RFC 2930	秘密鍵レコード	A method of providing keying material to be used with TSIG（英語版） that is encrypted under the public key in an accompanying KEY RR.^[10]
TLSA（英語版）	52	RFC 6698	TLSA証明書アソシエーション	A record for DNS-based Authentication of Named Entities (DANE). RFC 6698 defines "The TLSA DNS resource record is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a 'TLSA certificate association'".
TSIG（英語版）	250	RFC 2845	Transaction Signature	Can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server^[11] similar to DNSSEC.
TXTレコード（英語版）	16	RFC 1035^[1]	テキストレコード	当初はDNSレコードで、人間が読めるテキスト形式のレコードだった。しかし、1990年代初頭以来、本レコードは、RFC1464で指定されたように、頻繁に機械可読データに利用されるようになった。日和見暗号化、Sender Policy Framework（SPF）、DKIM、DMARC、DNS-SD（英語版）など。

他のタイプの擬似リソースレコード

コード	番号	Defining RFC	説明	機能
*	255	RFC 1035^[1]	全キャッシュレコード	ネームサーバーが保持している全てのタイプのすべてのレコードを回答する。ネームサーバーが情報を持っていない場合、要求は上位に転送される。回答されるレコードは、完全でない可能性がある。例えば、AレコードとMXレコードの両方があり、ネームサーバがAレコードのみをキャッシュしている場合、Aレコードのみ回答される。また、WindowsのnslookupやWiresharkなどで見られるように、"ANY"と呼ばれることもある。
AXFR	252	RFC 1035^[1]	Authoritative ゾーン転送	セカンダリネームサーバにマスターネームサーバからゾーンファイル全体を転送する。
IXFR	251	RFC 1996	増分ゾーン転送	前回のシリアル番号から指定されたゾーンの差分のゾーン転送を要求する。
OPT	41	RFC 6891	オプション	EDNS（英語版）をサポートするために必要な「疑似DNSレコードのタイプ」である。

廃止されたレコードタイプ

Obsoleted by RFC 973: MD(3), MF (4), MAILA (254)
Records to publish mailing list subscriber lists in the DNS: MB(7), MG(8), MR(9), MINFO(14), MAILB (253). The intent, as specified by RFC 883, was for MB to replace the SMTP VRFY command, MG to replace the SMTP EXPN command, and MR to replace the "551 User Not Local" SMTP error. Later, RFC 2505 recommended that both the VRFY and EXPN commands be disabled, making the use of MB and MG unlikely to ever be adopted.
Declared "not to be relied upon" by RFC 1123 (with further information in RFC 1127): WKS(11)^[12]
Mistakes: NB(32), NBSTAT(33) (from RFC 1002); the numbers are now assigned to NIMLOC and SRV.
Obsoleted by RFC 1035: NULL(10) (RFC 883 defined "completion queries" (opcode 2 and maybe 3) which used this record, RFC 1035 later reassigned opcode 2 to be "status" and reserved opcode 3.)
Defined as part of early IPv6 but downgraded to experimental by RFC 3363: A6(38), Later downgraded to historic in RFC 6563.
Obsoleted by DNSSEC updates (RFC 3755): NXT(30). At the same time, the domain of applicability for KEY and SIG was also limited to not include DNSSEC use.
Part of the first version of DNSSEC (RFC 2065).
Not in current use by any notable application: HINFO(13), RP(17), X25(19), ISDN(20), RT(21), NSAP(22), NSAP-PTR(23), PX(26), EID(31), NIMLOC(32), ATMA(34), APL(42)
Defined by the Kitchen Sink internet draft, but never made it to RFC status: SINK(40)
A more limited early version of the LOC record: GPOS(27)
IANA reserved, no RFC documented them [1] and support was removed from BIND in the early 90s: UINFO(100), UID(101), GID(102), UNSPEC(103)
SPF(99) (from RFC 4408) was specified as part of the Sender Policy Framework protocol as an alternative to storing SPF data in TXT records, using the same format. It was later found that the majority of SPF deployments lack proper support for this record type, and support for it was discontinued in RFC 7208.^[13]^[14]

RP(17) may be used for certain human-readable information regarding a different contact point for a specific host, subnet, or other domain level label separate than that used in the SOA record.

参考

“IANA DNS Parameters registry”. 2008年5月25日閲覧。
“Google's Guide to DNS Records”. 2010年12月9日閲覧。

出典・脚注

[脚注の使い方]

^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ Paul Mockapetris (November 1987). “RFC [https://datatracker.ietf.org/doc/html/rfc1035 1035: Domain Names - Implementation and Specification]”. Network Working Group of the IETF (Internet Engineering Task Force). p. 12. 2011年1月12日閲覧。
^ “RFC [https://datatracker.ietf.org/doc/html/rfc3596 3596: DNS Extensions to Support IP Version 6]”. The Internet Society (October 2003). 2011年1月13日閲覧。
^ RFC 2535, §3
^ RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
^ RFC 2931, §2.4. "SIG(0) on the other hand, uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer."
^ RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
^ ^a ^b ^c RFC 3755, §3. "DNSKEY will be the replacement for KEY, with the mnemonic indicating that these keys are not for application use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace SIG, and NSEC (Next SECure) will replace NXT. These new types completely replace the old types, except that SIG(0) [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY."
^ RFC 4025, Abstract. "This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445."
^ The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.
^ RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]."
^ RFC 2845, abstract
^ RFC 1123 section 2.2, 5.2.12, 6.1.3.6
^ Kucherawy, M. "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. 2013年8月31日閲覧。
^ Kitterman, S. (2014年4月). "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. 2014年4月26日閲覧。