2. The namespace

The namespace is a tree, and almost every rule about DNS is a rule about reading that tree correctly.

                          "" (root)
                           │
        ┌──────────┬───────┴───┬──────────┐
       com        org         uk         arpa
        │          │        ┌──┴──┐        │
    example    wikipedia   co    ac     in-addr
        │                   │              │
   ┌────┴────┐             bbc            192
  www      mail                            │
                                          0
   READ A NAME RIGHT TO LEFT:
   www.example.com.
    │     │      │ └ the root, as an empty
    │     │      │   label
    │     │      └── a TLD
    │     └───────── a second-level domain
    └─────────────── a host, or anything

Labels

   A LABEL
     1–63 octets
     a FULL NAME: ≤255 octets on the wire,
       including length bytes and the root
     up to 127 labels in theory

   ON THE WIRE a name is length-prefixed
   labels, terminated by a zero:

     3 w w w 7 e x a m p l e 3 c o m 0

The 255-octet limit is a real operational constraint, not trivia: it is why deeply nested Kubernetes service names or long auto-generated subdomains occasionally fail to resolve while shorter ones work, and the failure is a FORMERR or a truncated name rather than anything helpful.

The trailing dot

   example.com.     a FULLY QUALIFIED name.
                    absolute. the final dot
                    IS the root label.

   example.com      RELATIVE — unless the
                    context says otherwise.
                    a stub resolver may
                    append a search domain.

cat /etc/resolv.conf
dig +search example      # honours `search`
dig example.com.         # absolute, no search

In a zone file the distinction is sharp and unforgiving: www IN A 1.2.3.4 means www.example.com., and www.example.com IN A 1.2.3.4 — missing the trailing dot — means www.example.com.example.com.. That single omitted character is one of the most common zone-file bugs in existence, and it produces a record that exists, resolves, and is simply the wrong name.

Caution

The same trap appears in CNAME and MX targets. MX 10 mail.example.com inside example.com’s zone file creates a mail route to mail.example.com.example.com., which does not exist, so mail bounces with a resolution failure that looks nothing like a typo.

Case, and what “case-insensitive” means

   COMPARISON is case-insensitive:
     Example.COM == example.com

   TRANSMISSION preserves case:
     a server echoes back the case you sent

   THIS IS DELIBERATE, AND IT BECAME A
   SECURITY FEATURE:

   DNS 0x20 ENCODING
     a resolver sends wWw.eXaMpLe.cOm and
     checks the reply echoes exactly that
     pattern. an off-path attacker
     guessing a response must also guess
     the capitalisation — ~2^n extra bits
     of entropy for an n-letter name.

Only ASCII letters are case-folded, which matters for the next section: anything non-ASCII is compared byte for byte.

Internationalised names

   DNS CARRIES OCTETS, AND THE PROTOCOL
   NEVER LEARNED UNICODE.

   münchen.de
     → IDNA: normalise, then Punycode
     → xn--mnchen-3ya.de
     → that is what goes on the wire

   THE LABEL PREFIX IS ALWAYS `xn--`.

idn2 münchen.de
dig +short xn--mnchen-3ya.de
python3 -c "print('münchen.de'.encode('idna'))"

The security consequence is homograph attacks: аpple.com with a Cyrillic а is a completely different name that renders identically. Browsers defend with mixed-script heuristics and by showing Punycode when a label mixes scripts, which is why a suspicious domain sometimes appears in the address bar as xn--80ak6aa92e.com.

What a zone is

This is the concept people most often have wrong, because “domain” and “zone” are used interchangeably in casual speech and are not the same thing.

   A DOMAIN is a subtree of the namespace.
   example.com is a domain, and so is
   everything under it, forever.

   A ZONE is the part of that subtree one
   operator actually SERVES — down to the
   next delegation.

   example.com ZONE
     example.com.        SOA, NS, A, MX
     www.example.com.    A
     mail.example.com.   A
     eu.example.com.     NS  ← DELEGATION.
                             the zone ENDS
                             here.

   eu.example.com ZONE  (different servers,
                         possibly a different
                         team or company)
     eu.example.com.     SOA, NS, A
     shop.eu.example.com. A

   SO: the example.com ZONE does NOT
   contain shop.eu.example.com, even
   though the example.com DOMAIN does.

