How DNS Resolution, Hierarchy and Caching Work

DNS is a distributed naming system, not a single web server or a worldwide copy of every website. It provides addresses and other records used by applications. Understanding the difference between delegation, authority and caching makes DNS failures easier to diagnose without guessing or waiting a fixed day.

Read the hierarchy from right to left

In mail.example.com., the final dot represents the root, com is the top-level domain, example is the next label and mail is a child name. A fully qualified name identifies its complete position. A name with several labels is not necessarily a separately delegated zone: administrative zone boundaries and name labels are different concepts.

The root refers resolvers toward top-level-domain authorities, which can refer them toward a registered domain’s authoritative servers. IANA lists 13 root-server identities, not merely 13 physical machines. Their distributed anycast instances and routing are more complex than a guarantee of the geographically nearest server.

Generic and country-code TLDs have differing registration rules. Historical labels such as commercial or nonprofit do not mean every domain under that suffix is restricted to that use. Registrable boundaries can span labels, as in names under co.uk; availability alone does not establish unrestricted eligibility.

What a lookup can involve

1. The application chooses its configured resolution path. Browser encrypted DNS, operating-system resolution, local host overrides and application caches can differ.
2. A recursive resolver may answer from cache. If it must discover authority, it follows referrals through the relevant delegation path and asks authoritative servers.
3. The answer returns to the requester and may be cached under applicable rules. An alias can require additional resolution.
4. The application uses the result to contact its service. DNS does not complete TLS, HTTP, mailbox provisioning or application authorization.

This is a model, not a promise every lookup visits the root or follows identical browser/OS cache steps. Latency depends on network, caches and service behavior; no universal 20-50 ms or sub-millisecond result is established here.

Know which record you need

A and AAAA provide IPv4 and IPv6 addresses; CNAME aliases a name; MX names mail exchangers with preferences; TXT carries application-specific data; NS and SOA describe authority and zone administration; PTR belongs to reverse DNS. A CNAME at a zone apex conflicts with required apex data; provider flattening features have their own semantics.

No MX answer does not universally mean SMTP cannot deliver: SMTP defines an implicit-address fallback in specific circumstances. An explicit null MX instead declares no mail service. Neither a web address nor a guessed mailbox record is a complete hosted-email setup. See the record reference and mail-authentication diagnosis.

Read-only command templates

With dig installed, these examples inspect different questions. Replace example.com with the intended domain. The explicit resolver query bypasses the system’s usual resolver selection; it is not necessarily an authoritative query.

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig @8.8.8.8 example.com A
dig +trace example.com A

Normal output includes response status, answers and responding-server information. NXDOMAIN means a nonexistent queried name in that response, not a connection timeout. An empty answer may mean the requested type is absent; inspect the full status and authority sections. SERVFAIL needs further investigation, including DNSSEC or upstream errors.

host and nslookup are alternative lookup tools, but their defaults and output differ. On Linux, /etc/resolv.conf may point to a local stub or be generated; resolvectl status can explain upstream configuration on systems using systemd-resolved. Do not overwrite managed files just to inspect them.

Check changes and security carefully

Verify the correct data at each authoritative server before blaming caches. TTL changes do not shorten copies already cached under an older value; negative caching and stale-answer rules also matter. See propagation troubleshooting. Flushing an OS cache does not flush every browser or public resolver, and private browsing is not a guaranteed DNS reset.

An address answer does not prove DNS is entirely correct or that the application works. Test the exact name/type, delegation, affected client path and service separately. A trace is useful evidence, not a complete DNSSEC validation or universal connectivity test.

DNSSEC authenticates signed DNS data when a valid trust chain exists; it does not encrypt lookups or make the named service safe. DoH/DoT protect particular transport paths, not all activity from every observer. Cache poisoning remains a security concern, and choosing a recursive provider involves privacy and operational tradeoffs. Do not casually switch resolvers or disable validation to conceal errors.

References: DNS terminology, IANA root-server identities, BIND lookup-tool manuals, SMTP address resolution and null MX.

Reviewed October 16, 2026. Command syntax and inert argument checks only; no public-resolution latency, recursive trace, DNSSEC deployment or application test was performed.