DNS record types explained

How to read a record line

Every record has the same five parts, in this order: the name it is published under, the TTL in seconds, the class (always IN, for Internet, in practice), the type, and the type-specific data. Once you can split a line into those five parts, an unfamiliar record type is only a question of what its data field means.

The trailing dot on a name is not a typo. A name ending in a dot is fully qualified — example.com. is the complete name. A name without one, typed into a DNS control panel, is usually interpreted relative to the zone, so entering example.com in a field that already appends the zone gives you example.com.example.com. That is one of the most common ways a record ends up published at the wrong name.

example.com.	143	IN	A	104.20.23.154
example.com.	143	IN	A	172.66.147.243

; name         TTL  class  type  data

A and AAAA: the address records

A holds one IPv4 address, AAAA holds one IPv6 address. Both answer the same question — what address should a client connect to for this name — and a name can carry several of each at once, as example.com does above.

Multiple address records are not a priority list. A client picks one, and the order it is given in can vary between queries, so publishing several A records distributes connections roughly but gives you no control over which address a given visitor gets and no health checking. If one of those addresses stops answering, a share of visitors get a connection failure until the record is removed; DNS itself will not notice.

AAAA records are worth publishing if the service behind them genuinely works over IPv6. Publishing an AAAA record for a host that does not actually listen on IPv6 is worse than publishing none at all, because clients on IPv6 networks will prefer it, try it first, and only fall back after a timeout that the visitor experiences as a slow page.

CNAME: an alias, and why it cannot sit at the apex

A CNAME says that a name is an alias for another name, and that every lookup for it should continue at the target. A resolver asking for an address record at www.github.com is told to go and ask github.com instead.

The rule that catches people is that a CNAME cannot coexist with any other record at the same name (RFC 1034 §3.6.2). The apex of a zone — example.com itself, with no subdomain — must carry SOA and NS records, so it can never carry a CNAME. This is why you cannot point a bare domain at a platform that only gives you a hostname.

DNS providers work around this with a synthetic record type, variously called ALIAS, ANAME or CNAME flattening. The provider resolves the target itself and serves the resulting addresses as ordinary A and AAAA records at the apex. It behaves correctly from the outside, but it is a provider feature and not a standard type, so it does not transfer when you move zones and it is not something you can publish in a zone file yourself.

www.github.com.	3600	IN	CNAME	github.com.

MX: where mail goes, and how to say it goes nowhere

An MX record has two fields: a preference number and a hostname. Lower preference is tried first; equal preference values are a rough split between the listed hosts. The hostname must itself resolve to an A or AAAA record — an MX record may not point at an IP address, and may not point at a CNAME.

A domain that does not receive mail should say so explicitly with a null MX: preference 0 and a single dot as the hostname, defined in RFC 7505. This is not the same as publishing nothing. A domain with no MX record at all invites senders to fall back to its A record and try to deliver mail to the web server; a null MX tells them to give up immediately and return a permanent failure, which is both faster for the sender and one less surface for abuse. example.com publishes exactly this.

If you are configuring mail for Google Workspace or Microsoft 365, the exact hostnames and preferences each expects are covered in the MX setup guide rather than here, because they are provider configuration rather than a property of the record type.

example.com.	300	IN	MX	0 .

; preference 0, hostname "." — a null MX: this domain accepts no mail (RFC 7505)

TXT: the general-purpose record everything else is built on

A TXT record holds free text, and a name can carry many of them at once. Because it is the only widely available place to publish arbitrary data under a name, it has become the substrate for most of the protocols that are not themselves DNS: SPF at the apex, DKIM keys under _domainkey, DMARC policy at _dmarc, MTA-STS at _mta-sts, TLS-RPT at _smtp._tls, and a long tail of ownership-verification strings from SaaS vendors.