Every zone has exactly one SOA record at its apex, and that is the practical test: a zone starts at an SOA and ends at each delegation below it.

dig +short example.com SOA
dig +norecurse @a.gtld-servers.net example.com   # see the referral itself

The zone cut

   AT A DELEGATION THE SAME NS RECORDS
   EXIST TWICE, IN TWO DIFFERENT ZONES.

   in the PARENT (com):
     example.com. NS ns1.example.com.
     → NOT authoritative. a referral.
       `dig` shows no `aa` flag.

   in the CHILD (example.com):
     example.com. NS ns1.example.com.
     → AUTHORITATIVE.

   THEY SHOULD MATCH. WHEN THEY DO NOT,
   you get intermittent failures that
   depend entirely on which resolver asked
   whom, and which one's cache expired
   first.

A mismatch between parent and child NS sets is one of the classic latent DNS faults: everything works, for months, until a resolver happens to refresh from the parent and lands on a nameserver that was decommissioned.

Glue

   example.com. NS ns1.example.com.

   TO ASK ns1.example.com YOU NEED ITS
   ADDRESS.
   TO GET ITS ADDRESS YOU MUST ASK
   example.com.
   WHICH YOU CANNOT REACH. ← a cycle

   SO THE PARENT SHIPS AN ADDRESS RECORD
   IT IS NOT AUTHORITATIVE FOR:

     example.com.     NS ns1.example.com.
     ns1.example.com. A  192.0.2.1   ← GLUE

Glue is required only when the nameserver’s name is inside the zone it serves (ns1.example.com serving example.com). Using out-of-zone nameservers — ns1.provider.net — avoids the problem entirely, which is one reason every managed DNS provider does exactly that.

dig +norecurse @a.gtld-servers.net example.com NS
# look at the ADDITIONAL section: that is the glue

Glue lives at the registrar, not in your zone file, which is why updating an in-zone nameserver’s IP requires two changes in two different systems — and why forgetting the registrar half is a reliable outage.

Wildcards

   *.example.com. IN A 192.0.2.99

   MATCHES: anything.example.com,
            whatever.example.com
   DOES NOT MATCH:
     example.com itself (the apex)
     a.b.example.com, IF b.example.com
       exists as a node
     any name that EXISTS with any record
       of any type

   THE RULE THAT SURPRISES PEOPLE

   creating www.example.com MX stops the
   wildcard from answering www.example.com A.
   the name now EXISTS, so the wildcard no
   longer applies to it — and you get
   NODATA instead of the wildcard's address.

dig +short anything.example.com
dig +short www.example.com          # may differ, if www exists

Wildcards are genuinely useful for multi-tenant systems where every customer gets a subdomain, and they are a trap in zones with a few explicit records, because the interaction above is invisible until somebody adds an unrelated record type.

Empty non-terminals

   IF a.b.c.example.com EXISTS, THEN
   b.c.example.com AND c.example.com EXIST
   TOO — with no records.

   SO ASKING FOR c.example.com RETURNS
   NOERROR WITH ZERO ANSWERS (NODATA),
   NOT NXDOMAIN.

This matters for anything that treats NXDOMAIN as “nothing here”: an empty non-terminal is a real node in the tree with no data, and the distinction is exactly the one chapter 1 drew. It also matters for DNSSEC, where empty non-terminals must still be provable.

Names that are special

   .arpa          infrastructure. reverse
                  DNS lives here:
                  in-addr.arpa (IPv4),
                  ip6.arpa (IPv6)

   .local         mDNS / Bonjour. NEVER use
                  it for unicast DNS.
   .localhost     always 127.0.0.1
   .invalid       guaranteed never to exist
   .example       reserved for documentation
   .test          reserved for testing
   .onion         Tor. resolved outside DNS.
   .home.arpa     the correct choice for a
                  home or lab network

   .internal      delegated in 2024 as the
                  reserved private-use TLD.
                  use this, not .corp or
                  .lan.

