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.
For publishing DNSSEC trust anchors outside of the DNS delegation chain. Uses the same format as the DS record. RFC5074 describes a way of using these records.
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.
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.
Used only for SIG(0) (RFC2931) and TKEY (RFC2930).[5]RFC3445 eliminated their use for application keys and limited their use to DNSSEC.[6]RFC3755 designates DNSKEY as the replacement within DNSSEC.[7]RFC4025 designates IPSECKEY as the replacement for use with IPsec.[8]
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.
Resource record for publishing SSH public host key fingerprints in the DNS System, in order to aid in verifying the authenticity of the host. RFC6594 defines ECC SSH keys and SHA-256 hashes. See the IANA SSHFP RR parameters registry for details.
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.
A record for DNS-based Authentication of Named Entities (DANE). RFC6698 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'".
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.
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 RFC883, 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, RFC2505 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 RFC1123 (with further information in RFC1127): WKS(11)[12]
Mistakes: NB(32), NBSTAT(33) (from RFC1002); the numbers are now assigned to NIMLOC and SRV.
Obsoleted by RFC1035: NULL(10) (RFC883 defined "completion queries" (opcode 2 and maybe 3) which used this record, RFC1035 later reassigned opcode 2 to be "status" and reserved opcode 3.)
Defined as part of early IPv6 but downgraded to experimental by RFC3363: A6(38), Later downgraded to historic in RFC6563.
Obsoleted by DNSSEC updates (RFC3755): NXT(30). At the same time, the domain of applicability for KEY and SIG was also limited to not include DNSSEC use.
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)
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 RFC4408) 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 RFC7208.[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.
^ abcdefghiPaul 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日閲覧。
^RFC2931, §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."
^RFC3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
^ abcRFC3755, §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."
^RFC4025, Abstract. "This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC3445."
^The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC2308.
^RFC2930, §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 [RFC2535]."