What Is DNS? How It Works and What Every Record Type Does

1. The Basics

The Domain Name System (DNS) is the internet's directory. It is usually described as a phone book, which is comforting and slightly wrong, because a phone book is one document that somebody prints. DNS is a distributed database with delegated authority: no single machine holds it, no single organisation publishes it, and every part of it is answered by whoever was handed responsibility for that part.

That delegation is the whole design. The root delegates .nl to the Dutch registry. The Dutch registry delegates petermartin.nl to whichever name servers the owner nominated. Those name servers answer for everything below it. Each level knows only enough to point at the next one.

The right mental model: DNS is not a lookup table, it is a chain of referrals. Nobody has the whole answer; everybody knows who to ask next. Almost every confusing DNS problem is a broken link in that chain, or a cached copy of a link that has since changed.

1.1 What a Record Actually Is

Everything DNS publishes is a resource record, and every resource record has the same five fields. Once you can read those five fields, every record type in this article is the same shape with different data in the last slot.

$ dig +noall +answer petermartin.nl A
petermartin.nl.         265     IN      A       23.88.98.40
      |                  |      |       |            |
      |                  |      |       |            └─ RDATA: the answer itself
      |                  |      |       └────────── TYPE: what kind of answer this is
      |                  |      └───────────────── CLASS: always IN, in practice
      |                  └─────────────────────── TTL: seconds a resolver may cache it
      └───────────────────────────── NAME: the name this record belongs to

The class field is a fossil from a time when the designers expected DNS to serve several separate networks. In practice you will type IN or leave it out for the rest of your career. The one place CH still shows up is a diagnostic trick: name servers answer hostname.bind CH TXT with the identity of the physical machine you reached.

1.2 Records Travel in Sets

A name plus a type is not one record, it is a resource record set (RRset): every record at that name with that type, treated as one unit. Ask for the NS records of a domain and you get all of them, in one answer, in no meaningful order:

$ dig +noall +answer petermartin.nl NS
petermartin.nl.         21600   IN      NS      chelsea.ns.cloudflare.com.
petermartin.nl.         21600   IN      NS      finley.ns.cloudflare.com.

This is not a display detail, it has three consequences you will meet in practice. A resolver caches the whole set or none of it. DNSSEC signs the whole set, not the individual records. And every record in a set must carry the same TTL: RFC 2181 (July 1997) deprecated differing TTLs within an RRset and told clients to treat a mismatch as an error. If a control panel appears to let you give two A records different TTLs, it is lying to you politely.

1.3 The Four Roles

Four different kinds of software are involved in every lookup, and mixing them up is the single most common source of confusion. They are not interchangeable.

The practical consequence: "the DNS is wrong" is never a complete sentence. A record can be correct on the authoritative server, stale in a recursive resolver, and absent from your own machine's cache, all at the same moment, and all three are behaving properly.

1.4 One Lookup, Start to Finish

When a browser needs www.petermartin.nl and nothing is cached anywhere, this is the journey:

your browser
    ↓  "where is www.petermartin.nl?"
stub resolver (in the operating system)
    ↓
recursive resolver (your ISP, or 1.1.1.1)
    ↓  asks a root server:    "who handles .nl?"
    ↓  asks the .nl registry: "who handles petermartin.nl?"
    ↓  asks Cloudflare:       "what is www.petermartin.nl?"
    ↓
back up the chain, cached at every step that allows it

Three questions to three different organisations, for one name. This sounds slow, and the first lookup is. Every step after that is answered from cache until the TTL runs out, which is why the second visit to a site feels instant.

Those two behaviours have names worth knowing, because documentation uses them without explanation. Your machine asks a recursive query: "give me the final answer, do the work". The resolver then makes iterative queries: "I do not need the answer, just tell me who to ask next". Almost nothing on the internet answers a recursive query for a stranger, and section 7.12 covers what happens to the ones that do.

The important part is what gets cached and where. The recursive resolver caches the answer and the referrals, so the next visitor asking for a different name under .nl skips the root entirely. This is also why a change you make is invisible to some people and not others: their resolvers cached at different moments. Nothing is being pushed anywhere. There is no propagation.

1.5 How the Question Travels

One layer below the chain of referrals is the transport, and it explains a family of failures that look like nothing else. Classic DNS runs on port 53, over both UDP and TCP. The old shorthand "DNS uses UDP" was never the whole story.

The reason both exist is a size limit set in 1987. RFC 1035 caps a plain UDP DNS message at 512 octets. A larger answer does not fail: the server sends back what fits, sets the truncation flag (tc) in the header, and the client is expected to ask again over TCP. RFC 7766 (March 2016) made supporting TCP a requirement rather than an option.

