# DNS Resolution Mechanics ## The resolver asks around on your behalf; the authoritative server is the source of truth Two roles, constantly confused, and the distinction carries the entire sovereignty argument. The **recursive resolver** is the thing your device talks to. It usually does not know the answer. It goes and finds it by querying up a chain: a root server, then the relevant top-level-domain server, then finally the authoritative server for the specific domain, which is the only party that actually holds the record. Then it hands the answer back. The **authoritative server** answers only for the domains it is responsible for. It is the source of truth and it never asks anyone else. ```mermaid graph LR D[Your device] --> R[Recursive resolver] R --> C{In cache?} C -->|yes| D C -->|no| ROOT[Root servers] ROOT --> TLD[TLD servers .com .ke] TLD --> AUTH[Authoritative server for the domain] AUTH --> R class D,R,AUTH internal-link; ``` > [!tip] Caching is why this is fast > Most lookups never reach the root. The resolver holds recent answers for the duration of each record's ==TTL==, so the full walk happens rarely. Caching is also why DNS changes propagate slowly, and why a poisoned cache is such an effective attack. **Recursive vs iterative** is the other pair worth keeping straight. Your device makes one recursive request, meaning "go get me the final answer." The resolver then makes a series of iterative queries, each returning a referral to the next server down rather than the answer itself. ## Why it matters Everything downstream of this sits on the same fact: the resolver sees every question, and the authoritative server sees only questions about itself. That asymmetry is what makes the resolver the valuable and the dangerous position. ## Related - [[The Resolver as Sovereignty Chokepoint]] - [[DNS as a Security Signal]] - [[DoH and DoT]] - [[CoreDNS]] - [[PowerDNS]] - [[Security MoC]]