Concepts / Names and DNS

Names and DNS

Authoritative server

Also called DNS hierarchy, root server, TLD, referral, delegation, NS record, glue, zone

A DNS server that holds a zone's records and answers for them with the aa flag.

For names it has delegated, it answers with a referral: the NS records of the child zone and, when needed, their addresses (glue). The root delegates lab, lab delegates example.lab, and so on down.

How the DNS hierarchy works, step by step

A domain is a name and everything under it; a zone is the part of it one set of servers answers for. lab is a domain that contains example.lab, but once example.lab is delegated, it is a separate zone. In the DNS tree lab rootServer (10.0.2.10) holds the root zone, labServer (10.0.2.11, ns.lab) holds lab, and exampleServer (10.0.2.12, ns.example.lab) holds example.lab. All three run BIND with recursion no: they answer only from their own zone files.

  1. The child zone is set up first. Its file starts with an SOA (primary server, contact, serial, timers) and the NS records naming its servers. These apex records are authoritative in the child.
  2. The parent delegates. lab's zone gets example.lab. NS ns.example.lab.. This copy of the NS record is not authoritative: it is a signpost, and the parent answers it without the aa flag.
  3. The parent adds glue. ns.example.lab lies inside the zone it serves, so nobody could look it up without first reaching it. The parent therefore also carries its address, ns.example.lab. A 10.0.2.12. A server named outside the zone (ns1.provider.net) needs no glue; it is found by a separate lookup.
  4. A resolver follows the signposts. The root answers a question about www.example.lab with a referral to lab, ns.lab with a referral to example.lab, each with glue in the additional section. ns.example.lab answers with aa set.
  5. Copies stay in step. Real zones have two or more servers. Secondaries copy the zone from the primary by zone transfer (AXFR, or IXFR for changes) when the SOA serial rises, prompted by NOTIFY or the refresh timer. To a client, a secondary is just as authoritative; the zones and encrypted DNS lab runs one.

On the internet the root zone is served under 13 names, a to m.root-servers.net, each anycast from many sites. A registrar sends your NS records and any glue to the TLD registry, which puts them in the TLD zone. Root and TLD delegations usually carry a TTL of two days.

What it looks like on a Linux machine

dig +norecurse @server asks one server what it knows, as a resolver does. ns.lab refers on, with glue:

$ dig +norecurse @10.0.2.11 www.example.lab
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; AUTHORITY SECTION:
example.lab.		60	IN	NS	ns.example.lab.

;; ADDITIONAL SECTION:
ns.example.lab.		60	IN	A	10.0.2.12

No aa, no answer: a referral. The server one rung down answers with authority:

$ dig +norecurse @10.0.2.12 www.example.lab
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; ANSWER SECTION:
www.example.lab.	60	IN	A	10.0.2.13

Asked for a name outside its zones, an authoritative-only server refuses, and dig notices the missing ra:

$ dig @10.0.2.12 www.elsewhere.lab
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 56207
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

A missing name comes back NXDOMAIN with the zone's SOA, from the server responsible for where it would be: example.lab. 60 IN SOA ns.example.lab. hostmaster.example.lab. 1 3600 600 86400 60. dig +trace www.example.lab does the whole walk and names each server in a Received … from 10.0.2.10#53(a.root-servers.net) line.

What goes wrong, and how you see it

Wrong glue. The parent hands out an address where nothing answers. The resolver follows it, times out and answers SERVFAIL after a long wait. Walking the tree finds it: ns.lab's referral says ns.example.lab. 60 IN A 10.0.2.99 while the real server is 10.0.2.12. Fix the parent's zone, then flush the resolver's cached referral (unbound-control flush_zone lab).

Lame delegation. The parent names a server that answers but does not hold the zone. It replies REFUSED, or without aa, and resolvers give up on it. Every server listed in the parent's NS set must load the zone.

Parent and child disagree. The child's apex NS set lists servers the parent does not, or the reverse. Compare dig +norecurse @10.0.2.11 NS example.lab with dig @10.0.2.12 NS example.lab.

A secondary falls behind. The zone was edited without raising the serial, or the primary refuses the transfer (Transfer status: REFUSED in the secondary's log). The two servers give different answers until the secondary copies again, or until the SOA expire time, when it stops answering for the zone.

Questions people ask

What is the difference between a recursive and an authoritative DNS server? An authoritative server holds zones and answers only for them, with aa. A recursive resolver holds no zones; it asks authoritative servers on a client's behalf and caches what they say. Keep the roles on separate servers: an authoritative server that also recurses for anyone is an open resolver, the tool of DNS amplification.

What are glue records? Addresses of name servers that live inside the zone they serve, published by the parent so the delegation can be followed.

Are there really only 13 root servers? There are 13 server names and addresses, but each is anycast from many places, well over a thousand machines in all. See DNS for the full lookup.

See it on real machines

Learn it on real machines.

Every lab is a small network of real Linux machines in your browser. Start with a free account: Google or email, no card.

Open this lab