This is an overview of resource records (RRs) permissible in zone files of the Domain Name System (DNS). It also contains pseudo-RRs.
Resource records Type Type id (decimal)Defining RFC Description Function A1 Address record Returns a 32-bit IPv4 address, most commonly used to map hostnames to an IP address of the host, but it is also used for DNSBLs, storing subnet masks, etc. AAAA28 IPv6 address record Returns a 128-bit IPv6 address, most commonly used to map hostnames to an IP address of the host. AFSDB18AFS database recordLocation 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. APL42Address Prefix ListSpecify lists of address ranges, e.g. in CIDR format, for various address families. Experimental. CAA257Certification Authority AuthorizationDNS Certification Authority Authorization, constraining acceptable CAs for a host/domain CDNSKEY60Child copy of DNSKEY record, for transfer to parent CDS59Child DSChild copy of DS record, for transfer to parent CERT 37Certificate recordStores digital certificates in various forms (PKIX, SPKI, PGP, etc). CNAME5 Canonical name record Alias of one name to another: the DNS lookup will continue by retrying the lookup with the new name. CSYNC62RFC 7477Child-to-Parent SynchronizationSpecify a synchronization mechanism between a child and a parent DNS zone. Typical example is declaring the same NS records in the parent and the child zoneDHCID 49RFC 4701DHCP identifierUsed in conjunction with the FQDN option to DHCPDLV32769RFC 4431DNSSEC Lookaside Validation recordFor 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.DNAME39RFC 6672 Delegation name record 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.DNSKEY48DNS Key recordThe key record used in DNSSEC. Uses the same format as the KEY record.DS43Delegation signerThe record used to identify the DNSSEC signing key of a delegated zoneEUI48108RFC 7043MAC address (EUI-48)A 48-bit IEEE Extended Unique Identifier.EUI64109RFC 7043MAC address (EUI-64)A 64-bit IEEE Extended Unique Identifier.HINFO13 Placeholder record, or host informationRepurposed to be used while responding to ANY queries. Originally defined as "Host information", intended to inform about host's operating system and hardware. RFC 8482 did not obsolete this conventional meaning for explicit HINFO queries, but rather considers it rarely used.HIP55RFC 8005Host Identity ProtocolMethod of separating the end-point identifier and locator roles of IP addresses.HTTPS65HTTPS BindingA specialised type of SVCB record. Provides connection information required to establish a secure connection via HTTPS, which would ordinarily be obtained and negotiated during connection to the host. Obtaining the information from the DNS server instead of negotiating it with the host allows for more secure connections (e.g. by using Encrypted Client Hello) and lower latency when the connection to the host is first established.IPSECKEY45RFC 4025IPsec KeyKey record that can be used with IPsecKEY25RFC 2535RFC 2535, §3 RFC 2930RFC 3445, §1. "The KEY RR was defined in RFC 2930..."Key recordUsed only for SIG(0) (RFC 2931) and TKEY (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 eliminated their use for application keys and limited their use to DNSSEC.RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..." RFC 3755 designates DNSKEY as the replacement within DNSSEC.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 designates IPSECKEY as the replacement for use with IPsec.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."KX36RFC 2230 Key Exchanger record 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. LOC29RFC 1876 Location record Specifies a geographical location associated with a domain name MX15 RFC 7505 Mail exchange record List of mail exchange servers that accept email for a domain NAPTR35RFC 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. NS2 Name server record Delegates a DNS zone to use the given authoritative name serversNSEC47Next Secure recordPart of DNSSEC—used to prove a name does not exist. Uses the same format as the (obsolete) NXT record.NSEC350RFC 5155Next Secure record version 3An extension to DNSSEC that allows proof of nonexistence for a name without permitting zonewalkingNSEC3PARAM51RFC 5155NSEC3 parametersParameter record for use with NSEC3OPENPGPKEY61RFC 7929OpenPGP public key recordA DNS-based Authentication of Named Entities (DANE) method for publishing and locating OpenPGP public keys in DNS for a specific email address using an OPENPGPKEY DNS resource record. PTR12 Pointer to a canonical name. Unlike a CNAME, DNS processing stops and just the name is returned. The most common use is for implementing reverse DNS lookups, but other uses include such things as DNS-SD.RP17Responsible PersonInformation about the responsible person(s) for the domain. Usually an email address with the @ replaced by a .RRSIG46DNSSEC signatureSignature for a DNSSEC-secured record set. Uses the same format as the SIG record.SIG24RFC 2535SignatureSignature record used in SIG(0) (RFC 2931) and TKEY (RFC 2930). RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC. SMIMEA 53 RFC 8162 S/MIME cert association Associates an S/MIME certificate with a domain name for sender authentication. SOA 6 RFC 2308The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308. Start of [a zone of] authority record Specifies authoritative information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone. SRV33RFC 2782Service locatorGeneralized service location record, used for newer protocols instead of creating protocol-specific records such as MX. SSHFP44RFC 4255SSH Public Key FingerprintResource record for publishing SSH public host key fingerprints in the DNS, 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.SVCB64Service BindingThis resource record provides metadata and other information that can help clients connect to the host. The HTTPS record is a specialised SVCB record to help when establishing HTTPS connections. The more general SVCB record can provide other information such as supported protocols, alternative endpoints, and some types of aliasing not supported by CNAME records. TA32768DNSSEC Trust AuthoritiesPart 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.TKEY249RFC 2930Transaction Key recordA method of providing keying material to be used with TSIG that is encrypted under the public key in an accompanying KEY RR.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."TLSA52RFC 6698TLSA certificate associationA record for 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'".TSIG250RFC 2845Transaction SignatureCan be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name serverRFC 2845, abstract similar to DNSSEC.TXT16Text recordOriginally for arbitrary human-readable text in a DNS record. Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc.URI256RFC 7553Uniform Resource IdentifierCan be used for publishing mappings from hostnames to URIs.ZONEMD63RFC 8976Message Digests for DNS ZonesProvides a cryptographic message digest over DNS zone data at rest.
Other types and pseudo-RRs Other types of records simply provide some types of information (for example, an HINFO record gives a description of the type of computer/OS a host uses), or others return data used in experimental features. The "type" field is also used in the protocol for various operations.
Type Type id. Defining RFC Description Function*255All cached recordsReturns all records of all types known to the name server. If the name server does not have any information on the name, the request will be forwarded on. The records returned may not be complete. For example, if there is both an A and an MX for a name, but the name server has only the A record cached, only the A record will be returned. Usually referred to as ANY (e.g., in dig, Windows nslookup, and Wireshark). In 2019, standards-track publication led many DNS providers, including Cloudflare, to provide only minimal responses to "ANY" queries, instead of enumerating records.AXFR252 Authoritative Zone TransferTransfer entire zone file from the primary name server to secondary name servers. IXFR251RFC 1996 Incremental Zone Transfer Requests a zone transfer of the given zone but only differences from a previous serial number. This request may be ignored and a full (AXFR) sent in response if the authoritative server is unable to fulfill the request due to configuration or lack of required deltas. OPT41RFC 6891OptionThis is a pseudo-record type needed to support EDNS.ALIAS / ANAME / apex CNAME / CNAME flattening / top-level redirection -draft-ietf-dnsop-aname-04Alias similar to DNAMEAn ANAME, ALIAS. apex CNAME, CNAME flattening, or sometimes also top-level redirection record is a pseudo record type and a commonly used but not RFC-standardized record type. Its implementation varies. It serves as an alternative to CNAMEs especially for the bare domain name and where such records should co-exist with others. It causes the DNS software vendor to synthetically generate A and AAAA records similar to the ones of the ANAME-records destination. If the destination changes these synthetic A and AAAA records change automatically as well. The actual mechanisms used are often considered proprietary.
Obsolete record types Progress has rendered some of the originally defined record-types obsolete. Of the records listed at IANA, some have limited use, for various reasons. Some are marked obsolete in the list, some are for very obscure services, some are for older versions of services, and some have special notes saying they are "not right".