DNS Explained: How Name Resolution Works, DNS Records, Caching, and TTL

Introduction

If you’ve ever typed a website name and it “just worked,” you’ve relied on DNS. In this DNS explained guide, you’ll learn how the Domain Name System translates human-friendly domain names into IP addresses so browsers, email servers, and APIs can connect to the right host. We’ll cover name resolution step by step, common DNS record types, DNS caching and TTL, recursive vs authoritative DNS behavior, troubleshooting with dig/nslookup, and operational best practices.

DNS explained: What is the Domain Name System?

DNS (the domain name system) is a globally distributed database that maps names like www.example.com to IP addresses. This mapping process is called name resolution. A resolver (often a recursive resolver from your ISP, enterprise network, or cloud provider) queries DNS servers to find answers, while authoritative DNS servers publish the official records for a domain’s zone.

Because DNS is hierarchical and delegated, no single server holds every record. Instead, zones are delegated from parent to child using NS records, allowing the system to scale reliably.

How DNS name resolution works (step-by-step

How DNS resolution works step by step: a client asks a resolver to look up a record (such as an A record). The resolver follows delegations from root servers to TLD servers and then to the domain’s authoritative servers until it retrieves the requested DNS records.

Query types — recursive vs iterative

In a recursive query, the resolver takes responsibility for returning a final answer (or an error) to the client. In an iterative query, a DNS server responds with the best information it has—often a referral to another server closer to the authoritative source.

This is commonly described as recursive vs authoritative DNS: recursive resolvers do the lookup work and cache results, while authoritative servers answer for their zones.

The role of resolvers, root servers, TLD servers, and authoritative servers

1. The client’s stub resolver asks a recursive resolver for www.example.com.
2. The resolver queries a root server to find where .com is served.
3. The resolver queries the TLD server to find the domain’s authoritative name servers.
4. The resolver queries an authoritative server to retrieve the needed record (A, AAAA, CNAME, MX, etc.).
5. The resolver returns the answer to the client and caches it according to the record’s TTL.

If delegation is misconfigured (wrong NS records, missing glue, or outdated SOA serials), name resolution can fail even when the zone contains the “right” record.

Common DNS record types (A, AAAA, CNAME, MX, NS, SOA

DNS records are stored in zone files (or equivalent managed DNS backends). Knowing what each record type does is essential for web hosting, service discovery, and email delivery.

A and AAAA records — IPv4 and IPv6

An A record maps a hostname to an IPv4 address. An AAAA record maps a hostname to an IPv6 address. If you’re learning networking fundamentals, this is where DNS meets IP addressing and subnetting basics.

CNAME and aliasing best practices

A CNAME (canonical name) record aliases one hostname to another. Common guidance:

• Use CNAMEs for true aliases (for example, app.example.com → prod.example.net).
• Avoid long CNAME chains; each hop can add lookup time.
• Be cautious at the zone apex; many DNS providers offer “ALIAS/ANAME” features, but standard DNS uses A/AAAA at the apex.

MX records and mail routing

MX records specify mail exchangers and priorities for a domain. Lower priority numbers are tried first. If no MX record exists, many mail servers fall back to A/AAAA records for the bare domain, but relying on that behavior is risky for production email.

NS and SOA — delegation and zone metadata

NS records indicate which authoritative servers host a zone. The SOA record includes zone metadata such as the primary name server, administrator contact, and timing values (serial, refresh, retry, expire). The SOA serial is especially important when you need secondary servers and caches to recognize updates.

DNS caching and TTL — how it affects propagation and changes

What is DNS caching and TTL? DNS caches store answers to reduce latency and authoritative query load. The TTL (time to live) tells resolvers how long a record may be cached before it must be refreshed. This is why “DNS propagation” is really about caches expiring at different times.

How resolvers and caches respect TTL

Resolvers cache responses by name, type, and sometimes additional DNSSEC-related data. When the TTL reaches zero, the resolver must re-query authoritative DNS. Many resolvers also use negative caching (caching NXDOMAIN/no data responses) based on SOA settings, which can delay visibility when you create a record that previously didn’t exist.

When to lower or raise TTL for deployment changes

• Before a cutover: lower TTL well in advance (commonly 60–300 seconds) so old answers expire quickly.
• During validation: confirm changes from multiple resolvers and networks.
• After stabilization: raise TTL (often 3600–86400 seconds) to improve cache hit rate and resilience.

Very low TTLs increase query volume and can amplify the impact of transient resolver issues. Very high TTLs slow rollback if you publish incorrect records.

Recursive vs authoritative DNS and resolver behavior

Recursive resolvers serve end users and applications by performing lookups, following delegations, and caching results. Authoritative servers publish the source-of-truth zone data. When debugging, separate these roles: a stale answer often points to caching/TTL behavior, while an incorrect answer from authoritative DNS points to a zone-file or managed-DNS configuration issue.

Split-horizon DNS and common deployment patterns

Split-horizon DNS (DNS views) returns different answers based on the query source. It’s commonly used to serve private RFC1918 addresses internally while exposing public addresses externally. To avoid surprises, document which clients use which resolvers and keep internal vs external zones clearly separated.

Common DNS troubleshooting steps and tools (dig, nslookup, traceroute

When DNS breaks, verify each layer of the request path: client configuration, recursive resolver behavior, and authoritative DNS responses. Most issues come down to wrong records, wrong delegation (NS), caching/TTL, or split-horizon mismatches.

Example queries (dig and nslookup) and expected output

Check an A record with dig:

dig +noall +answer www.example.com A

Expected output (example):

www.example.com.  300  IN  A  93.184.216.34

Check which authoritative servers are delegated:

dig +noall +answer example.com NS

Check with nslookup (Windows-friendly):

nslookup -type=MX example.com

Practical troubleshooting checklist

• Confirm the client is using the intended resolver (enterprise DNS, VPN DNS, or public resolver).
• Query a public recursive resolver (for example, 1.1.1.1 or 8.8.8.8) and compare results.
• Query authoritative servers directly to bypass cache and isolate zone issues.
• Verify NS delegation and look for missing glue records when required.
• Check TTL and negative caching when newly created records don’t appear.
• Use traceroute/tracert to distinguish DNS failures from routing issues (routing vs switching problems can look similar at first).

Best practices for managing DNS in production

• Use redundancy: at least two authoritative name servers across separate networks.
• Automate changes: infrastructure-as-code reduces drift and speeds rollback.
• Monitor DNS: track query failures, latency, and record correctness from multiple regions.
• Plan TTLs: choose values based on change frequency and risk tolerance.
• Harden security: restrict zone transfers, use least-privilege access, and consider DNSSEC where appropriate.
• Document dependencies: DNS and DHCP explained together helps teams trace host naming to IP assignment.

Frequently asked questions

DNS explained for beginners: is DNS a protocol or a service?

It’s both: DNS is a protocol (queries and responses) and a distributed system of servers that implement it.

Does changing a DNS record update instantly?

No. Changes are seen as caches expire based on TTL, plus any resolver-specific minimum/maximum caching behavior.

Why do I get different answers on and off a VPN?

This often indicates split-horizon DNS or different recursive resolvers with different caches.

Conclusion — DNS explained: key takeaways and next steps

DNS explained in one sentence: it’s the internet’s naming system that turns domain names into IP addresses through a delegated hierarchy, with performance and “propagation” largely driven by caching and TTL. To go further, practice reading A/AAAA/CNAME/MX/NS/SOA records, run dig against recursive and authoritative servers, and standardize DNS change processes for production reliability.