EDNS(0) (RFC 6891, April 2013) is the escape hatch. A client attaches an OPT pseudo-record advertising how large a UDP answer it can accept, and modern servers reply within that. You can see the negotiated value in any dig output:

$ dig petermartin.nl CAA | grep -E 'EDNS|MSG SIZE'
; EDNS: version: 0, flags:; udp: 1232
;; MSG SIZE  rcvd: 465

That answer is 465 bytes, comfortably inside the 1232 the two ends agreed on and comfortably outside the 512 that plain DNS allows. This matters in practice because DNSSEC and long TXT records make answers big. A firewall that permits UDP port 53 and blocks TCP port 53, which was once common advice, breaks exactly the large answers a signed zone produces, and it breaks them intermittently.

Three encrypted transports now sit alongside port 53. None of them changes a single record you publish, so as a domain owner there is nothing to configure:

All three encrypt the conversation between a client and its resolver. Not one of them encrypts anything between that resolver and your authoritative servers, and none of them proves an answer is genuine. That is DNSSEC's job, and the two are constantly confused: encryption hides the question, DNSSEC signs the answer.

1.6 Who Publishes These Records

Before the record types, one piece of vocabulary that costs people days. A domain feels like one thing you bought. It is really three separate arrangements with three different companies, and knowing which one to log into is most of the battle.

You never talk to the registry. You talk to a registrar, and the registrar talks to the registry on your behalf. On top of that split, the company answering DNS queries and the company running the website are frequently two more unrelated businesses. Here is one domain taken apart:

$ whois petermartin.nl | grep -A3 '^Registrar'
Registrar:
   Registrar.eu
   Hofplein 20
   3032AC Rotterdam

$ dig +short petermartin.nl NS
finley.ns.cloudflare.com.
chelsea.ns.cloudflare.com.

$ dig +short petermartin.nl
23.88.98.40

$ whois 23.88.98.40 | grep -iE '^(netname|org-name|country):'
netname:        CLOUD-NBG1
org-name:       Hetzner Online GmbH
country:        DE

Three companies for one domain name, which is a perfectly normal and well-run setup. It is also why "my hosting company should fix my DNS" so often goes nowhere: the hosting company may have nothing to do with it. Keep this table, because it answers the question that actually blocks people.

Rows two and five are the ones people get wrong. Changing name servers is a registrar action, not a DNS action, and no amount of editing records at either provider will do it. Turning on DNSSEC needs both ends to agree, which is why it is the change most likely to be left half-finished.

1.7 What This Article Covers

Sections 4 to 6 are the record types, which is most of the article: what each one is for, what its data means, and what happens when it is wrong. Section 6 ends with the complete register of every type IANA has assigned.

Two neighbouring subjects are covered elsewhere so this article does not repeat them. For the tooling side, reading dig output block by block, tracing a delegation and comparing a cache with the source, see the companion article on the dig command. For how a name resolves on a machine you administer, including /etc/resolv.conf, nsswitch.conf and container DNS, see DNS on Linux. And for where the DNS lookup sits in the whole page load, see what actually happens when you enter a URL.

3. A Short History

DNS was not designed as a grand architecture. It was written to solve an administrative crisis: one text file that had stopped scaling.

Before DNS, every machine on the ARPANET kept a local copy of a single file called HOSTS.TXT, maintained by the Network Information Center at the Stanford Research Institute. Every new host meant editing that file, and every machine on the network downloading it again. As the network grew, the file grew, the downloads grew, and the delay between "a host exists" and "everyone knows about it" grew with them.

In November 1983 Paul Mockapetris published the replacement as two documents: RFC 882, "Domain Names Concepts and Facilities", which described the idea, and RFC 883, which defined how it worked on the wire. The insight was to stop distributing a file and start distributing authority.

The record types tell the rest of the story. The original specification defined sixteen of them, and everything added since has been a response to something the internet turned out to need.

Two things are worth taking from that table. The core specification is from 1987 and has never been replaced, only extended: the wire format you are using today was designed for a network of a few thousand machines. And the additions cluster around three themes, which is the whole history of the internet in miniature - finding services rather than hosts, proving an answer is genuine, and keeping the question private.

5. The Records for Specific Jobs

Past the nine everyday types, the register splits into four groups: records that find a service, records that publish a key or a fingerprint, the DNSSEC machinery, and things you query with rather than store. Then there are the fossils, which are worth two minutes because you will meet their names in a dropdown.

5.1 SRV: Finding a Service, Not a Host

An A record tells a client where a machine is. It says nothing about which port to talk to, and nothing about what to do if there are three of them with different capacities. SRV, from RFC 2782 (February 2000), answers all three questions at once.

The name is structured: an underscore-prefixed service, an underscore-prefixed protocol, then the domain.

