No single DNS (Domain Name System) Domain Name System Translates a human-friendly name such as www.ietf.org into a network address. introduced in ch. 1 server holds all the mappings, so a lookup walks a hierarchy of servers — and caching is what stops that walk from happening nearly every time.
Words you will meet
- Root DNS server — a server at the top of the tree; it points to the servers for .com, .edu and the rest.
- TLD server — Top-Level Domain: knows who is in charge of every name ending in .com, .uk, and so on.
- Authoritative DNS server — holds the true records for one organisation’s own hosts.
- Local DNS server — the nearby server your machine asks first; it does the walking for you.
- Recursive query — “go and find the whole answer for me”.
- Iterative query — “I do not know, but ask them”; you do the walking.
- DNS caching — keeping a copy of an answer so the same question does not travel again.
Why this matters
This is the best worked example of a distributed database in the book. It is also one of the few pieces of Internet infrastructure run jointly by hundreds of thousands of organisations that have no reason to trust each other.
It is worth reading closely for a second reason. The design here — a hierarchy, delegation, caching at the edge — reappears whenever a system must scale beyond what one organisation can operate. Section 5.4 shows the same pressures shaping routing between ISPs.
Why not just one big server?
A simple design would put every mapping on one DNS server. Clients send all queries there and it answers directly. The simplicity is attractive.
It is also inappropriate for today’s Internet, and the book gives four reasons.
| What goes wrong | |
|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Four problems, and every one of them is fatal on its own.
In plain words
A centralized database in a single DNS server simply does not scale.
So DNS is distributed by design, and it is a wonderful example of how a distributed database can be implemented in the Internet. Every design choice in the rest of this section follows from the four failures above.
A distributed, hierarchical database
To deal with scale, DNS uses a large number of servers, organised hierarchically and distributed around the world. No single DNS server has all the mappings. Instead the mappings are spread across them.
To a first approximation there are three classes of DNS server.
Hover a link to see its rate, delay and length.
Three levels. Each one knows only how to point you at the next, and none of them knows the whole database.
Read this diagram as text
- Root DNS servers — wired link — com
- Root DNS servers — wired link — org
- Root DNS servers — wired link — edu
- com — wired link — facebook.com
- com — wired link — amazon.com
- org — wired link — pbs.org
- edu — wired link — nyu.edu
- edu — wired link — umass.edu
Suppose a client wants the address of www.amazon.com. It first contacts a root
server, which returns addresses for the TLD servers for com. It contacts one of
those, which returns the address of an authoritative server for amazon.com.
Finally it contacts that server, which returns the address for
www.amazon.com.
Root DNS servers
There are more than 1000 root server instances scattered all over the world. They are the top of the tree, and everything below them is organised by TLD (Top-Level Domain) Top-Level Domain The last label of a hostname — com, edu, uk — and the DNS servers responsible for it. introduced in ch. 2 . These are copies of 13 different root servers, managed by 12 different organizations, and coordinated through the Internet Assigned Numbers Authority root dns server Simple A server at the top of the DNS tree. It points to the servers for .com, .edu and the rest. Precise There are more than 1000 root server instances scattered all over the world, copies of 13 different root servers managed by 12 organizations and coordinated through IANA. Root name servers provide the IP addresses of the TLD servers. Because local servers cache TLD addresses, root servers are bypassed for all but a very small fraction of queries. introduced in ch. 2 — open in glossary ( IANA (Internet Assigned Numbers Authority) Internet Assigned Numbers Authority Coordinates the DNS root servers and publishes the well-known port numbers. introduced in ch. 2 ). Root name servers provide the IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 addresses of the TLD servers.
The book’s figure shades countries into four bands and publishes no per-country counts. This redrawing keeps the bands that are legible in the printed figure and places each territory as one square rather than tracing a coastline — a page scan is not a good enough source for borders, and a map that is subtly wrong is worse than one that is obviously schematic. Treat it as showing the pattern, not a census.
Every territory, as text
- Brazil — 21+ servers
- Canada — 21+ servers
- Germany — 21+ servers
- India — 21+ servers
- Netherlands — 21+ servers
- United States — 21+ servers
- Argentina — 11–20 servers
- Australia — 11–20 servers
- China — 11–20 servers
- France — 11–20 servers
- Italy — 11–20 servers
- Japan — 11–20 servers
- Russia — 11–20 servers
- South Africa — 11–20 servers
- Spain — 11–20 servers
- Sweden — 11–20 servers
- Switzerland — 11–20 servers
- United Kingdom — 11–20 servers
- Chile — 1–10 servers
- Colombia — 1–10 servers
- Egypt — 1–10 servers
- Finland — 1–10 servers
- Iceland — 1–10 servers
- Indonesia — 1–10 servers
- Kenya — 1–10 servers
- Mexico — 1–10 servers
- Morocco — 1–10 servers
- New Zealand — 1–10 servers
- Nigeria — 1–10 servers
- Norway — 1–10 servers
- Peru — 1–10 servers
- Poland — 1–10 servers
- Saudi Arabia — 1–10 servers
- South Korea — 1–10 servers
- Thailand — 1–10 servers
- Turkey — 1–10 servers
- Ukraine — 1–10 servers
- Vietnam — 1–10 servers
- Algeria — 0 servers
- Angola — 0 servers
- Chad — 0 servers
- Kazakhstan — 0 servers
- Mongolia — 0 servers
Click a band in the key to isolate it. The lesson is the “0 servers” band: this is infrastructure for the whole world, and large parts of the world have none of it locally.
Top-level domain servers
Every top-level domain has a
TLD server top-level domain server Simple A server that knows who is in charge of every name ending in .com, .edu, .uk and so on. Precise For each top-level domain — com, org, net, edu, gov, and country domains such as uk, fr, ca and jp — there is a TLD server or server cluster. Verisign Global Registry Services maintains the com TLD servers and Educause maintains the edu TLD servers. TLD servers provide the IP addresses of authoritative DNS servers.
introduced in ch. 2 — open in glossary
, or a server cluster. That
covers com, org, net, edu and gov, and every country domain such as
uk, fr, ca and jp.
Verisign Global Registry Services maintains the TLD servers for com, and
Educause maintains those for edu. The network infrastructure supporting a TLD
can be large and complex. TLD servers provide the IP addresses of authoritative
DNS servers.
Authoritative DNS servers
Every organization with publicly accessible hosts — web servers, mail servers — must provide publicly accessible DNS records mapping those names to IP addresses. An organization’s authoritative DNS server authoritative dns server Simple The server holding the true records for one organisation’s own hosts. Precise The DNS server that houses an organization’s publicly accessible DNS records, mapping the names of its hosts to IP addresses. Every organization with publicly accessible hosts must provide such records, either from a server it runs itself or from one operated by a service provider. Most universities and large companies run their own primary and secondary authoritative servers. introduced in ch. 2 — open in glossary houses those records.
It can run its own, or pay to have the records stored in a service provider’s server. Most universities and large companies implement and maintain their own primary and secondary authoritative servers, the second being a backup.
The local DNS server, which is not in the hierarchy at all
There is a fourth kind, and it does not strictly belong to the hierarchy — yet it is central to the architecture.
Each ISP (Internet Service Provider) Internet Service Provider Connects hosts, and other ISPs, to the rest of the Internet. introduced in ch. 1 , residential or institutional, has a local DNS server local dns server Simple The nearby server your machine asks first. It does the running around for you. Precise Also called a default name server. It does not strictly belong to the hierarchy of DNS servers but is central to the DNS architecture. Each ISP has one, and a host learns its address when it connects, typically through DHCP. It sits close to the host: often on the same LAN, or a few routers away. It acts as a proxy, forwarding the host’s query into the DNS hierarchy and caching what comes back. introduced in ch. 2 — open in glossary , also called a default name server. When a host connects to an ISP, the ISP provides it with the addresses of one or more of them, typically through DHCP (Dynamic Host Configuration Protocol) Dynamic Host Configuration Protocol Gives a host its IP address and the address of its local DNS server when it joins a network. Built properly in §4.3.2. introduced in ch. 2 , which chapter 4 covers.
A host’s local DNS server is typically close to it. For an institutional ISP it may be on the same LAN (Local Area Network) Local Area Network A network covering one building, campus or home. introduced in ch. 1 ; for a residential ISP it is usually separated by no more than a few routers. When a host makes a query, that query goes to the local server, which acts as a proxy and forwards it into the hierarchy.
Four kinds of server, and only three own anything
Root, TLD and authoritative servers hold records. A local DNS server holds none — it is authoritative for nothing at all.
What it does instead is ask on your behalf, and remember the answers. That is why it can be central to the architecture without being part of the hierarchy, and why the next two sections are entirely about it.
Walking the hierarchy
Suppose the host cse.nyu.edu wants the IP address of gaia.cs.umass.edu.
NYU’s local DNS server is dns.nyu.edu, and an authoritative server for the
target is dns.umass.edu.
Click any arrow to see what that message says and why it is sent.
Eight messages to answer one question. Click any arrow to see who is asking whom, and what comes back.
Read this diagram as text
- cse.nyu.edu sends 1 — where is gaia.cs.umass.edu? to dns.nyu.edu. This one query is RECURSIVE: it asks the local server to obtain the mapping on the host’s behalf. The host will now do nothing until the answer arrives. Everything that follows happens without it.
- dns.nyu.edu sends 2 — where is gaia.cs.umass.edu? to root. The local DNS server forwards the query into the hierarchy, starting at the top.
- root sends 3 — ask the edu TLD servers to dns.nyu.edu. The root server takes note of the edu suffix and returns a list of IP addresses for the TLD servers responsible for edu. It does not chase the answer itself — that is what makes this reply ITERATIVE.
- dns.nyu.edu sends 4 — where is gaia.cs.umass.edu? to edu TLD.
- edu TLD sends 5 — ask dns.umass.edu to dns.nyu.edu. The TLD server takes note of the umass.edu suffix and responds with the address of the authoritative DNS server for the university.
- dns.nyu.edu sends 6 — where is gaia.cs.umass.edu? to dns.umass.edu.
- dns.umass.edu sends 7 — it is at 128.119.245.12 to dns.nyu.edu. The authoritative server actually holds the record, so this reply is the real answer rather than another referral.
- dns.nyu.edu sends 8 — it is at 128.119.245.12 to cse.nyu.edu. The host gets one answer to one question. From its point of view DNS took two messages. Six more happened that it never saw.
Lifelines, left to right: cse.nyu.edu (host), dns.nyu.edu (server), root (server), edu TLD (server), dns.umass.edu (server).
Count the messages
To obtain the mapping for one hostname, eight DNS messages were sent: four query messages and four reply messages.
Hold on to that number. It is the cost of a lookup with nothing cached, and the rest of this section is about how rarely that cost is actually paid.
When the TLD server does not know
The example assumed the TLD server knows the authoritative server. In general that is not always true. The TLD server may know only an intermediate DNS server, which in turn knows the authoritative one.
Suppose the University of Massachusetts has a server dns.umass.edu for the
university, and each department has its own authoritative server. When
dns.umass.edu receives a query for a host ending cs.umass.edu, it returns the
address of dns.cs.umass.edu, which is authoritative for that department. The
local server then queries that one.
In this case a total of 10 DNS messages are sent.
Recursive and iterative
The chain above uses both kinds of query.
Click any arrow to see what that message says and why it is sent.
Still eight messages, but notice the shape: the query travels all the way down, and the answer climbs all the way back.
Read this diagram as text
- cse.nyu.edu sends 1 — find it for me to dns.nyu.edu.
- dns.nyu.edu sends 2 — find it for me to root.
- root sends 3 — find it for me to edu TLD. This is the difference. In the iterative pattern the root replied with a referral. Here it takes on the work and asks the TLD server itself.
- edu TLD sends 4 — find it for me to dns.umass.edu.
- dns.umass.edu sends 5 — 128.119.245.12 to edu TLD.
- edu TLD sends 6 — 128.119.245.12 to root.
- root sends 7 — 128.119.245.12 to dns.nyu.edu.
- dns.nyu.edu sends 8 — 128.119.245.12 to cse.nyu.edu. The host sees exactly what it saw before. The difference is entirely in who carried the load: here the root and TLD servers did work on someone else’s behalf, which is why in practice they refuse to.
Lifelines, left to right: cse.nyu.edu (host), dns.nyu.edu (server), root (server), edu TLD (server), dns.umass.edu (server).
| Recursive"find it for me" | Iterative"I do not know, ask them" | |
|---|---|---|
| Who does the work? | ||
| What comes back? | ||
| Where it is used in practice | ||
| Effect on the server asked |
Cells marked ⓘ have a reason behind them — click to read it.
In theory any DNS query can be either. In practice the split is fixed.
In plain words
In theory any DNS query can be iterative or recursive. In practice the pattern is always the same one:
- the query from the requesting host to its local DNS server is a recursive query recursive query Simple A query that asks the server to go and find the whole answer for you. Precise A DNS query that asks the contacted server to obtain the mapping on the querying party’s behalf. In theory any DNS query can be recursive or iterative; in practice the query from a requesting host to its local DNS server is recursive. introduced in ch. 2 — open in glossary ;
- the remaining ones are iterative queries iterative query Simple A query answered with “I do not know, but ask them”. You do the walking. Precise A DNS query whose reply is returned directly to the querying server, typically naming the next server to ask rather than giving the final answer. In practice the queries from a local DNS server up the hierarchy are iterative. introduced in ch. 2 — open in glossary .
The reason is load. A recursive query obliges the server to keep working until it has an answer. A root server that accepted recursive queries from the whole Internet would be doing everyone’s work at once.
DNS caching
Everything so far has ignored DNS caching dns caching Simple Keeping a copy of an answer, so the same question does not have to travel again. Precise The feature by which a DNS server stores a mapping in its local memory when a reply arrives. It can then answer later queries for the same hostname even though it is not authoritative for it. Because hostname-to-address mappings are not permanent, cached information is discarded after a period, often two days. introduced in ch. 2 — open in glossary , and it is critically important. It is what makes the delay tolerable, and what stops DNS messages ricocheting around the Internet.
The idea is simple. In a query chain, when a DNS server receives a reply it can store the mapping in its local memory. If another query arrives for the same hostname, it can supply the address immediately — even if it is not authoritative for that hostname.
Worked example — the second person to ask
The host apricot.nyu.edu asks dns.nyu.edu for the address of cnn.com. That
costs the full walk.
A few hours later another NYU host, kiwi.nyu.edu, asks the same server for the
same name. Because of caching, the local server returns the address
immediately, without querying any other DNS server.
Eight messages became zero.
Because hosts and their mappings are by no means permanent, DNS servers discard cached information after a period, often set to two days.
Caching is also why the root servers survive
A local DNS server can cache the addresses of TLD servers as well as ordinary mappings. That lets it skip the root entirely and go straight to the TLD level.
There are only a few hundred top-level domains, so those addresses are looked up once and reused constantly. The consequence is striking:
Because of caching, root servers are bypassed for all but a very small fraction of DNS queries.
The 13 root servers are the most critical machines in this design, and almost nobody talks to them.
Check yourself
Check yourself
0 of 7 answered1.A single DNS server holding every mapping would be simple. The book gives four reasons it cannot work. Which is NOT one of them?
2.predictIn the iterative ladder, how many DNS messages are exchanged to resolve one hostname, and how do they divide?
3.In the common pattern, which query is recursive and which are iterative?
Recursive means "go and find the whole answer for me".
4.The local DNS server is described as central to the DNS architecture, yet not part of the hierarchy. How can both be true?
5.A host asks its local DNS server for cnn.com. A few hours later a different host on the same network asks for the same name. What happens?
6.Why are the root servers contacted for only a very small fraction of DNS queries?
7.The book notes a case where 10 DNS messages are needed instead of 8. What causes the extra pair?
What to remember
- Three classes of server hold records: root (points at TLD servers), TLD (points at authoritative servers), authoritative (holds an organisation’s own). No single server has all the mappings.
- The local DNS server is authoritative for nothing and is not in the hierarchy, yet every host asks it first. It acts as a proxy and caches.
- Caching turns a cold lookup’s eight messages into zero for the next person to ask. TLD addresses are cached too, so root servers are bypassed for all but a very small fraction of queries.