How DNS resolution works

When you type a name into a browser, a resolver (usually your provider's or a public one such as 1.1.1.1) turns it into an address by walking a hierarchy.

1. The resolver asks a root server where .uk lives. Root servers reply with the nameservers for the top-level domain.
2. It asks the .uk nameservers who is responsible for example.co.uk. They reply with the domain's delegated nameservers, the same list the registry publishes.
3. It asks one of those authoritative nameservers for the record it wants and receives an answer marked authoritative (the AA flag).
4. It caches the answer for the record's time to live (TTL) so the next question is answered instantly.

Why delegation and zone must agree

The parent (step 2) and the child zone (step 3) both hold an NS record set. Resolvers cache whichever they see first. When the two disagree, some users are sent to a server that does not carry the zone, which is the DNS-LAME-DELEGATION and DNS-NS-SET-MISMATCH findings on the DNS facet.

Recursive versus authoritative

An authoritative server knows the answer for its zones and nothing else. A recursive resolver knows nothing itself but will find out. Asking an authoritative server a question with recursion desired and getting a referral back is normal; that is what our per-nameserver check does.

What can go wrong

• A nameserver is down or lame, making resolution slow or flaky.
• Secondaries have not refreshed from the primary, so answers differ by server (DNS-SERIAL-MISMATCH).
• Caches still hold old records after a change; wait for the TTL to pass.
• A CNAME at the apex breaks the SOA and NS records that must live there.

The DNS facet on whois.me.uk queries the domain's nameservers individually, so you can see each of these directly.