$ dig +noall +answer _sip._udp.sip.voice.google.com SRV
_sip._udp.sip.voice.google.com. 300 IN SRV 20 1 5060 sip-anycast-2.voice.google.com.
_sip._udp.sip.voice.google.com. 300 IN SRV 10 1 5060 sip-anycast-1.voice.google.com.
                                           |  |  |    |
                                           |  |  |    └─ target host
                                           |  |  └────── port
                                           |  └───────── weight, within the same priority
                                           └──────────── priority, lower wins

Priority works like MX: try the lowest, fall back upward. Weight is the part MX never had - among targets with equal priority, a client picks in proportion to the weights, so you can send twice the traffic to the bigger machine. A target of . means "this service is explicitly not offered here", which is a useful thing to be able to say.

The underscore in the name is deliberate. Underscores are not legal in host names, so a name beginning with one can never collide with a real machine. Everything that uses DNS as a metadata store adopted the convention: _dmarc, _domainkey, _acme-challenge are all the same idea.

SRV is heavily used by XMPP, SIP, LDAP, Kerberos, Minecraft and Microsoft Active Directory. It is not used by the web, and that is not an oversight - by the time SRV existed, every browser and every URL already assumed port 80. Fixing that took another twenty-three years.

5.2 SVCB and HTTPS: The First New Idea in Years

RFC 9460 (November 2023) defines two closely related types. SVCB (service binding) is the general mechanism; HTTPS is the same record specialised for web traffic so that browsers can look it up without a structured name.

What makes them different from everything before is that the data is a list of key-value parameters, extensible without a new record type ever again:

$ dig +noall +answer cloudflare.com HTTPS
cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2"
    ipv4hint=104.16.132.229,104.16.133.229
    ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

Read that as a set of promises made before the client connects. alpn="h3,h2" says this server speaks HTTP/3 and HTTP/2, so a browser can open a QUIC connection immediately instead of connecting over HTTP/1.1 and being told to upgrade. The ipv4hint and ipv6hint parameters carry addresses in the same answer, saving a round trip. The 1 is the priority and the . means "the target is this same name".

Google's answer is deliberately smaller, which is also worth seeing:

$ dig +noall +answer www.google.com HTTPS
www.google.com.         6393    IN      HTTPS   1 . alpn="h2,h3"

Every record type before SVCB answered one fixed question with one fixed shape. SVCB answers "what should I know before I connect to you?" with a list of parameters that can grow. It is the first type designed on the assumption that nobody knows yet what will need to go in it.

SVCB also carries ech, the parameter that publishes the key for Encrypted Client Hello. Without it, the hostname you are visiting travels in clear text at the start of every TLS handshake even though everything after it is encrypted. That is the single biggest privacy gap left in HTTPS, and the fix is delivered by a DNS record.

The other thing SVCB quietly fixes is the apex problem from section 4.2: a priority of 0 makes it an AliasMode record, which is a standardised alias that is allowed at the apex. After thirty years of provider-specific ALIAS workarounds, the standard grew the feature. Support is still arriving, so this is a "watch it land" item rather than a "deploy it today" item, but it is the direction.

5.3 ALIAS and ANAME Are Not Record Types

You will find ALIAS, ANAME or "CNAME flattening" in provider control panels. None of them is in the IANA register, none of them travels on the wire, and no resolver has ever seen one.

What actually happens is that your DNS provider resolves the target itself, on its own schedule, and publishes the result to the world as an ordinary A or AAAA record. The record type in the control panel is a user interface convenience over a background job. It works well, it is the right answer for an apex today, and the thing to remember is that it is a provider feature: moving to another provider means finding out whether they have one too.

5.4 DNAME: A CNAME for a Whole Branch

Where a CNAME redirects one name, a DNAME (RFC 6672, June 2012) redirects everything below a name:

old.example.com.    3600   IN   DNAME   new.example.com.

# a query for shop.old.example.com is answered as if it asked
# shop.new.example.com, without any record for it existing

Note what it does not do: DNAME does not redirect the name it sits on. old.example.com itself still needs its own records. That asymmetry is the reason most people who try DNAME once go back to writing the records out.

It is genuinely useful for renaming a company's entire internal subtree, and for reverse zones when an address block is re-delegated. For a normal website it is a tool you will read about and never need.

5.5 NAPTR and URI

NAPTR (naming authority pointer, RFC 3403, October 2002) is SRV with a regular expression engine bolted on. It maps a name to a service by rewriting it, and it exists mostly so that a telephone number can be turned into a SIP address:

