02 · Anatomy of a domain name

Take www.blog.your-website.com. It has four visible parts and one that is almost always left off. Knowing which part is which - and which organisation controls each - explains a surprising amount of DNS behaviour: why you cannot put a CNAME on the bare domain, why a cookie set on github.io would be a disaster, why whois asks a different server for .com than for .uk.

This is part two of the Learn DNS series. Part one covered why the system is a delegated tree; this one walks a single name down that tree.

Read it right to left

DNS names are written most-specific first, but they are resolved most-general first. The separators are dots, and each piece between dots is a label. Fully written out, every name ends in one more dot than you usually type:

www . blog . your-website . com .
 |     |         |           |    |
 |     |         |           |    → the root (empty label)
 |     |         |           → top-level domain
 |     |         → the registered name (the "apex")
 |     → a subdomain
 → a host under that subdomain

A name written with the trailing dot is a fully qualified domain name (FQDN) - absolute, no guessing. Without the dot it is technically relative, and software may append a search domain from your network config before resolving it. In DNS records and config files, always write the FQDN.

The root

The dot at the end is the root zone: the single node every name descends from. It is served by thirteen named authorities, a.root-servers.net through m.root-servers.net. "Thirteen" is a number of names, not machines - each name is anycast to hundreds of sites worldwide, so there are well over a thousand physical root servers. The root zone itself is tiny: it does nothing but point at the top-level domains. It is published by IANA (operated by ICANN affiliate PTI) under multi-stakeholder policy.

The top-level domain

The rightmost label - com, org, net, io, dev, uk. Broad categories:

• gTLDs - generic: the original com / org / net, plus hundreds added since 2013 (dev, app, xyz).
• ccTLDs - two-letter country codes: uk, de, jp. Each is run under its country's own rules.

Every TLD has one registry that operates its nameservers and holds its master database - Verisign for com, PIR for org, Nominet for uk. That split between registry, registrar and registrant is its own note: Registries and registrars.

The public suffix problem

"The TLD is one label" is not always true in practice. Under uk you do not register example.uk directly - you register example.co.uk, so the effective suffix is co.uk. Platforms do the same thing on purpose: your-project.github.io and your-app.pages.dev hand each customer a subdomain that must be treated as a separate site.

Browsers resolve this with the Public Suffix List (publicsuffix.org): a community-maintained list of "you cannot set a cookie this broad" boundaries. It is why a cookie on your-website.com can cover www.your-website.com, but a cookie on github.io is rejected - the browser knows github.io is a suffix, not a site. The label just below the public suffix, plus that suffix, is the registrable domain.

The apex

your-website.com - the registrable domain - goes by several names: apex, zone apex, root domain, naked or bare domain. This is the name you pay for, and the name where a zone's defining records live: its SOA and its NS set.

The apex has one well-known limitation: you cannot put a CNAME on it. A CNAME means "I have no other records, ask about that name instead", and the apex is required to hold SOA and NS - so the two conflict. This is why providers invent ALIAS / ANAME records or "CNAME flattening". That gets its own note later in the series.

Subdomains and hosts

Anything to the left of the apex - www, blog, api, mail, www.blog. There is nothing special about www; it is just a conventional label. A subdomain can be:

• records in the parent zone - api.your-website.com A 203.0.113.20 sits right in the your-website.com zone file. The common case.
• delegated - NS records hand eu.your-website.com to a different set of nameservers, making it its own zone with its own operator. Used by large organisations and by platforms.

Label rules

DNS itself is more permissive than the hostname rule - a TXT or SRV owner name can contain underscores, for instance (_dmarc.your-website.com, _sip._tcp.your-website.com). "Hostname" is the stricter subset used for names that resolve to addresses.

Zone vs domain

The two words are used loosely but mean different things. A domain is any node in the tree - com, your-website.com, and www.your-website.com are all domains. A zone is a contiguous chunk of the tree under one administrative control, starting at some domain and stopping wherever a child is delegated away. Each zone has exactly one SOA record at its top.

Usually your-website.com is a single zone that contains www, blog, mail and the rest directly. Delegate eu.your-website.com to another provider and you have created a second zone; the parent zone now just holds the NS records pointing at it.

See it with dig

# the apex's defining records
dig +short your-website.com SOA
dig +short your-website.com NS

# walk the delegation at every level: root → com → your zone
dig +trace www.your-website.com

# is a subdomain delegated, or just records in the parent?
# an NS answer here means it is its own zone
dig +short eu.your-website.com NS

The shape of it

• Names read right to left; every one ends at the root dot.
• Root → TLD → registrable domain (apex) → subdomains. Each boundary is a delegation to a different operator.
• The Public Suffix List is why "the TLD" is sometimes two labels (co.uk, github.io) and why it matters for cookies and certificates.
• The apex holds SOA and NS, which is why it cannot take a CNAME.
• A zone is the unit with one SOA; a domain is any node in the tree.

Next: Learn DNS 03 - How a DNS lookup works, step by step, which follows a single query from your keyboard to the authoritative answer.