Before we can understand how DNS queries work, we need to understand what DNS actually is. Not “it translates names to IP addresses” — you already know that. We’re going deeper.
DNS is a hierarchical, distributed naming system. Every word in that description matters. Let’s unpack it.
Names, Labels, and the Tree
A domain name like www.example.com isn’t just a string — it’s a path through a tree structure. Each segment separated by dots is called a label.
www.example.com
│ │ │
│ │ └── "com" (top-level domain label)
│ └────────── "example" (second-level domain label)
└────────────── "www" (third-level domain label)
Here’s the mind-bending part: the tree is read right to left. The root of the tree is an empty label at the far right (usually invisible). Then com, then example, then www. Each label is a branch leading to more specific nodes.
RFC 1034 §3.1 defines this structure formally:
“The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term ‘node’ to refer to both.”
Label Rules
Labels have constraints defined in RFC 1035:
- Length: Each label can be 1-63 characters
- Total name length: Maximum 253 characters (255 bytes in wire format, including length octets)
- Characters: Originally letters, digits, and hyphens (LDH rule). Internationalized domain names (IDN) extend this via Punycode encoding
- Case: DNS is case-insensitive.
EXAMPLE.COM,example.com, andExample.Comare identical
The tree structure allows for approximately 10^77 possible domain names — more than enough for the foreseeable future.
The Invisible Root
There’s a label you almost never see: the root. Every fully qualified domain name technically ends with a dot representing the root:
www.example.com.
^
└── The root (empty label)
This trailing dot is usually hidden by browsers and applications, but it’s always there logically. When you see www.example.com. with the trailing dot, that’s the Fully Qualified Domain Name (FQDN) — the complete, unambiguous path from the root to that specific node.
Why does this matter? In DNS configuration files (zone files), the trailing dot is critical:
; Without trailing dot — RELATIVE (will have zone origin appended)
www IN A 93.184.216.34
; With trailing dot — ABSOLUTE (FQDN, used as-is)
www.example.com. IN A 93.184.216.34
Forgetting the trailing dot in a zone file is one of the most common DNS configuration mistakes. We’ve all done it.
Domains vs Zones: The Critical Distinction
Here’s where many people get confused: domains and zones are not the same thing.
A Domain
A domain is a subtree of the DNS namespace. The domain example.com includes everything under it: www.example.com, mail.example.com, api.example.com, dev.api.example.com, and so on — the entire subtree.
A Zone
A zone is the portion of a domain that’s under a single administrative authority. It’s defined by what’s actually in a single authoritative database (zone file).
The key insight: delegation splits domains into multiple zones.
Consider example.com:
example.com (zone: administered by Example Inc.)
├── www.example.com (in the example.com zone)
├── mail.example.com (in the example.com zone)
└── api.example.com (DELEGATED — separate zone)
├── v1.api.example.com (in the api.example.com zone)
└── v2.api.example.com (in the api.example.com zone)
The domain example.com includes api.example.com and everything below it. But if Example Inc. delegates api.example.com to a separate team with their own nameservers, then api.example.com becomes a separate zone.
RFC 1034 §4.2 explains:
“The domain space is partitioned into areas called ‘zones’, each starting at a domain and extending downward to leaf domains or to domains where other zones start.”
Why This Matters
When you’re debugging DNS or configuring nameservers, understanding zones is essential:
- A zone file contains all records for a zone — not a domain
- A zone transfer copies zone data between servers
- Authoritative nameservers are authoritative for zones, not domains
- Delegation creates new zones from existing domains
Delegation: The Key to Scalability
Delegation is the mechanism that makes DNS distributed. It’s how the root zone hands off .com to Verisign, how Verisign hands off example.com to your registrar, and how you can hand off api.example.com to a different provider.
Delegation works through NS (nameserver) records:
; In the com. zone, delegating example.com to its nameservers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; Glue records — because ns1.example.com is within the delegated zone
ns1.example.com. IN A 192.0.2.1
ns2.example.com. IN A 192.0.2.2
Those NS records say: “Don’t ask me about anything under example.com — go ask these nameservers instead.”
Glue Records: Solving the Chicken-and-Egg
Notice something tricky? The NS record says the nameserver for example.com is ns1.example.com. But to find the IP address of ns1.example.com, you’d need to query the example.com zone. That’s a circular dependency.
Glue records solve this. They’re A/AAAA records included in the parent zone that provide the IP addresses of nameservers within the delegated zone. They “glue” the delegation together by providing the information needed to bootstrap the query.
Glue records are only required when nameservers are within the zone they’re authoritative for. If Example Inc. used ns1.cloudflare.com as their nameserver, no glue would be needed — cloudflare.com is a different zone with its own delegation chain.
Fully Qualified Domain Names (FQDNs)
An FQDN is a complete domain name that specifies the exact location in the DNS hierarchy, from a specific node all the way up to the root. It’s unambiguous.
www.example.com. ← FQDN (trailing dot = root)
www.example.com ← Usually treated as FQDN by applications
www ← Relative name (needs context)
In practice, most applications assume you mean an FQDN even without the trailing dot. But in DNS zone files and configurations, the distinction matters:
$ORIGIN example.com.
; "www" is relative — becomes www.example.com.
www IN A 93.184.216.34
; "mail.example.com." is absolute — used as-is
mail.example.com. IN A 93.184.216.35
; "other" without trailing dot — becomes other.example.com.
; "other." with trailing dot would be just "other." (probably wrong!)
The $ORIGIN directive sets the context for relative names. Any name not ending in a dot gets the origin appended.
The Complete Picture
Let’s put it all together. The DNS namespace is:
- A tree — hierarchical, with the root at the top and increasingly specific names as you descend
- Divided into zones — each zone is a contiguous portion under single administrative control
- Connected by delegation — NS records in parent zones point to authoritative servers for child zones
- Globally distributed — no single server holds all the data; each zone is served by its own authoritative servers
This architecture is what allows DNS to scale to handle the entire internet. No central database could handle the load or complexity. Instead, thousands of organizations each manage their own small piece of the namespace, and delegation ties it all together.
Key Takeaways
- Labels are the dot-separated components of a domain name (max 63 characters each)
- The root is an invisible empty label at the end of every FQDN
- Domains are subtrees; zones are administratively delegated portions of domains
- Delegation via NS records is how DNS distributes authority
- Glue records solve circular dependencies when nameservers are within their own zone
- FQDNs are absolute paths from root; trailing dots matter in zone files
Understanding these fundamentals is essential for everything that follows. Next, we’ll trace the complete journey of a DNS query from your keyboard to an IP address.