$ dig +noall +answer sip2sip.info NAPTR
sip2sip.info.  3600  IN  NAPTR  25 100 "s" "SIPS+D2T" "" _sips._tcp.sip2sip.info.
sip2sip.info.   300  IN  NAPTR  20 100 "s" "SIP+D2U"  "" _sip._udp.sip2sip.info.
sip2sip.info.  3600  IN  NAPTR  10 100 "s" "SIP+D2T"  "" _sip._tcp.sip2sip.info.

The "s" flag means "the result is an SRV name, go and look that up next", which is why these three point straight at _sip._tcp and friends. If you are not building telephony infrastructure you will never write one.

URI (RFC 7553, June 2015) is the simpler idea that mostly did not catch on: publish a full URI, with priority and weight, at an underscore-prefixed name. It is the obvious way to say "the API for this domain is over there" and almost nobody does it.

5.6 Publishing Keys and Fingerprints

A family of record types exists for one reason: DNS is a directory every party already trusts to find you, so it is a natural place to publish "and here is what my key looks like, so you can tell a real one from a fake". They are only as trustworthy as the DNSSEC underneath them, which is why they cluster around it.

TLSA is the one with real deployment, because mail between servers had no other way to insist on encryption. Here is FreeBSD's mail server publishing its own certificate association:

$ dig +noall +answer _25._tcp.mx1.freebsd.org TLSA
_25._tcp.mx1.freebsd.org. 3600 IN TLSA 3 1 1
    0A7E2F469913EA64CA98AF1F31BBBCAF51920D8DF90D2972A9DC02BF7C37F404

The name encodes the port and protocol, the same underscore convention as SRV. The three numbers say which kind of certificate this is, what part of it was hashed, and which hash. A sending server that finds this record and validates it knows it is talking to the real FreeBSD mail server, not a machine that intercepted the connection. That guarantee is only worth anything if the record itself is signed, which is exactly why DANE and DNSSEC are always mentioned together.

SSHFP solves the small daily annoyance of SSH's first-connection prompt, where the honest answer to "are you sure you want to continue connecting?" is that you have no way to be sure. Publish the fingerprint and the client can check:

$ dig +short SSHFP anonscm.debian.org
cgi-grnet-01.debian.org.
4 1 4A6C5668982EE0601D8AA97D2DCA32C3BF148116

5.7 The DNSSEC Set

DNSSEC signs the records in a zone so a validating resolver can prove an answer came from you and was not modified on the way. It uses eight record types, and you will rarely create any of them by hand - a competent DNS provider generates them - but you will see them and you need to know which one lives where.

The chain in one command. The root vouches for .nl with a DS record:

$ dig +noall +answer nl. DS @a.root-servers.net
nl.  86400  IN  DS  17153 13 2
    C5DFDDC91E7532562A35F3C2CD30823894BE08F20101F1ABF45C8AB9739F3F49

And .nl publishes the key that hash refers to. Note the 257 on the third line: that flag marks the key-signing key, the one the DS above is a hash of. The 256 keys are zone-signing keys, rotated far more often.

$ dig +noall +answer nl. DNSKEY @ns1.dns.nl
nl.  3600  IN  DNSKEY  256 3 13 ArhUNmeRU9NE4fAbORd6DjntZ0vDP3PoQotzRxGg/...
nl.  3600  IN  DNSKEY  256 3 13 ObMZD0WbONw5/xzfY63W7kn4yVhtYwgu7pjE9L4T...
nl.  3600  IN  DNSKEY  257 3 13 aeDdFmc/JLPyva7Y4bS2SFbfWmxaiSrnqwgs+D1P...

Every signed answer carries its signature alongside it, with a validity window you can read:

$ dig +noall +answer +dnssec nl. SOA @ns1.dns.nl
nl.  3600  IN  SOA    ns1.dns.nl. dns.sidn.nl. 2026083114 3600 600 1209600 600
nl.  3600  IN  RRSIG  SOA 13 1 3600 20260928000023 20260831050721 467 nl. 4Lkw...
                                    |              |
                                    |              └─ signed on 31 Aug 2026
                                    └─────────────── expires 28 Sep 2026

That expiry date is the whole risk of DNSSEC in one field. Signatures are not permanent. If the machine that re-signs the zone stops running and nobody notices, your domain does not degrade gracefully - it vanishes for every validating resolver on the date in that field, and it looks perfectly healthy when you query the authoritative server directly.

The last piece is the strangest. DNSSEC has to prove that a name does not exist, without signing an infinite number of non-existent names in advance. The answer is to sign the gaps. Ask .nl for a name that is not there and it returns NSEC3 records saying "between these two hashed names there is nothing":

