DNS: The Hierarchy and the Four Record Types

Why it is distributed, and why that is not optional#

People use names. Routers use addresses. Something has to map between them, and the obvious design — one big table on one big server — fails for four reasons, all of which are worth naming:

• A single point of failure. That server goes down and the entire Internet stops resolving names.
• Traffic volume. Every name lookup on Earth arriving at one machine.
• Distance. Whoever is furthest from it waits longest, on every lookup.
• Maintenance. One database holding every host on the Internet, edited by everyone.

DNS is also a good example of a theme worth carrying into later chapters: it is a core Internet function implemented at the application layer, at the edge of the network, rather than inside the core. Complexity is pushed to the edge wherever it can be.

Beyond name-to-address translation, DNS provides host aliasing (a memorable name pointing at an awkward canonical one), mail server aliasing (so mail to a domain reaches the right host), and load distribution (one name mapped to a set of addresses, handed out in rotation).

Vocabulary, before anything uses it#

The four kinds of server#

The local name server is the odd one out and gets asked about for that reason: it is not part of the hierarchy at all. Every ISP, company and university has one. When a host makes a query it goes there first. The local server keeps a cache of recent translations and acts as a proxy, forwarding into the hierarchy whatever it cannot answer.

There are 13 logical root servers worldwide, identified by letters. Each is not one machine but a large set of replicas, so the number describes addresses rather than boxes.

Iterative and recursive queries#

Both styles get the same answer. They differ in who does the walking.

In an iterative query, each contacted server that does not know the answer replies with a referral — the name of a server closer to it. The local name server then makes the next query itself, and the next, until it reaches the authoritative server. The work stays with the local server.

Iterative: “I do not know, but ask this server.”

In a recursive query, the contacted server takes on the job: it queries onward on your behalf and returns the finished answer. The burden moves up the hierarchy.

Recursive: “Wait there, I will find out.”

In practice the common arrangement is a mix: the host makes a recursive query to its local name server, and the local name server then makes iterative queries out into the hierarchy. That is deliberate, because the alternative concentrates load at the top — if every query to a root server were recursive, the roots would be resolving the whole Internet’s names.

Caching, TTL, and stale answers#

Once any name server learns a mapping, it caches it. This is what keeps the system usable: TLD server addresses end up cached in local name servers everywhere, so root servers are rarely contacted at all.

Cache entries expire after the TTL on the record. Until then, the cached answer is used without checking — which produces the one honest limitation of DNS worth stating in an answer:

That is also the practical reason a low TTL is set before a planned migration and raised again afterwards: TTL is the knob that trades lookup traffic against how fast a change propagates.

Resource records, and the field order that costs marks#

The DNS database stores resource records. Every one is the same four-field tuple:

(Name, Value, Type, TTL)

What Name and Value mean depends entirely on Type, which is why the type has to be decided first:

That last point generalises into a rule that makes these questions mechanical: any record whose value is a host name creates the need for an A record for that host name. NS and MX both have host-name values, so each of them drags an A record along behind it.

Getting a new domain into DNS#

A new organisation registers its domain name with a registrar, giving the names and addresses of its authoritative name servers. Two things then have to happen, in two different places, and keeping them separate is the whole skill:

1. At the parent TLD server, the registrar inserts the records that delegate the domain: an NS record naming the authoritative server, and an A record giving that server’s address so a resolver can actually reach it.
2. At the organisation’s own authoritative server, the organisation creates the records for its hosts: an A record for the web server, an MX record naming the mail exchanger for the domain, and an A record for that mail host.

Worked example#

Step 1 — Split the page in two before writing anything. Parent server on one side, authoritative server on the other. Every record has to be placed on one side or the other, and deciding that first prevents the classic mistake of putting host records at the parent.

Step 2 — At the parent, delegate and then make the delegation reachable. Which record delegates a domain to a name server? NS. Now, can a resolver contact ns1.redkite.example knowing only its name? No — so an A record has to come with it.

(redkite.example, ns1.redkite.example, NS, TTL)
(ns1.redkite.example, 10.20.0.2, A, TTL)

Step 3 — At the authoritative server, take the hosts one at a time. Web server: a name to an address, so A. Mail: which host accepts mail for the domain, so MX — and its value is a host name, which again drags an A record behind it.

