The namespace & delegation

A DNS name is a list of labels. In www.example.com the labels are www, example and com. Each label names one node of the tree, and the list is written from the leaf up to the top: the most specific label on the left, the most general on the right. The dots are only how people write the list down; they are separators, not part of any label.

There is one more label in every name, and you rarely see it. The top of the tree, the root, has a name too: the empty label, a label with nothing in it. Written out in full, the name is www.example.com., with a dot at the end, and the empty space after that dot is the root. A name written all the way to the root is a fully qualified domain name, or FQDN. It says exactly where the node sits, with nothing left for software to guess.

Most of the time you leave that last dot off and nothing goes wrong, because browsers and resolvers assume you meant the full name. But inside a zone file, and in some tools, the dot is load-bearing. Write mail.example.com without it in a zone file for example.com and the server appends the zone's own name, giving you mail.example.com.example.com. instead. That one missing dot is behind a surprising share of broken mail setups. On your own computer, a name with no dot at the end can also be expanded by a search list, which Chapter 10 covers.

Names are matched without regard to case. WWW.Example.COM and www.example.com are the same name, and a server must treat them as the same (RFC 4343). But the rule is narrow: it applies to the ASCII letters A to Z only, and a server is supposed to preserve the case you sent when it echoes the name back. Bytes outside ASCII are compared exactly as they are, which is one reason internationalized names are not sent as raw Unicode, as you will see below.

That last line is how the name actually travels. There are no dots in a DNS message. Each label is sent as one byte giving its length, followed by that many bytes of label, and the name ends with a zero-length label: a single zero byte, the root. This is where the two famous limits come from. A label's length has to fit in that one length byte, and the top two bits of it are reserved (they mark the compression pointers of Chapter 2), which leaves six bits: at most 63. And a whole name, length bytes and final zero included, may be at most 255 bytes. Because of the length bytes, the longest name you can type is shorter: 253 characters, without the trailing dot.

There are two different sets of rules for what can go in a label, and they are often confused. The DNS itself is permissive. RFC 2181 §11 says it plainly: the length limits are the only restriction the DNS places on a label, and any byte value at all may appear. The protocol is a database of byte strings, and it does not care what the bytes mean.

Host names are stricter, because they were written into older software long before DNS existed. The rule usually called LDH, letters, digits and hyphen, comes from the host tables of the early ARPANET (RFC 952) and was relaxed slightly by RFC 1123 §2.1: a label may contain the ASCII letters a to z (either case), the digits 0 to 9 and the hyphen, may start with a digit, but may not start or end with a hyphen. A name that will be typed into a browser, used for a mail server or put in a certificate is expected to follow it.

So a label like my_server is perfectly legal DNS and an illegal host name. That gap is exactly what the underscore labels exploit. Because no host can ever be called _dmarc or _tcp, those labels can be used to hang records on a name for a purpose, without any chance of colliding with a real machine. SRV records live at names like _sip._tcp.example.com (RFC 2782), DMARC policy at _dmarc.example.com, and DKIM keys under _domainkey. Chapter 5 and Chapter 8 use them.

Most of the world does not write in ASCII, and people reasonably want names in their own scripts. The DNS could carry the UTF-8 bytes of bücher without complaint, but almost nothing else could: host-name checks in software would reject it, case-insensitive matching only knows A to Z, and a single Unicode letter can be written as more than one byte sequence. The solution standardized as IDNA leaves the DNS alone and changes the names instead. Every non-ASCII label is converted, in the application, into an ASCII label that obeys the host-name rule, and that is what goes into zone files and DNS messages.

The two forms have names. The Unicode form that people read is the U-label: bücher. The ASCII form that the DNS carries is the A-label: xn--bcher-kva. The prefix xn-- is the ACE prefix, short for ASCII-compatible encoding, and it tells software that what follows is encoded (RFC 5890). The encoding itself is Punycode, defined in RFC 3492. Your browser's address bar shows you the U-label; the DNS only ever sees the A-label.

Punycode is short because it is clever. It copies all the plain ASCII letters first, in order, then a hyphen, then a compact series of instructions that say which Unicode characters to insert and where. Here is the whole thing for bücher, German for "books":

1. Copy the basic letters: bcher. Five characters, then a separator hyphen.
2. One character is left, ü, which is code point U+00FC, decimal 252. The encoder walks upward from 128, the first non-ASCII code point. To reach 252 it must step over 252 − 128 = 124 values, and at each value it considers all 6 possible insertion places in a 5-letter string, so 124 × 6 = 744. Then ü goes in at position 1, after the b: one more step. The single number to encode is 745.
3. 745 is written as a variable-length number in base 36 using the letters a to z and digits 0 to 9, with thresholds that adapt as the encoder goes. With the starting settings it comes out as three digits: k, v, a.
4. Add the prefix: xn--bcher-kva. Thirteen ASCII characters, every one of them legal in a host name.

The dissector above shows the same trace for whatever you type. Try 日本語.example, where there are no basic letters at all, so there is no hyphen and the A-label is xn--wgv71a119e.

One warning belongs here, and its defenses belong in Chapter 13. Many scripts contain letters that look exactly like Latin ones: the Cyrillic а is not the Latin a, but on screen they are identical. A name built from look-alikes is a homograph, and it can be used to imitate a familiar brand. Browsers defend against this by showing the raw xn-- form when a label mixes scripts in a suspicious way, and registries restrict which characters they will accept. It is a reason to be glad the A-label exists: it never lies about which characters are really there.