$ dig +noall +authority +dnssec zzzznotexist.nl @ns1.dns.nl
nl.  600  IN  SOA  ns1.dns.nl. dns.sidn.nl. 2026083114 3600 600 1209600 600
k36vo59bkum4osckkrd8tvibdgr0njbc.nl. 600 IN NSEC3 1 0 0 -
    K36VONMLM2T8IF3G8P5AV864OHLTB7K7 NS SOA TXT RRSIG DNSKEY NSEC3PARAM
7nch1gp6se37vhes4101tma9pdr0cm05.nl. 600 IN NSEC3 1 0 0 -
    7NCHAQDNOK5JC77VF6M30VKE5K771FH5 NS

The names are hashed for a reason. The original NSEC design named the real neighbours in plain text, which meant anyone could walk a zone from one denial to the next and enumerate every name in it. NSEC3 hashes them so the walk yields hashes instead. The trailing list - NS SOA TXT RRSIG DNSKEY NSEC3PARAM - is the set of types that do exist at that name, which is how a resolver proves "this name exists but has no MX" as distinct from "this name does not exist".

Should you sign? If your DNS provider handles the whole lifecycle including key rollovers, and pushing the DS record to your registrar is a button rather than a support ticket, turn it on. If signing would be a manual job you perform once and never revisit, the risk is real. The common middle state - zone signed, DS record never published at the registrar - achieves nothing and nobody notices, because everything keeps working.

5.8 The Ones You Query With, Not Store

Several entries in the register are not records at all. They are QTYPEs or pseudo-records: things that appear in a question or in the transport, never in a zone file. Confusing the two categories is why people go looking for a "record type OPT" in a control panel.

5.9 Curiosities and Fossils

The rest of the register is a museum, and it is a genuinely interesting one because each entry is a snapshot of what somebody thought the internet was going to be.

LOC (RFC 1876, January 1996) puts latitude, longitude and altitude in DNS. A handful of organisations still publish one:

$ dig +short LOC caida.org
32 53 1.000 N 117 14 25.000 W 107.00m 30m 10m 10m

That reads as 32 degrees 53 minutes north, 117 degrees 14 minutes west, 107 metres above sea level, with a 30 metre accuracy claim. It is San Diego, and it has been sitting in that zone for years doing nothing at all.

Nothing is ever removed from the register, only marked. A code point that was handed out in 1987 stays handed out, because somewhere there is still an implementation that would misread a reused number.

7. Something Most Users Do Not Know

7.1 SPF Had Its Own Record Type, and Lost It

In 2006 SPF was given type number 99, entirely to itself. Publishing your sender policy as a TXT record was supposed to be the temporary arrangement while the world caught up.

The world did not catch up. Eight years later, RFC 7208 (April 2014) deprecated the dedicated type and made TXT the only correct place. The reason is worth sitting with, because it is the strongest argument in this whole article about how infrastructure actually changes: control panels did not offer the new type, libraries did not query for it, and a sender that had to check both types was doing twice the work for zero benefit. The purpose-built record lost to the general-purpose one on deployment alone.

That is why DKIM, DMARC, MTA-STS, BIMI and every site-verification scheme since have all been built on TXT without even asking for a number. The lesson stuck.

7.2 A TXT Record Cannot Hold More Than 255 Characters at a Time

RFC 1035 stores text as a character-string: one length byte followed by that many characters. One byte, so 255 characters maximum. Anything longer has to be split into several strings inside the same record, and the reader is expected to glue them back together.

You can see it happen with any 2048-bit DKIM key, which does not fit:

$ dig +short TXT google._domainkey.nlnetlabs.nl
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhfvuanQm2k...
 ...UiaUufabV/EMRD7xp5GhE6arl3inx7B65gOifz" "Mg241EQM6bliIlt6Q8wTanhA8kbz...
 ...ryGX9X7msJ+v9xYEybiPZyGwnhnI6LMewcHzxtK4LFoYTrb0NOSK+tueth4Vhdz1TBbFw...

Look for the " " in the middle. That is not a typo and it is not a space in the key - it is the boundary between two 255-character strings inside one record, and a verifier concatenates them with nothing in between.

This is the source of a specific and maddening bug. Some control panels split a long key for you correctly. Some refuse it. Some accept it and silently insert a space at the join, which produces a key that is one character wrong and a DKIM check that fails with no useful message. If a long TXT record does not validate, look at the join before you look at anything else.

7.3 ANY Is Answered With a Shrug

Every DNS tutorial older than about 2019 suggests dig example.com ANY to see everything at once. Try it on a large domain today and you will get one record, or a truncation, or a polite refusal.

RFC 8482 (January 2019) is titled "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", and it exists because ANY was the perfect amplification weapon. A tiny question produced an enormous answer, and UDP does not verify who asked, so an attacker could forge a victim's address as the source and have name servers all over the world flood them with large responses.