(www.redkite.example, 10.20.0.5, A, TTL)
(redkite.example, mail.redkite.example, MX, TTL)
(mail.redkite.example, 10.20.0.9, A, TTL)

Step 4 — Walk a resolver through your own records. Start at the parent: the NS record names the server, the A record gives its address, so the resolver can get there. At that server, the A record answers a web lookup and the MX plus its A record answer a mail lookup. If the walk completes, the answer is right.

Practice#

Use a fictional domain of your own for the writing questions. Say the type out loud before you write each tuple.

1. Give the four reasons a single centralised DNS server would not work.
2. Which kind of name server is not part of the hierarchy, and what two jobs does it do?
3. State the difference between an iterative and a recursive query in one sentence about where the work sits.
4. Why is it normal for a host to query recursively but for its local server to query iteratively?
5. Write the four fields of a resource record in order, then say what Name and Value hold for each of A, NS, CNAME and MX.
6. A domain orchid.example is delegated to ns.orchid.example at 10.30.1.4. Write the records at the parent server.
7. The same organisation runs mail on smtp.orchid.example at 10.30.1.8. Write the records at its own server, and say why there are two.
8. Somebody writes (orchid.example, 10.30.1.8, MX, TTL). What is wrong with it?
9. A host changes its IP address and some users still reach the old one. Why, and when will it stop?
10. Which transport does a normal DNS query use, on which port, and when is the other one used instead?

Solutions#

1. It does not scale, for four reasons. A single point of failure; the traffic volume of every lookup on the Internet; the distance from a centralised database to most of the hosts querying it; and the maintenance burden of one database describing every host.
2. The local name server, which caches and forwards. The local, or default, name server. It does not strictly belong to the hierarchy. It keeps a cache of recent name-to-address translations, and it acts as a proxy, forwarding into the hierarchy any query it cannot answer.
3. Who chases the referrals. In an iterative query the contacted server returns a referral and the asking server makes the next query itself, so the work stays with the asker. In a recursive query the contacted server does the chasing and returns a finished answer, so the work moves to it.
4. It keeps load off the upper levels. The host offloads the work to its local server with one recursive query. The local server then queries iteratively so that the root and TLD servers only answer referrals rather than resolving names on behalf of the whole Internet, which would concentrate enormous load at the top of the hierarchy.
5. Name, Value, Type, TTL. A: Name is a host name, Value is an IP address. NS: Name is a domain, Value is the host name of an authoritative server for it. CNAME: Name is an alias, Value is the canonical host name. MX: Name is a domain, Value is the host name of its mail server.
6. An NS record and an A record. (orchid.example, ns.orchid.example, NS, TTL) and (ns.orchid.example, 10.30.1.4, A, TTL). The NS record delegates the domain; the A record is what lets a resolver actually reach the server it names.
7. An MX record and an A record. (orchid.example, smtp.orchid.example, MX, TTL) and (smtp.orchid.example, 10.30.1.8, A, TTL). Two records are needed because an MX value is a host name, not an address, so something still has to map that host name to an address.
8. An MX value must be a host name. The value of an MX record must be the host name of the mail server, not an IP address. It should name smtp.orchid.example, with a separate A record mapping that name to 10.30.1.8.
9. Cached records with unexpired TTLs. Name servers that learned the old mapping cached it, and a cached record is used without rechecking until its TTL expires. Those users will keep reaching the old address until every cached copy has aged out. This is why DNS is described as best-effort translation.
10. UDP on port 53, with TCP as fallback. A normal query uses UDP on port 53, because it is a single short request and a single short reply and the overhead of a connection would not be worth paying. TCP on the same port is used when a reply is too large for a single datagram, and for zone transfers between servers.

Test-readiness checklist#

• ☐  I can give all four reasons a centralised DNS would fail.
• ☐  I can name the four kinds of server and say what each knows.
• ☐  I can say why the local name server is the odd one out.
• ☐  I can distinguish iterative from recursive by where the work sits, not by message count.
• ☐  I can explain why the usual arrangement mixes the two.
• ☐  I can write the four record fields in order without hesitating.
• ☐  I can say what Name and Value hold for each of A, NS, CNAME and MX.
• ☐  I can place a record at the parent server or the authoritative server correctly, every time.
• ☐  I can remember that NS and MX each need an accompanying A record.
• ☐  I can explain a stale DNS answer in terms of TTL, and say when it resolves.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.