There are two size limits and they are different things. A single TXT string may not exceed 255 characters; a longer value is published as several quoted strings inside one record, which the DNS protocol concatenates back together on the way out. Separately, a whole DNS response over UDP has practical size limits, so a name carrying dozens of verification strings can grow large enough to force retries over TCP.

Because everything lives here, the failure mode is collision rather than corruption. Two SPF records at the same name is a configuration error that makes SPF fail outright, even though DNS itself is perfectly happy to serve both. When a protocol says exactly one record, DNS will not enforce it for you.

"v=spf1 -all"
"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

NS and SOA: who is in charge of the zone

NS records name the authoritative servers for a zone. They exist in two places at once: inside the zone itself, and in the parent zone as the delegation. Those two sets are supposed to match, and a domain where they have drifted apart — usually after a DNS provider move where the registrar was updated but the old zone was left behind, or the reverse — behaves unpredictably, because a resolver may follow either.

SOA carries the zone's administrative parameters in a single line, and reading it is worth the minute it takes. In the record below the fields are, in order: the primary name server, the zone contact address with the first dot standing in for the @ sign, the serial number, the refresh interval, the retry interval, the expire time, and the minimum TTL.

That last field is not, despite the name, a default TTL for the zone. Since RFC 2308 it governs negative caching: how long a resolver may remember that a name does not exist. The actual limit is the smaller of that minimum field and the TTL of the SOA record itself, which for the record below is 1800 seconds either way. A zone with a large minimum will have non-existence cached for a long time, which is why a newly created subdomain can stay invisible to a resolver that looked for it a few minutes too early.

example.com.	1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2413856909 10000 2400 604800 1800

; primary NS, contact, serial, refresh, retry, expire, negative-cache TTL

CAA: which certificate authorities may issue

A CAA record (RFC 8659) names the certificate authorities allowed to issue certificates for a domain. Publicly trusted CAs are required by the CA/Browser Forum baseline requirements to check for it and to refuse issuance when a record exists that does not list them, which makes CAA one of the few DNS records that actually prevents something rather than merely describing it.

Each record has a flags byte, a property tag and a value. issue authorises ordinary certificates, issuewild separately authorises wildcards, and iodef gives an address where a CA should report a request that violated the policy. A domain can authorise a CA for ordinary certificates while refusing it wildcards, and a value of ";" for a tag means nobody may issue that kind of certificate at all.

CAA is inherited: if a name has no CAA record of its own, the CA walks up the tree until it finds one. This is the useful behaviour most of the time and the surprising behaviour occasionally, because a record at the apex constrains every subdomain that does not override it.

The risk in adding CAA is specific and worth stating plainly: if you omit a CA you actually use, nothing breaks today, and then a renewal fails weeks later when the CA refuses to issue. Managed certificates from a CDN or hosting platform are the usual casualty, because the CA behind them is not always obvious. Check what is issuing your current certificate before you publish, and if a renewal does start failing, deleting the CAA record restores issuance within its TTL.

cloudflare.com.	300	IN	CAA	0 issue "letsencrypt.org"
cloudflare.com.	300	IN	CAA	0 issue "digicert.com; cansignhttpexchanges=yes"
cloudflare.com.	300	IN	CAA	0 issuewild "letsencrypt.org"
cloudflare.com.	300	IN	CAA	0 iodef "mailto:tls-abuse@cloudflare.com"

PTR: the reverse direction, in somebody else's zone

A PTR record maps an address back to a name, and it lives in a reverse zone derived from the address itself: in-addr.arpa for IPv4, ip6.arpa for IPv6. The address is written backwards, so 8.8.8.8 becomes 8.8.8.8.in-addr.arpa.

The important practical point is ownership. Reverse zones are delegated with the address space, so the PTR record for your server is published by whoever allocated the address — your hosting provider or ISP — and not by you in your own zone. Setting one means using their control panel or asking their support, and no amount of editing your domain's DNS will produce it.