Servers are now free to answer ANY with whatever they feel like. The practical consequence is that you must ask for the types you want, one at a time. It is more typing and it never lies to you.

7.4 A Wildcard Is a Name, Not a Type, and It Matches Less Than You Think

People talk about "a wildcard record" as though * were a type. It is not: it is a label in the name, and any type can sit on it.

*.example.com.      300   IN   A       203.0.113.10

Two surprises follow from RFC 4592 (July 2006). First, a wildcard does not match the name it sits under: the record above answers for anything.example.com and not for example.com. Second, and much less known, it stops matching as soon as any name exists below it. If a.b.example.com is defined, then b.example.com now exists as a node in the tree, and a query for other.b.example.com returns NXDOMAIN rather than falling through to the wildcard. One unrelated record can silently switch the wildcard off for a whole branch.

Third, the type matters. A wildcard A record does not cover an MX query. The answer to "does anything.example.com have an MX record" is a clean no, even with the wildcard above in place.

Wildcards also change the meaning of your zone in ways people do not intend. Every typo resolves. Every subdomain an attacker invents resolves. Monitoring that checks "does this name exist" always says yes. Use one when you genuinely serve unlimited names, such as customer subdomains on a platform. Otherwise list the names you actually have.

7.5 The Apex Problem Is Finally Being Fixed by a Record Type

For thirty years the answer to "why can I not put a CNAME on my bare domain" has been an explanation followed by a workaround. ALIAS, ANAME and flattening are all one provider's private solution to a problem the standard created.

SVCB in AliasMode is the first standardised fix. It carries an alias, it is allowed at the apex because it is not a CNAME and does not exclude its neighbours, and every resolver can be taught it because RFC 3597 already lets them carry types they do not understand. It is not deployed everywhere yet. But this is the first time in three decades that the answer is a standard rather than a provider feature, and it is worth knowing which way the wind is blowing before you pick a DNS host on the strength of its ALIAS support.

7.6 The Serial Number Can Take Your Zone Offline Without Changing a Record

The SOA serial is how secondary servers decide whether to pull a fresh copy: higher means newer. It is a 32-bit number that wraps around, compared using serial number arithmetic, and the practical rule is that it must only ever go up.

Set it backwards - by restoring an old zone file, by switching from a date-based scheme to a counter, by importing a zone into a new provider that starts at 1 - and every secondary concludes it already has something newer and stops transferring. The primary is correct, the secondaries are stale, nothing reports an error, and the two answer differently depending on which one a resolver happens to ask. It is the purest example of a DNS failure that is invisible from the place you would naturally look.

7.7 Two New Record Types Were Registered This Month

DNS is forty-two years old and the register is still moving. On 20 August 2026 two entries appeared, UNECE (69) and ISO (70), for carrying values coded according to an external standards body's registry rather than one invented for DNS.

Look at the recent additions together and the direction is clear. RESINFO (2024) lets a resolver describe its own capabilities. WALLET (2024) publishes a cryptocurrency address. DSYNC (2025) tells a child zone where to send notifications about its own delegation. HHIT and BRID (2025) identify drones. CLA and IPN are drafts for the Bundle Protocol, which is the networking used for space communication where round trips are measured in minutes.

DNS stopped being only a directory of web servers a long time ago. It is now the internet's general-purpose place to publish a small, signed, globally readable fact about a name you control - and that, rather than address lookup, is what the last twenty years of new record types have all been about.

7.8 The 13 Root Servers Are 13 Addresses, Not 13 Machines

Everyone learns that DNS has thirteen root servers, named a through m. That is true, and it leads to two wrong conclusions: that thirteen computers hold up the internet, and that they are mostly in the United States. Both are decades out of date, and you can disprove them from your own terminal.

Every root server answers a special query in the CH class that reveals which physical instance you actually reached. Ask all thirteen:

$ for L in a b c d e f g h i j k l m; do
      printf '%-22s ' "$L.root-servers.net"
      dig @$L.root-servers.net hostname.bind CH TXT +short
  done

Run from a machine in the Netherlands on 31 August 2026, that gives:

Not one of them is in the United States. Eleven answered from Europe, most within 20 milliseconds. The thirteen names are not thirteen machines; they are thirteen addresses, and each address is announced from many locations at once using anycast. The network routes you to whichever copy is nearest along its own paths, without you or your resolver knowing it happened.

The two outliers are the interesting part. From Amsterdam, b answered from Singapore and i from Jakarta, roughly twenty times slower than their neighbours. Anycast follows routing, not geography, and those two identities simply have no European instance that this network's path prefers. It is a useful reminder that "the nearest server" is a claim about BGP rather than about maps.

