DNS resolution sequence
Client query through recursive resolvers to authoritative nameservers.
Domain Name System (DNS) resolution is invisible until it breaks. This template maps out the entire path from your application sending a query to a recursive resolver through the global DNS hierarchy — root nameserver, TLD nameserver, and finally the authoritative nameserver that holds the answer.
Understanding this sequence is critical for debugging slow lookups, DNSSEC validation issues, and zone delegation problems. The diagram shows exactly which party is responsible at each hop, making it easy to spot where a failure could occur and who to contact to fix it.
When to use this template
- Onboarding infrastructure engineers — DNS feels like magic until someone walks through each question and answer. This diagram makes the chain of trust explicit.
- Debugging DNS failures — a slow lookup or a "Name Not Found" error happened at one of these hops. Knowing which party controls which step lets you narrow the culprit fast.
- DNSSEC and security audits — when you need to explain where signature validation fits in the resolution chain, this template shows the moments at which an attacker could intervene.
How to adapt it
Rename the generic nameserver roles to your specific setup, then layer in your production details:
- Add a local DNS cache decision diamond before the resolver query — if cached, skip straight to returning the IP.
- Insert DNSSEC validation steps after each nameserver response to show cryptographic verification.
- Replace the single authoritative nameserver with a secondary nameserver showing replication and failover behavior.
Visual edits regenerate clean Mermaid code, so you can map your exact DNS architecture and paste the result straight into your infrastructure docs.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
actor Client
participant Resolver as Recursive Resolver
participant Root as Root Nameserver
participant TLD as TLD Nameserver
participant Auth as Authoritative NS
Client->>Resolver: Query example.com
Resolver->>Root: Where is .com?
Root-->>Resolver: Ask TLD nameserver
Resolver->>TLD: Where is example.com?
TLD-->>Resolver: Ask authoritative NS
Resolver->>Auth: Where is example.com?
Auth-->>Resolver: 93.184.216.34
Resolver-->>Client: 93.184.216.34
Frequently asked questions
- What is a DNS resolution sequence diagram?
- It shows the conversation between a client, its recursive resolver, and the DNS hierarchy — root, TLD, and authoritative nameservers — that collectively answer the question "What IP address belongs to example.com?". Each hop adds one piece of information until the authoritative nameserver reveals the answer, which the resolver caches and returns.
- Why does the resolver ask the root nameserver instead of asking the TLD directly?
- The client and resolver do not know which TLD nameserver to ask — the root nameserver is the only well-known starting point. The root points to the TLD (top-level domain) nameserver for that domain extension, which then points to the authoritative nameserver for that specific domain. This hierarchy keeps DNS scalable as the internet grows.
- What is the difference between a recursive resolver and an authoritative nameserver?
- A recursive resolver (often your ISP's DNS server) walks the full chain of queries on your behalf and caches the result — it is the worker that does the asking. An authoritative nameserver owns the actual DNS records for a domain and only answers questions it knows — it does not recurse. Most resolvers cache answers for minutes or hours, making the second lookup instant.
- How do I customize this diagram for DNSSEC or a local DNS cache?
- For DNSSEC, add a "Verify signature" step after each response — the resolver validates each answer cryptographically. For a local cache hit, add a decision diamond after the client query: if cached, return immediately; if not, proceed to the resolver. Either change drops right into the visual editor without syntax trouble.