Record types in depth

Every piece of data in DNS, whatever it describes, is a resource record with the same five parts. Written in the zone-file format that RFC 1035 defined in 1987, one record looks like this:

The owner is the name the record belongs to. The TTL is how many seconds a resolver may keep a copy (Chapter 4 is all about it). The class is almost always IN, for internet; the others are historical. The type says how to read the last field, the RDATA. For an A record the RDATA is four bytes of IPv4 address. For an MX record it is a 16-bit number and a domain name. For a TXT record it is one or more short strings. The type decides everything about the format, and nothing else does.

On the wire the type is not a word but a 16-bit number. IANA, the registry that also hands out port numbers, keeps the list. The words you type in a zone file are only names for those numbers.

The single most useful idea in this chapter is the RRset: all the records that share an owner name, a class and a type. If www.example.com has three A records, those three are one RRset. RFC 2181 made the set the unit of DNS: a server answers with the whole set or none of it, a resolver caches it as one thing, and the records in it must all carry the same TTL. Order inside a set means nothing. Exact duplicates collapse into one, because a set cannot hold the same member twice. If you ever wonder why DNS behaves the way it does, think in RRsets, not in lines of a zone file.

An A record holds a 32-bit IPv4 address; AAAA, defined in RFC 3596, holds a 128-bit IPv6 address. The name AAAA is a joke that stuck: four times the bits, four As. A name can have both, and on a modern network a client usually asks for both and races the connections, preferring IPv6 when it works.

A name can also have several of each, and that is the oldest form of load spreading on the internet. Because an RRset has no order, a server is free to rotate the records on each answer, so different clients try different addresses first. It is crude: DNS has no idea whether an address is overloaded or dead, and a cached answer keeps pointing at a broken machine until its TTL runs out. That is why the record types later in this chapter, SRV and HTTPS, add priorities, and why large sites steer traffic with smarter servers instead (Chapter 9).

A CNAME record says: this name is an alias, and every question about it should be asked about the canonical name instead. When a resolver looks up the A record of www.example.com and finds a CNAME pointing to edge.example.net, it restarts the lookup at edge.example.net and hands back both the CNAME and the final answer. Chapter 3 follows such chains hop by hop.

That redirect applies to every type at once, and that is the root of all the CNAME rules. If www could hold a CNAME and also its own MX record, which one should a mail server believe, the MX at www or the MX at the canonical name? RFC 2181, section 10.1, settles it bluntly. For any name, exactly one of these is true:

• it has one CNAME record and nothing else (DNSSEC signatures excepted);
• it has one or more records, none of them a CNAME;
• it exists but holds no records at all;
• it does not exist.

Now look at the top of a zone, the apex: the name example.com itself. The apex must hold an SOA record and NS records; that is what makes it the top of a zone (Chapter 6). Since it already holds data, it cannot also hold a CNAME. This is the famous apex problem. Point www at your hosting company with a CNAME and everything is fine. Try to do the same for example.com, which many people type without the www, and the zone is broken: some servers refuse to load it, others serve it and confuse resolvers.

Two related rules from RFC 2181 section 10.3 catch people the other way round. The name an MX or NS record points to must not be an alias. Those records trigger "additional section processing": the server adds the target's addresses to the answer so the client does not need a second query, and that shortcut does not follow CNAMEs. An MX pointing at an alias works badly at best. RFC 2782 says the same about SRV targets.

So how do so many sites put a bare example.com on a content delivery network? Most DNS providers offer a feature with a name like ALIAS, ANAME or CNAME flattening. You type something that looks like a CNAME at the apex; the provider's server looks up the target's addresses itself and answers with ordinary A and AAAA records, which are allowed at the apex. Cloudflare's documentation describes its version as following the chain and "returning the final IP address" instead of the CNAME. These are useful, but they are not DNS record types. There is no ALIAS in the IANA registry. Each provider implements its own, they do not transfer to secondary servers made by someone else, and the addresses you get depend on where the provider's server is, not where the visitor is.

An MX record carries two things: a preference, a number from 0 to 65535, and the name of a mail server. Lower numbers are tried first. A sending server looks up every MX record for the domain, sorts by preference, and works down the list until one accepts the message; servers with equal preference should be tried in random order, which spreads the load between them. The numbers themselves mean nothing beyond their order: 10 and 20 behave exactly like 1 and 2. People leave gaps so they can slot a server in later without renumbering.

What those mail servers then do with SPF, DKIM and DMARC records is Chapter 8. The record those three live in, TXT, has one structural rule worth knowing first. A TXT record's RDATA is not one string but a list of character-strings, each with a one-byte length in front. One byte counts to 255, so no single string can be longer than 255 bytes. Anything longer, such as a 2048-bit DKIM key, has to be split into several quoted strings inside the same record:

DNS itself does not join the pieces. It stores and returns them as a list, and the application decides what they mean; email's rules happen to say "glue them together with nothing in between." Two common surprises follow. A web form that lets you paste a 400-character value may split it for you, or may silently cut it, so check with dig. And two separate TXT records at the same name are two members of one RRset, in no particular order, which is a different thing from one record holding two strings.