According to IANA's own list, the thirteen identities are run by twelve organisations, and between them they operate well over a thousand instances worldwide; root-servers.org publishes the current count. The number thirteen is a limit from 1987 on how many name servers fit in a single UDP packet, not a count of computers.

The same trick is what any competent DNS provider sells you, and it is the main reason to use one rather than running your own name server on a single machine. Your two NS records look like two servers and are really two addresses announced from dozens of sites, so a visitor in Sydney and a visitor in Rotterdam both get a nearby answer, and losing a data centre changes nothing.

7.9 You Do Not Own Your Domain

You rent it, in fixed terms, and the lease is the single point of failure most people never think about. Every record type in this article assumes the delegation still exists.

What actually goes wrong is unglamorous: the card on file expires, the renewal notice goes to a colleague who left, the domain was registered in a personal account belonging to a freelancer three agencies ago. The recovery, once a domain has lapsed and been picked up by somebody else, ranges from expensive to impossible.

Three habits remove most of that risk:

• Registrar lock switched on, so a transfer cannot be initiated quietly.
• Auto-renew on, with a payment method that outlives individual employees, and the registrant email pointed at a role address rather than a person.
• Expiry monitoring that is not the registrar's own email. If the account details are wrong, the reminders go to the wrong place, which is precisely the case you are trying to catch.

7.10 NXDOMAIN Does Not Mean What Your Monitoring Thinks

Every answer carries a response code, and four of them account for almost everything you will see. They are in the header, not the records, and dig prints them on the status: line.

The distinction that catches people is between NXDOMAIN and NODATA. NODATA is not a response code; it is NOERROR with an empty answer section, and RFC 2308 (March 1998) defines it that way. It means the name exists, but not with the type you asked for:

$ dig +noall +comments petermartin.nl TLSA @chelsea.ns.cloudflare.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56610
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
                                # the name is fine; it has no TLSA record

Now the part almost nobody knows, measured on 31 August 2026. Ask the authoritative server for a name that genuinely does not exist and you get NXDOMAIN. Ask any of the three big public resolvers the same question and you get NOERROR:

$ for R in chelsea.ns.cloudflare.com 1.1.1.1 8.8.8.8 9.9.9.9; do
      printf '%-26s ' "$R"
      dig +noall +comments zzznotexist.petermartin.nl A @$R | grep -oE 'status: [A-Z]+'
  done
chelsea.ns.cloudflare.com  status: NXDOMAIN
1.1.1.1                    status: NOERROR
8.8.8.8                    status: NOERROR
9.9.9.9                    status: NOERROR

The resolvers are not broken and the zone is not misconfigured. The proof of non-existence explains it:

$ dig +noall +authority +dnssec zzznotexist.petermartin.nl A @1.1.1.1
zzznotexist.petermartin.nl. 1800 IN NSEC \000.zzznotexist.petermartin.nl. RRSIG NSEC TYPE128

That TYPE128 is NXNAME, number 128 in the register in section 6.3, defined by RFC 9824 (September 2025) for compact denial of existence. Instead of maintaining a real chain of NSEC records, the server synthesises one for the exact name asked about and puts NXNAME in its type list to mean "and this name is not really here". It is cheaper to sign on the fly, and it stops a zone being walked.

The side effect is that the answer looks like NODATA to anything that does not understand NXNAME, and the resolver passes that on. Note also that dig prints TYPE128 rather than the mnemonic: this build does not know the name yet, and it is carrying the record correctly anyway. That is RFC 3597 from section 6.2, working exactly as designed, in live output.

Testing the same five zones showed the split cleanly: the four using compact denial returned NOERROR from every resolver, and nlnetlabs.nl, which still publishes a classic NSEC chain, returned NXDOMAIN from all of them. The practical warning: a monitoring check that alerts on NXDOMAIN will stay silent for a name that does not exist. Check the answer count, not the response code. I keep a self-hosted Uptime Kuma watching uptime and certificate expiry across my own and client domains, and this is the section that sent me back through its DNS checks. If yours alerts on the response code, it will stay quiet through exactly the failure it was added to catch.

7.11 Split Horizon: The Same Name, Two Answers

Some organisations answer differently for the same name depending on who is asking: a private address on the office network, a public one from outside. This is split horizon, also called split DNS or split view, and it is a legitimate design rather than a misconfiguration.

inside the office     app.example.com  →  10.10.0.20
from the internet     app.example.com  →  203.0.113.20

It is also a trap for whoever debugs it later, because two people running the same command in good faith get different answers and each concludes the other is confused. If you run split horizon, document it where the person on call will find it, and expect every external DNS checking tool to disagree with what you see at your desk.

7.12 Your Resolver Probably Does Not Tell the Root What You Asked