If one organization had to answer for the entire tree, DNS would never have scaled. The trick is delegation: any node can hand everything beneath it to someone else. The point where that happens is a zone cut, and the pieces between cuts are zones. A zone starts at a node called its apex, includes the nodes below it, and stops at every cut where a child has been delegated away (RFC 1034 §4.2, RFC 9499).

That is why a domain and a zone differ. The domain example.com is the whole subtree. The zone example.com is the part of that subtree that the example.com servers answer for. Delegate shop.example.com to a different team and the domain does not change at all, but the zone shrinks.

A cut is made of NS records, and it is visible from both sides. In the parent zone, the cut is a set of NS records at the child's name, saying which servers to ask. Those records are a signpost. The parent is not authoritative for them: it is passing on what the child told it, and a parent's server marks its answer as a referral, not as an authoritative answer. In the child zone, the same NS records appear at the apex, together with an SOA record, and here they are the real, authoritative data. When the two copies disagree, the child's is the truth, and the mismatch is a classic source of hard-to-find failures.

What "authoritative" means is simply this: a server is authoritative for a name when it holds the zone that contains it, from the zone's own source of truth, rather than from a cache or a signpost. Only an authoritative server sets the AA (authoritative answer) bit in a reply.

Look at the additional section of the first answer. The servers for shop.example.com are named ns1.shop.example.com and ns2.shop.example.com: they live inside the zone they serve. To find their addresses you would have to ask them, which you cannot do without their addresses. The parent breaks the loop by carrying copies of those addresses alongside the delegation. Those copies are called glue. This chapter only needs the rule: if a zone's name servers sit inside that zone, the parent must hold glue. How resolvers use glue, and why they must not trust it too far, is Chapter 3.

Delegation answers the technical question of who answers for a name. There is a parallel, human question: who decides who gets which delegation? The answer is a chain of organizations, one per level near the top of the tree.

The root zone is the short list of every top-level domain and the servers for each. Changes to it go through the IANA functions, which have been performed since the 2016 stewardship transition by Public Technical Identifiers (PTI), an affiliate of ICANN. When a TLD operator wants to change its name servers, it files a request with IANA, which checks it; the root zone maintainer, Verisign, then edits the zone, signs it and publishes it to the root server operators (Chapter 9). The root zone does not hold a single second-level name. It knows only about TLDs.

Top-level domains come in kinds. Country-code TLDs (ccTLDs) are two letters taken from the ISO 3166-1 list of country codes, like .uk, .de and .jp, and each country's operator sets its own rules. Generic TLDs (gTLDs) include the originals, .com, .net, .org, and the hundreds of new gTLDs, such as .nyc, added through ICANN's program that opened in 2012. Generic registries operate under contracts with ICANN. There is also .arpa, kept for infrastructure such as reverse DNS.

Below the TLD, three roles split the work:

• The registry runs the TLD: its database of registrations and its zone. Verisign is the registry for .com; every TLD has exactly one registry.
• The registrar is the company you actually deal with. It sells you the name, collects your details and sends the registry your changes. For gTLDs, registrars are accredited by ICANN, and many registrars sell names in the same TLD.
• The registrant is you: the person or organization that holds the registration and decides where it points.

Registrars talk to registries in the Extensible Provisioning Protocol, EPP, an XML protocol for creating, renewing and changing domain objects (RFC 5730). Your contact details live in the registry's and registrar's databases, published through WHOIS and its successor RDAP. They are not in the DNS. What actually lands in the TLD zone when you register a name is tiny: your NS records, glue if your servers sit inside your own domain, and a DS record if you sign your zone with DNSSEC (Chapter 11). Everything else about your name lives on the servers those NS records point to.

Some names are kept out of the market so that documentation, test networks and other naming systems have somewhere safe to live. RFC 6761 set up a registry of these special-use domain names, kept by IANA, and for each entry it records how every kind of software should treat it: users, applications, stub resolvers, caching resolvers, authoritative servers and registries. The point is that these names should be handled close to home and should not be sent up the tree. None of the special top-level names is delegated in the root zone, so even when a query does leak upward, the root answers that the name does not exist.

The registry also covers reverse-DNS zones for private address space, such as 10.in-addr.arpa and 168.192.in-addr.arpa, so that lookups for private addresses are answered locally instead of flooding public servers. Chapter 7 explains those names. This site uses only reserved names, the documentation addresses 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 and 2001:db8::/32, and public names like jelia.nyc, for exactly the reasons this registry exists.

Here is a question the DNS cannot answer: is co.uk a company's name, or a place where many companies register names? Both example.com and co.uk are two labels long and both are just nodes in the tree. Nothing in a DNS answer says "anyone can register beneath me". Browsers badly need to know, because cookies are scoped by domain. If a site at shop.example.co.uk could set a cookie for all of co.uk, it could read or plant cookies on thousands of unrelated businesses.

The Public Suffix List fills that gap. It is a plain text file, started by Mozilla and now kept as a community resource, that lists every known suffix under which the public can register names: com, co.uk, pvt.k12.ma.us, and thousands more. It has two sections: an ICANN section for suffixes run by registries, and a private section where companies list suffixes they hand out to customers, such as github.io, so that one customer's site cannot set cookies for another's.

The list gives rise to the idea of a registrable domain: one label plus the public suffix, like example.co.uk. Browsers use it for cookie boundaries and for deciding what counts as the "same site"; certificate authorities and mail software use it too. But it is not a DNS concept. It does not line up with zones (co.uk and uk may or may not be separate zones; the list does not care), it is not published in the DNS, and it changes on its own schedule. When a tool tells you the "domain" of a.b.example.co.uk is example.co.uk, it is reading this list, not asking the DNS.