MX solved "where is the mail server?" in 1987, for one service. SRV, defined in RFC 2782, solves it for any service. Its owner name says which service and which transport, each label starting with an underscore so it can never collide with a real host name: _sip._tcp.example.com is "the SIP service over TCP for example.com." The RDATA has four fields:

• Priority: like MX preference. Clients must try every target at the lowest priority before touching the next one.
• Weight: among targets with the same priority, how big a share of the clients each should get.
• Port: the TCP or UDP port, so a service no longer has to live on its well-known port.
• Target: the host name, which must have address records and must not be an alias. A target of "." means "this service is deliberately not offered here."

The weight is the interesting part, because RFC 2782 spells out the exact algorithm every client should run. Within one priority level:

1. Line the records up in any order, except that weight-0 records go first.
2. Walk the list keeping a running sum of the weights.
3. Pick a random whole number from 0 to the total, inclusive.
4. Choose the first record whose running sum is at least that number. That target is tried next.
5. Remove it and repeat with the rest, to build a full fall-back order.

Any public certificate authority can issue a certificate for any domain, once it is convinced the requester controls the domain. A CAA record, now defined by RFC 8659, lets a domain owner narrow that list: "only these authorities may issue for me." Since 2017, the CA/Browser Forum's rules require public certificate authorities to check it before issuing.

A CAA record has three parts: a flags byte, a tag, and a value. The tags you will use:

• issue: an authority (named by its domain) allowed to issue certificates for this name. issue ";" means nobody may.
• issuewild: the same, but only for wildcard certificates like *.example.com. When present, it overrides issue for wildcard requests.
• iodef: where to report a refused request, as a mailto: or https: address.

The clever part is the search. To issue for www.shop.example.com, the authority asks for CAA records at that exact name. If there are none, it removes the leftmost label and asks again at shop.example.com, then example.com, then com, stopping before the root. The first non-empty set it meets is the policy for the whole request; nothing above it is consulted. So one CAA set at your apex covers every name below it, and a subdomain can override it with its own set. If the climb finds nothing at all, any authority may issue.

The flags byte has one bit in use: 128, the critical flag. If an authority finds a critical tag it does not understand, it must refuse to issue. That lets a future tag say "if you can't enforce this, don't issue at all" instead of being quietly ignored.

A browser visiting https://example.com traditionally learns almost nothing from DNS: an address or two. It then has to discover everything else by trying. Does the server speak HTTP/3 over QUIC? It finds out only after a first connection, from a header. Is there an encryption key for the TLS handshake? No way to say. RFC 9460, published in 2023, adds two record types to carry that information up front: SVCB, "service binding," for any protocol, and HTTPS, the same format specialised for the web.

An HTTPS record starts with a priority. That number chooses between two modes.

• AliasMode (priority 0) says "this service is really over there," naming a target. It is the CNAME the apex was never allowed: unlike a CNAME it only redirects this one service, so the apex keeps its SOA, NS and MX records untouched.
• ServiceMode (priority 1 or more) describes an actual endpoint. Lower numbers are preferred, like MX. The target "." means "this same name." After the target come SvcParams, key=value pairs.

A client that understands the record can open an HTTP/3 connection on its first try. A client that does not understand the record simply ignores it and falls back to A and AAAA, which is why sites keep both. For services other than the web, SVCB uses the same underscore naming as SRV: _8443._foo.api.example.com for a protocol "foo" on port 8443.

A record whose owner starts with an asterisk label, like *.example.com, is a wildcard. It lets a server answer for names that are not in the zone. The intuitive rule, "the star matches anything," is wrong in two ways that matter, and RFC 4592 from 2006 exists to pin the real rule down.

The real rule works in three steps. First, if the name asked about exists in the zone, the wildcard is never used, even if that name holds no record of the requested type; the answer is "no data." Second, if the name does not exist, the server finds the closest encloser: the longest ancestor of the name that does exist. Third, it looks for the source of synthesis, the name made of an asterisk plus the closest encloser. If that exists, the server builds an answer from it, with the owner name changed to the name you asked about. If it does not, the answer is NXDOMAIN.

"Exists" is the subtle word. A name exists if it owns records, and also if any name below it owns records, even when it holds nothing itself. Such a name is an empty non-terminal. Put an SRV record at _ssh._tcp.host2.example and you have created _tcp.host2.example and host2.example as empty non-terminals. Now a question for host2.example hits an existing name: the wildcard at *.example stays silent, and the answer is "no data." The wildcard was blocked by a record you added for something else entirely.

Two more consequences. A wildcard only matches at one place in the tree: *.example.com answers for a.b.example.com only if b.example.com does not exist. And an asterisk anywhere but the leftmost label, as in sub.*.example, is just an odd literal name, not a wildcard. Instrument 3 uses the example zone from RFC 4592 itself, so you can check each case against the standard.