In the original design, a resolver looking up secret-project.internal.example.com sent that whole name to a root server, then to the registry, then to the authoritative server. Only the last one needed it. The other two learned a name they had no business knowing, and the root sees a large share of the world's queries.

QNAME minimisation, standardised in RFC 9156 (November 2021), fixes it: the resolver asks each level only the part it needs to return a referral. The root is asked about com., the registry about example.com., and only your own name servers ever see the full name.

Two things follow. As a domain owner, your authoritative servers are the only place a complete query name appears, which makes their query logs more sensitive than people assume. And as someone reading a +trace, the queries you see are deliberately shorter than the name you asked for, which is a feature and not a bug in the tool.

7.13 Knowing Where the Record Types Stop

Part of expertise is knowing which layer a problem belongs to. DNS answers exactly one question: what does this name map to? Everything a visitor experiences after that belongs to something else.

The fifth row is the one worth internalising. When a page takes four seconds to load, the name was resolved in the first few milliseconds and everything after that was somebody else's problem.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Forgetting the trailing dot in a zone file. example.com without it becomes example.com.example.com. Control panels usually add it for you; zone files never do.
• Putting a CNAME next to another record. It is not allowed at any name, not only the apex. If www is a CNAME, it can have no TXT, no MX and no A.
• Pointing an MX at a CNAME or at an IP address. Both are forbidden, both appear to work with some senders, and both fail with the strict ones you cannot afford to lose.
• Publishing an AAAA record you do not actually serve on. The site works for most people and hangs for everyone with working IPv6, which is the hardest class of bug to be told about.
• Chaining CNAME records three deep. Every hop is another lookup on a cold cache. It works and it is slow.
• Letting a long TXT record be split with a space inserted at the join. The key is then one character wrong, and DKIM fails with no useful error.
• More than ten include: lookups in an SPF record. The specification caps it, and over the limit the result is a permanent error rather than a pass.
• Setting DMARC to p=reject on day one. Start at p=none and read the reports, or find out which systems send as you by watching their mail disappear.
• Leaving an A record pointing at a server you released. When somebody else is allocated that address, your subdomain is serving their content.
• Letting the SOA serial go backwards. Secondaries stop transferring, nothing reports an error, and two servers answer differently for the same name.
• Assuming the TTL you set is the TTL in use. A resolver was handed the previous value and keeps it for the full term. Your new short TTL only applies after the old one expires.
• Signing with DNSSEC and never publishing the DS record at the registrar. Everything keeps working and you have gained nothing, which is why this half-finished state can persist for years.
• Leaving an AXFR open to the world. A zone transfer hands over every name you have, which is a free map of your infrastructure.
• Keeping every record at a 60 second TTL permanently. Low TTLs are a migration tool, not a virtue. Held forever they multiply your query volume, remove the cache that keeps you reachable during a name server outage, and buy nothing on the days you change nothing.
• Moving DNS provider with DNSSEC still enabled. The old DS record stays at the registrar, the new provider signs with different keys, and every validating resolver returns SERVFAIL. The domain does not resolve at all, and the authoritative server looks perfectly healthy. Remove the DS, wait out its TTL, migrate, then sign again.
• Migrating only the A record. Inventory the whole zone first. The records people forget are MX, DKIM selectors, DMARC, CAA and the service verification TXT records, and each of them breaks something that is not the website.
• Alerting on NXDOMAIN to detect a missing name. With compact denial of existence, a name that does not exist now returns NOERROR through every major resolver. Check that the answer section is empty instead.
• Blocking TCP on port 53. Once a zone is signed or carries long TXT records, answers exceed what UDP can deliver and the retry over TCP is not optional. The failures are intermittent, which makes them expensive to diagnose.
• An MX pointing at a host that stopped answering. Worse than having no MX, because nothing rejects anything: senders queue for four or five days and only then bounce. Connect to port 25 and look for a 220 banner; a hang means every message to your domain is stuck in a queue somewhere.
• Leaving a domain that receives no mail with no MX record. Senders fall back to the A record and offer mail to your web server. Publish a null MX (0 .) instead and they fail immediately.
• Concluding a provider does not support a record because its form rejected it. Control panel fields are validated more narrowly than the DNS. If the form refuses a legal record, try the zone file importer or the API, then confirm against the authoritative servers rather than against the screen.
• Publishing v=spf1 -all on a domain whose website still sends. A contact form mailing you from an address at that domain is sending, and -all plus p=reject is an instruction to throw it away.
• Letting glue records go stale. If your name servers live inside your own domain, their addresses are also published by the registry. Change the address in your zone only and the world keeps using the old one.
• Believing your own browser. Browser caches, operating system caches and browser-level encrypted DNS all sit between you and reality. Check from another network before you conclude anything.