An A–Z list of DNS record types: the everyday ones every zone has, the DNSSEC and security records, the specialised ones you meet in VoIP, Kerberos or service discovery, the query-only pseudo-types that tools print, and the obsolete ones you still find in old zone files. Each entry gives the type number and defining RFC, what the record does, an example in zone-file syntax, the mistakes that break it and how to check it.
Look up the common types live with DNS Lookup. When a lookup fails rather than returning the wrong data, the DNS error codes A–Z explains the status you got.
No entry matches.
Maps a name to an IPv4 address: www.example.com. 300 IN A 192.0.2.10. Several A records on one name give simple round-robin. Common mistakes: a private address (10.x, 192.168.x) published in public DNS, an apex left without an A record after a host move, and a TTL so long that a migration takes a day to reach everyone. Check with DNS Lookup.
Maps a name to an IPv6 address: www.example.com. 300 IN AAAA 2001:db8::10. Publish it only if the service really answers on IPv6. A AAAA record pointing at a host that doesn't listen there makes IPv6 clients wait for a timeout before falling back to IPv4. Check the record with DNS Lookup and the reverse name with PTR Lookup.
Pointed to AFS cell database servers and DCE/NCA services. Almost unused today; RFC 5864 recommends SRV records for AFS instead. Safe to remove unless a legacy AFS deployment still reads it.
Not a real record type: there is no ALIAS in the IANA registry. DNS providers offer it to work around the rule that a CNAME can't sit at the zone apex. The provider's server resolves the target itself and answers with ordinary A/AAAA records, so resolvers never see an "ALIAS". Names vary (ALIAS, ANAME, CNAME flattening). It works only on the provider that offers it and doesn't move with a zone transfer. Background: CNAME, A and ALIAS.
A query type, not a record you publish: "send me every record for this name". Because ANY answers were abused for amplification attacks, RFC 8482 lets servers return a minimal answer (often a single HINFO record) instead of everything. Never rely on ANY to list a zone; query each type you need.
Lists address prefixes ("address prefix list"), for example APL 1:192.0.2.0/24 !1:192.0.2.128/25. Experimental and practically unused. Some resolvers and providers don't support it at all.
Zone-transfer query types: AXFR copies the whole zone, IXFR only the changes since a given SOA serial. Secondaries use them to stay in sync with the primary. Allow them only to your own secondaries, by IP and ideally with a TSIG key; an open AXFR hands anyone your full zone, internal names included. NODA tests for it (AXFR / Zone Transfer check).
Says which certificate authorities may issue certificates for the domain: example.com. CAA 0 issue "letsencrypt.org", plus issuewild for wildcards and iodef for violation reports. CAs must check it before issuing. It applies to subdomains unless they have their own CAA. Common mistake: adding CAA for one CA and forgetting the one your CDN or email provider uses, which then silently fails to renew. Check with DNS Lookup, and see who has actually issued with CT Log Search.
Published by the child zone to tell the parent which DS record it wants. Registries and registrars that support it scan for CDS/CDNSKEY and update the DS automatically, which removes the manual step in key rollovers. A special value (CDS 0 0 0 00) asks the parent to remove the DS and turn DNSSEC off safely. Only useful if your registry or registrar scans for it.
Stores a certificate or a CRL (X.509, PGP and others) in DNS. Rarely used; TLSA, SMIMEA and OPENPGPKEY cover the common cases with DNSSEC-based trust. You may meet it in older PGP key-distribution setups.
Makes one name an alias of another: www.example.com. CNAME example.net. Resolvers then look up the target. A name with a CNAME may have no other records, which is why a CNAME can't sit at the zone apex (the apex needs SOA and NS) and can't share a name with MX or TXT. Long chains slow every lookup. Don't point MX or NS at a CNAME (RFC 2181 §10.3). More: CNAME, A and ALIAS.
Lets a child zone ask the parent to copy its NS records or glue automatically, the way CDS does for DS. Support at registries is still limited. Useful mainly if you change nameservers often and your registry supports it.
Written by DHCP servers that update DNS dynamically, to record which client owns a name and avoid two clients fighting over it. You'll find it in Windows/ISC DHCP setups with dynamic DNS; it isn't meant to be edited by hand.
DNSSEC Lookaside Validation: a stopgap that published trust anchors outside the parent zone while the root and TLDs weren't signed yet. The main DLV registry closed in 2017 and RFC 8749 moved DLV to Historic. Remove any leftover DLV configuration from resolvers.
Redirects a whole subtree: old.example. DNAME new.example. makes a.old.example resolve as a.new.example, for every name below it (but not old.example itself). Used for domain renames and IPv6 reverse-zone moves. Servers synthesise a CNAME for older resolvers. If the rewritten name would exceed 255 bytes, the answer is YXDOMAIN.
The zone's public DNSSEC keys. Flags 257 marks a key-signing key (KSK, the one the parent's DS points to), 256 a zone-signing key (ZSK). Resolvers use these keys to verify RRSIG signatures. Keys alone don't make a zone secure: without a matching DS at the parent, validators ignore them. Prefer algorithm 13 (ECDSA P-256) or 15 (Ed25519). Check the chain with the DNSSEC Checker.
Published in the parent zone (usually by your registrar) and holds a hash of the child's key-signing key. It's the link that makes the child's DNSSEC trusted. Use digest type 2 (SHA-256). The classic outage: changing DNS provider while the old DS is still at the registrar, so every validating resolver returns SERVFAIL. Remove or replace the DS before or during a provider move. Check with the DNSSEC Checker.
Originally described a host's CPU and operating system. Publishing that is now considered an information leak, so it's rarely used. It came back in one role: RFC 8482 servers answer ANY queries with a synthetic HINFO record (for example "RFC8482" ""). If you see that, nothing is wrong.
Publishes a Host Identity Protocol identity (a public key) and rendezvous servers for a host. Only used in HIP deployments, which are rare outside research and some industrial networks.
Tells clients how to connect before they connect: supported protocols (alpn="h3,h2"), alternative endpoints, IP hints and Encrypted ClientHello keys. example.com. HTTPS 1 . alpn="h3,h2" lets browsers go straight to HTTP/3. Priority 0 is alias mode and, unlike CNAME, works at the zone apex. SVCB is the general form for other protocols. Most CDNs publish it automatically.
Publishes an IPsec public key and gateway for a host, used for opportunistic encryption. It should only be trusted when the zone is DNSSEC-signed. Rarely deployed.
The first-generation DNSSEC records. RFC 3755 replaced them with DNSKEY and RRSIG for zone signing. SIG(0) transaction signatures still exist in a few dynamic-update setups, but you shouldn't see KEY/SIG in a modern signed zone.
Names a key-exchange host for a domain, in the style of MX, for IPsec key negotiation. Informational RFC, essentially unused.
Gives the physical location of a host as latitude, longitude, altitude and precision: LOC 40 26 57 N 79 58 12 W 300m. Cloudflare supports it; most others don't. Keep in mind it's public: don't publish the location of anything you'd rather keep private.
The original mail and service records from 1987, replaced by MX (RFC 974) and never really used since. WKS ("well-known services") listed open ports and is obsolete as well. If old software or a zone file still contains them, remove them.
Says which servers receive mail for the domain, with a preference (lower is tried first): example.com. MX 10 mx1.example.com. The target must be a host name with A/AAAA records, not an IP and not a CNAME. With no MX, senders fall back to the domain's A record. A domain that receives no mail should publish a null MX (MX 0 ., RFC 7505) plus a null SPF. Check with SPF / DKIM / DMARC Checker and DNS Lookup.
A rewrite rule used by Dynamic Delegation Discovery (DDDS): it maps a name to a service and the next name or URI to look up, often followed by SRV. You meet it in SIP/VoIP and ENUM (phone numbers in DNS, under e164.arpa). The regex field is easy to get wrong; test the whole NAPTR → SRV → A chain.
Lists the authoritative nameservers for a zone. It exists twice: in the parent zone (the delegation, set at your registrar) and in the zone itself. The two lists should match. Use at least two nameservers, ideally on different networks; a nameserver name inside the zone it serves needs glue at the parent. Common breakage: a leftover NS after a provider move that answers REFUSED. Check delegation and consistency with NODA and the records with DNS Lookup.
DNSSEC's signed proof that a name or type doesn't exist: each NSEC names the next existing name in the zone. Side effect: anyone can walk the chain and list every name in the zone ("zone walking"). If that matters to you, use NSEC3, or the "black lies" / compact denial approach many signing providers use.
Like NSEC, but proves non-existence over hashed names, which makes zone walking harder (not impossible: hashes can be cracked offline). NSEC3PARAM publishes the hash parameters. RFC 9276 says to use 0 extra iterations and an empty salt: more iterations cost resolvers CPU without adding real protection, and resolvers may treat high values as insecure (EDE 27). Check the current value with dig NSEC3PARAM example.com.
Publishes a user's OpenPGP public key in DNS under a hash of the local part of their address: <sha256-of-local-part>._openpgpkey.example.com. Only meaningful in a DNSSEC-signed zone. Most deployments use Web Key Directory (WKD) over HTTPS instead.
A pseudo-record that carries EDNS(0) in a query or response: the UDP payload size, the DNSSEC OK (DO) bit, and options such as cookies, client subnet and Extended DNS Errors. It never appears in a zone file. dig prints it as the "OPT PSEUDOSECTION". Broken handling of OPT by old servers and firewalls is the usual cause of FORMERR.
Maps an address back to a name, under in-addr.arpa (IPv4) or ip6.arpa (IPv6): 10.2.0.192.in-addr.arpa. PTR mail.example.com. The reverse zone belongs to whoever owns the IP block, usually your hosting provider, so you set PTR in their panel, not in your domain's DNS. Mail servers need one that matches a forward A/AAAA record and the HELO name. Check with PTR Lookup.
Names the "responsible person" for a domain as a mailbox and a TXT pointer. Rarely published today, mostly because it attracts spam; the SOA RNAME field and RDAP contacts cover the same need.
The DNSSEC signature over one record set, with an inception and expiration time. Signers re-create them on a schedule; if signing stops, the zone keeps working until the signatures expire and then fails everywhere validation is on (EDE 7). A record set with no RRSIG in a signed zone fails validation too (EDE 10). Request them with dig +dnssec; check expiry with the DNSSEC Checker.
Publishes an S/MIME certificate for an email address, in the same format as TLSA, under <hash>._smimecert.example.com. Lets mail clients find and trust a recipient's certificate via DNSSEC. Little client support so far.
The zone's header record, exactly one per zone, at the apex: primary nameserver (MNAME), contact mailbox (RNAME, with the first dot meaning @), serial, and the refresh/retry/expire timers for secondaries. The last field sets how long resolvers cache "doesn't exist" answers (RFC 2308), which is why a new name can stay NXDOMAIN for a while. Raise the serial on every change, or secondaries won't pick it up; a date-based YYYYMMDDnn is the usual convention. Check SOA consistency across nameservers with NODA.
A dedicated record type for SPF that never caught on. RFC 7208 (2014) removed it: SPF lives in a TXT record starting with v=spf1, and type-99 records are ignored by receivers. If your provider still offers an "SPF" record type, use TXT instead. Build and check the TXT version with the SPF Record Generator.
Says where a service runs: _sip._tcp.example.com. SRV 10 60 5060 sip1.example.com. (priority, weight, port, target). Used by SIP, XMPP, LDAP, Kerberos, Active Directory, Minecraft, Matrix and others. The name must carry both labels, _service._proto; the target must be a host name with A/AAAA, not a CNAME. A target of . means "service not offered here". Check with DNS Lookup.
Publishes the fingerprint of a host's SSH key, so a client can verify the server on first connect instead of asking "are you sure?". OpenSSH uses it with VerifyHostKeyDNS yes, but only trusts it when the answer is DNSSEC-validated. Generate the records on the server with ssh-keygen -r host.example.com.
DANE: binds a TLS certificate or key to a service name, under _port._proto.host, for example _25._tcp.mail.example.com. TLSA 3 1 1 <sha256>. Used mostly for SMTP between mail servers, where it protects against downgrade and fake certificates. It requires a DNSSEC-signed zone. Update the TLSA record before rotating the key, or mail delivery to you breaks. Check the certificate with the SSL Checker.
Meta-records that exist only inside a message, never in a zone. TSIG signs a DNS message with a shared secret (typically HMAC-SHA256) to authenticate zone transfers, NOTIFY and dynamic updates between servers. TKEY negotiates such keys. Both sides need the same key name, algorithm and secret, and clocks within the allowed skew; otherwise you get BADSIG, BADKEY or BADTIME.
Free-form text, used for SPF (v=spf1 …), DKIM keys (selector._domainkey), DMARC (_dmarc), and domain-verification tokens for Google, Microsoft and others. Each string is limited to 255 characters; longer values are split into several quoted strings that receivers join without spaces. Common mistakes: two SPF records (invalid), smart quotes pasted from a document, and verification tokens left behind years after they were used. Check SPF/DKIM/DMARC with the SPF / DKIM / DMARC Checker.
Maps a service name to a URI, with priority and weight like SRV: _ftp._tcp.example.com. URI 10 1 "ftp://ftp.example.com/pub". Used by Kerberos (MIT, for KDC discovery) and some other protocols. Not widely supported by DNS providers.
A digest of the whole zone, placed at the apex, so a receiver can verify that a full copy is complete and unmodified, independent of how it was transferred. The root zone has published it since 2023. Useful for zones that are distributed as files (for example local root copies, RFC 8806).
Type numbers from the IANA DNS Parameters registry; defining RFC named in each entry. Score a whole domain's DNS with NODA.
