DNS is a tree of delegations: a root zone hands authority for each top-level domain to other servers, each of those hands authority for the domains below it, and a resolver finds an answer by following referrals down the tree. The tree works because everyone agrees which servers are the root, and that agreement was institutional, so a group of settlements must make its own: agree one top zone, delegate a sub-zone to each settlement, and tell every resolver where to start. With each level on a different server, looking up library.north.region.internal from an empty cache takes four queries.
Part of Networking
The structure of the name system as a chain of delegations, why its root is an agreement rather than a technology, and how a federation of settlements builds a private one.
Authority Is Delegated Downward, And The Top Is A Matter Of Agreement
Protocols describes the structure: the root zone, served by the root name servers; top-level domains served by their own name servers; and individual domains served by authoritative servers set up by the owner. A resolver with an empty cache asks the root, gets a referral to the top-level server, asks it, gets a referral to the authoritative server, and asks that for the answer. Delegation is the whole mechanism: a zone’s server holds a record that names the server responsible for each child zone, and that record is the referral.
Nothing in the software says which servers are the root. The software ships with a list of their addresses (general knowledge, not from the other articles), and everyone using the same list is what makes names mean the same thing everywhere. On the old internet a coordinating organisation decided who could run top-level domains and who could register names beneath them. That is an institutional arrangement, in the same way as the address registries (IP Addressing); it does not exist for a settlement, and it cannot be recovered by software. A federation of settlements has to do the same job by agreement among themselves.
What You Need
- An agreement among the settlements on the top zone name and who may add to it
- A name server in each settlement, ideally two (DNS)
- Two servers for the top zone, kept by people who answer to the whole federation
- A way to configure every resolver with where to start
Method: Build A Private Hierarchy
Step 1: Agree the name structure on paper For example a region zone, region.internal, with a sub-zone for each settlement: north.region.internal and south.region.internal. The suffix .internal is general knowledge for private use; the choice matters less than that everyone adopts the same.
Step 2: Run the region zone on its own servers It holds only the delegation records: for each settlement, the name of that settlement’s server and the server’s address (the parent must know the child’s server address as well as its name, which is known as glue and is general knowledge).
Step 3: Each settlement runs its own zone It holds that settlement’s names and is the authority for them (DNS Records shows what goes in).
Step 4: Tell every resolver where to start Either replace the root list with the federation’s top servers, or configure each settlement’s resolver to send queries for region.internal to the region servers (general knowledge: most resolver software supports both).
Step 5: Test from a cold cache A resolver that has never seen a name shows the full walk; a cached one hides faults.
Worked Example: Following A Lookup From The Top
South’s resolver looks up library.north.region.internal with an empty cache. Assume the root, internal, region.internal and north.region.internal are each on different servers.
| Query | Asked of | Reply |
|---|---|---|
| 1 | root server | referral to the servers for internal |
| 2 | internal server | referral to the servers for region.internal |
| 3 | region.internal server | referral to the servers for north.region.internal |
| 4 | north server | the address record for library |
Four queries, three referrals and one answer. Each referral is cached for its record’s time to live (Protocols), so a second lookup under north.region.internal from the same resolver goes straight to the north server: one query. If the hierarchy is shallower or one server holds several levels, fewer queries are needed; the table assumes the deepest case.
Contrast this with a flat arrangement in which every settlement’s resolver forwards all queries to one central server: one query for any name, but everything fails when that server does and the central operators must hold every settlement’s names. Delegation spreads the data and the failure.
Common Mistakes
- Two settlements inventing the same suffix independently — when they join, names clash exactly as overlapping address blocks do (Private Ranges); agree names before connecting
- A top zone run by one person on one machine — it is the single point of failure for all names; run two
- Forgetting that referrals are cached — moving a delegated server takes as long as the delegation record’s TTL to spread
- Letting resolvers keep the old root list when there is no outside network — they spend their time failing to reach it
What’s Next
- Learn next: DNS Records — what the servers actually hold
- Combine with: Certificate Authority — the other trust arrangement that needs an agreed top