When you look up a domain, the answer is not stored in one place, it is discovered by walking down a chain of authority that starts at the root of DNS. Understanding that walk, called delegation, is what turns "DNS is broken" into "the delegation for this domain is inconsistent, here is the exact hop that is wrong."
The chain of authority
A recursive trace follows the delegation step by step:
- Root servers (
.) do not know your domain, but they know who runs each top-level domain. They point to the TLD servers for.com,.org, your ccTLD, and so on. - TLD servers (for example the
.comservers) do not hold your records either, but they hold the delegation: the NS records naming your domain's authoritative nameservers. - Your authoritative nameservers hold the real answers, the A, MX, TXT, and other records for your zone.
Each level only knows enough to point at the next one. A recursive resolver repeats this walk (and caches each step) so that most lookups never touch the root at all. Our nameserver trace tool performs this walk for a domain and shows the delegation at each level.
Glue records: solving the chicken-and-egg problem
If your nameservers live inside the domain they serve, for example ns1.example.com is authoritative for example.com, there is a bootstrapping problem: to find example.com you need ns1.example.com, but to find ns1.example.com you need example.com. Glue records break the loop: the parent (.com) publishes the IP addresses of those in-zone nameservers directly in the delegation, so a resolver can reach them without a circular lookup. Missing glue is a classic cause of intermittent, hard-to-reproduce resolution failures.
What to look for in a trace
- Parent vs child NS agreement. The NS records the TLD hands out (the parent side) should match the NS records your own nameservers publish at the zone apex (the child side). A mismatch means a stale delegation.
- Lame delegation. A nameserver is listed in the delegation but does not actually answer authoritatively for the zone. Every listed server should respond with an authoritative answer.
- All nameservers reachable and consistent. If two of your four nameservers return different data, some users get stale answers depending on which one their resolver picked.
- SOA consistency. All authoritative servers for a zone should serve the same SOA serial once changes have propagated between them.
Why this matters for troubleshooting
Most "my change is not showing up" problems are really delegation or propagation problems. If the parent still points at your old DNS provider, no amount of editing records at the new provider will help, resolvers never reach the new servers. A trace makes that obvious at a glance: you see the delegation pointing to the wrong place.
# Walk the delegation yourself
dig +trace example.com
# Compare parent-side vs child-side NS
dig NS example.com @a.gtld-servers.net # parent (example: .com server)
dig NS example.com # child (your nameservers)
FAQ
What is the difference between a recursive resolver and an authoritative server?
An authoritative server holds the real records for a zone. A recursive resolver holds none of its own, it walks the delegation chain (and caches the results) to find answers on your behalf.
I switched DNS providers but nothing changed. Why?
Almost always because the delegation at the registrar/TLD still names your old nameservers. Update the NS records at your registrar, then re-run a trace to confirm the parent points to the new provider.
What is a lame delegation?
A nameserver listed in the delegation that fails to answer authoritatively for the zone. It causes slow, intermittent lookups as resolvers wait on a server that will not help.