DNS basics in one page

High-level flow 🌐

Clients may use local caches before asking a recursive resolver. The resolver uses cached information or follows delegations from the root to the TLD and the target authoritative zone. It does not start at the root for every query; it may also forward requests to another resolver.

Recursion vs. iteration

• Recursive query: client to resolver, “please resolve fully for me.”
• Iterative query: resolver to upstream servers, “tell me what you know,” then follows referrals.
• Answers can be cached with TTL-based freshness; cache eviction or refresh can happen sooner.

Caching resolver

Does recursive lookups on behalf of clients. Run by ISPs, enterprises, or public DNS (1.1.1.1, 8.8.8.8, etc.).

Role

• Receives recursive queries and, if needed, walks root/TLD/authoritative.
• TTL governs normal cache freshness, not a guarantee of an unchanged answer. The serve-stale mechanism can use expired data when authoritative refresh is unavailable.
• A validating resolver checks DNSSEC. Relying on its AD flag requires trusting that resolver and the communication path to it.

When an old answer survives a change

Changing authoritative data does not immediately erase an answer already held by a resolver. Lowering a TTL does not shorten an earlier cache entry that was stored with a longer TTL. See the examples in DNS TTL and caching for how the change time relates to the remaining lifetime. If a new name cannot be found, the section on caching negative answers explains another possible cause.

Authoritative DNS

Publishes authoritative data for a zone such as example.com, including SOA, NS, and other records. Authoritative does not mean free of configuration errors.

Notes

• Answers from zone data stored in files or databases and refers queries for delegated zones to their authorities.
• Primary/secondary for redundancy is standard practice.
• CDNs and cloud DNS offer authoritative services, often anycasted.

DNSSEC 🔒

Signs DNS record sets to authenticate their origin and integrity. DNSSEC does not encrypt queries or guarantee that a destination website is safe.

How it works (short)

• Signed zones publish RRSIG signatures and DNSKEY public keys. A DS record linking to a child key is published in the parent zone.
• Validation normally starts with a configured root trust anchor and follows DS-to-DNSKEY links. Unsigned delegations also exist; not every domain is signed.
• Bogus data that fails validation differs from insecure, unsigned data. Normal validation returns SERVFAIL for bogus data; unsigned data is not treated as authenticated.

Practical notes

• When enabling DNSSEC, remember key rollover and DS registration.
• Some old resolvers/devices may not support DNSSEC—check before rollout.

Specifications and related guides

RFC 1034 §4.3.1 / RFC 4033 / RFC 4035 §4.9.3 / RFC 8767 §4. Continue with DNS root servers for delegation and DNS TTL and caching for interpreting answers after a change.