Mail is where this matters. Receiving servers routinely check that a connecting address has a PTR record and that the name it returns resolves forward to the same address, a round trip usually called forward-confirmed reverse DNS. A sending address with no PTR at all looks like a compromised home machine or a throwaway cloud instance, and is treated accordingly.

8.8.8.8.in-addr.arpa.	11237	IN	PTR	dns.google.

SRV: a host and a port for a named service

An SRV record (RFC 2782) publishes where a specific service runs, rather than where a domain points in general. The name encodes the service and protocol as underscore-prefixed labels, and the data carries four fields: priority, weight, port and target host.

Priority works like MX preference — lowest first. Weight distributes load between records sharing a priority, proportionally rather than evenly, so a weight of 30 against a weight of 10 takes roughly three times the traffic. The port is the part no other record type can express, and it is why protocols such as XMPP, SIP, LDAP and Minecraft use SRV instead of a plain A record.

SRV only works when the client goes looking for it. Browsers do not consult SRV records for ordinary web traffic, which is the usual reason a correctly published SRV record appears to do nothing.

_xmpp-server._tcp.jabber.org. 60 IN	SRV	30 30 5269 scarlet.jabber.org.

; priority 30, weight 30, port 5269, target scarlet.jabber.org

HTTPS and SVCB: connection parameters before the first request

HTTPS and SVCB records (RFC 9460) let a name advertise how to connect to it, not just where. A single record can carry the supported application protocols, an alternative port, an alternative target host, address hints, and the public key material for encrypted client hello — all fetched in the same round trip as the address lookup.

The practical effect today is that a browser that supports them can start an HTTP/3 connection immediately, rather than connecting over HTTP/2 and being told to upgrade by an Alt-Svc header afterwards. The HTTPS type is the web-specific form; SVCB is the general one for other protocols.

You are unlikely to publish these by hand. They are normally produced by a CDN or DNS provider on your behalf, and the reason to recognise them is so that an unfamiliar record type in a lookup does not read as a fault.

DS, DNSKEY, RRSIG and NSEC: the DNSSEC types

A signed zone carries several extra types that exist only to prove the other records have not been altered. DNSKEY holds the zone's public keys. RRSIG holds a signature over a set of records, with a validity window. NSEC and NSEC3 prove that a name does not exist, which is the harder half of the problem — you cannot sign an answer you are not giving.

DS is the one that lives elsewhere. It is a hash of the zone's key, published in the parent zone, and it is what links a zone into the chain of trust running back to the DNS root. Because it is in the parent, it is set through your registrar rather than your DNS host, which is the source of most DNSSEC breakage: the zone is re-signed with a new key and the DS record at the registrar is left pointing at the old one.

The consequence is severe and worth knowing before you enable it. A DS record that does not match the zone's current key does not degrade gracefully — every validating resolver treats the whole zone as unresolvable, which for most of the internet is indistinguishable from the domain ceasing to exist. The fix is to remove the DS record at the registrar, which restores resolution once the old record's TTL expires. Enable DNSSEC deliberately, and never leave a key rollover half-finished.

cloudflare.com.	7706	IN	DS	2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D63826F2B9

What commonly goes wrong

• A record published at the wrong name, because the control panel appended the zone to a value that was already fully qualified. Look the record up afterwards rather than trusting the form.

• A CNAME attempted at the apex, or a CNAME sitting alongside other records at the same name. Both are invalid; the second is often accepted by a control panel and then behaves inconsistently.

• An MX record pointing at a CNAME or at a bare IP address. Neither is permitted, and some senders will fail while others cope, which makes it look intermittent.

• Two SPF records at the apex, usually because a second mail provider's setup wizard added its own rather than merging into the existing one.

• An AAAA record for a host that does not listen on IPv6, producing slow page loads for IPv6 clients rather than an outright error.

• A DS record at the registrar that no longer matches the zone's key, which takes the entire domain offline for validating resolvers.

Every one of these is visible in a lookup. Running the DNS lookup against the exact name you just edited, immediately after editing it, catches most of them before anyone else sees them.