Note

.corp, .home and .mail were widely used on internal networks and are permanently blocked from the root for exactly that reason — ICANN found that delegating them would break thousands of networks whose queries leak to the public internet. .internal and .home.arpa are the sanctioned choices, and a private zone under a domain you actually own is better than both.

Where a name may legally appear

Not every record may point at any name, and the restrictions are the source of several persistent misconfigurations.

   MUST BE A HOSTNAME WITH A/AAAA RECORDS,
   NEVER A CNAME, NEVER AN IP ADDRESS

     MX targets
     NS targets
     SRV targets
     the SOA's MNAME

   MAY BE A CNAME
     anything a browser or ordinary client
     resolves: www, api, a CDN hostname

   MUST NOT COEXIST WITH A CNAME
     literally anything else at the same
     owner name

# a CNAME'd MX: resolvers tolerate it, senders often do not
dig +short example.com MX | while read -r p t; do
  dig +short "$t" CNAME | grep -q . && echo "BAD: $t is a CNAME"
done

The reason for the restriction is that these records are consumed during resolution itself, by code that must not recurse further. A resolver following a delegation cannot be asked to resolve a CNAME chain to find the nameserver, so RFC 2181 forbids it outright — and the failure when somebody does it anyway is partial, depending entirely on which implementation is reading.

Reverse DNS

   192.0.2.15  →  15.2.0.192.in-addr.arpa.
                  PTR mail.example.com.

   2001:db8::1 →  1.0.0.0.…(32 nibbles)…
                  .8.b.d.0.1.0.0.2.ip6.arpa.
                  PTR host.example.com.

   REVERSED BECAUSE DELEGATION GOES RIGHT
   TO LEFT, AND ADDRESSES ARE ALLOCATED
   LEFT TO RIGHT. reversing the octets
   makes the allocation hierarchy line up
   with the DNS hierarchy.

dig -x 192.0.2.15
dig -x 2001:db8::1

Reverse DNS is delegated by whoever owns the address block, which means you cannot set your own PTR record unless your provider delegates the block or offers an interface. It matters almost exclusively for mail: a sending IP without matching forward and reverse records is treated as suspicious by essentially every large mail receiver.

What to take from this chapter

• A name is labels read right to left, each 1–63 octets, with the whole name capped at 255 octets on the wire — a limit real enough to break long generated subdomains.
• The trailing dot makes a name absolute. In a zone file, omitting it on www.example.com silently creates www.example.com.example.com., which resolves and is wrong. The same trap applies to MX and CNAME targets.
• Comparison is case-insensitive but transmission preserves case, which DNS 0x20 turns into extra entropy against off-path spoofing.
• Non-ASCII names are Punycode (xn--) on the wire, and homograph attacks are the consequence browsers defend against by displaying the encoded form.
• A domain is a subtree; a zone is what one operator serves. A zone begins at an SOA and ends at every delegation below it.
• At a zone cut the same NS set exists in both parent and child. A mismatch is a classic latent fault — everything works until a resolver refreshes from the parent.
• Glue is an address record the parent serves for a nameserver named inside the zone it serves. It lives at the registrar, so changing an in-zone nameserver’s IP needs two changes in two systems. Out-of-zone nameservers avoid the problem.
• .local is mDNS and must never be used for unicast DNS. .internal and .home.arpa are the sanctioned private names; .corp, .home and .mail are permanently blocked because so many networks leaked them.
• Reverse DNS reverses the address because delegation runs right to left. You usually cannot set your own PTR, and mismatched forward/reverse records are a mail-delivery problem specifically.

Next: the architecture — stub, recursive and authoritative, what each actually does, and the root servers that are not thirteen machines.