The Ultimate Guide to DNS: How the Domain Name System Works

DNS — the Domain Name System — is the infrastructure that translates domain names into IP addresses. Without it, you'd be typing IP addresses into your browser instead of domain names. It's one of the most critical pieces of internet infrastructure, and when it fails, nothing works.

This guide covers everything: how DNS resolution works, every major record type, TTL and propagation, common problems, and how to monitor DNS to catch failures before they affect users.

What DNS Does

Computers communicate over the internet using IP addresses — numerical identifiers like 203.0.113.10. Humans use domain names — like example.com. DNS is the system that bridges the two.

When you type example.com into your browser, DNS translates that name into the IP address of the server hosting the website. Your browser then connects to that IP address to load the page.

This translation happens billions of times per second across the internet, is largely invisible, and is fundamental to how the internet works.

How DNS Resolution Works (Step by Step)

Understanding the resolution process helps you diagnose DNS problems and understand propagation delays.

Step 1: Check the Local Cache

Before making any network requests, your device checks its local DNS cache. If it already has a recent answer for example.com, it uses that directly. DNS responses are cached based on their TTL (time to live) value — if the cache entry hasn't expired, no lookup is needed.

Step 2: Ask the Recursive Resolver

If the cache misses, your device asks its configured recursive resolver — typically your ISP's DNS server, or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The recursive resolver does the actual work of finding the answer. It also has its own cache — if it recently answered the same query for another user, it returns the cached answer immediately.

Step 3: Ask the Root Nameservers

If the recursive resolver doesn't have a cached answer, it starts from the top. There are 13 sets of root nameservers distributed globally. They don't know the IP address for example.com, but they know which nameservers are authoritative for .com domains.

Step 4: Ask the TLD Nameservers

The recursive resolver asks the .com TLD (top-level domain) nameservers: "who's responsible for example.com?" They respond with the authoritative nameservers for example.com.

Step 5: Ask the Authoritative Nameservers

The recursive resolver asks the authoritative nameservers for example.com — the servers that actually hold the DNS records for that domain. They return the A record (IP address) for example.com.

Step 6: Return and Cache the Answer

The recursive resolver returns the IP address to your device and caches it for the duration of the TTL. Your device also caches it. Your browser connects to the IP address.

The whole process typically takes milliseconds. After the first lookup, cached results make it even faster.

DNS Record Types

DNS records are stored at the authoritative nameservers and define how a domain behaves. Here are all the major types. For a more detailed reference, see DNS record types explained.

A Record

Maps a domain to an IPv4 address. The most fundamental record.

example.com    A    203.0.113.10
www.example.com    A    203.0.113.10

AAAA Record

Maps a domain to an IPv6 address.

example.com    AAAA    2001:db8::1

CNAME Record

Creates an alias pointing one hostname to another hostname (not an IP). Cannot be used at the root domain (use ALIAS/ANAME records for that, where supported).

www.example.com    CNAME    example.com
shop.example.com    CNAME    stores.shopify.com

MX Record

Specifies which mail servers handle email for the domain. Priority number is included — lower means higher priority.

example.com    MX    10    mail1.provider.com
example.com    MX    20    mail2.provider.com

TXT Record

Stores text data. Used for domain verification, SPF, DKIM, DMARC, and other purposes.

example.com    TXT    "v=spf1 include:_spf.google.com ~all"

NS Record

Specifies the authoritative nameservers for the domain. Set at your registrar — these tell the internet where to find your DNS records.

example.com    NS    ns1.cloudflare.com
example.com    NS    ns2.cloudflare.com

SOA Record

Start of Authority. Contains administrative information about the DNS zone. Managed by your DNS provider automatically.

SRV Record

Specifies hostname and port for specific services. Used for VoIP, XMPP, and some Microsoft services.

CAA Record

Specifies which Certificate Authorities can issue SSL certificates for the domain. Adds a layer of protection against fraudulent certificate issuance.

example.com    CAA    0 issue "letsencrypt.org"

PTR Record

Reverse DNS — maps an IP address back to a hostname. Managed by whoever owns the IP (your hosting provider). Important for email deliverability.

TTL: Time to Live

Every DNS record has a TTL value in seconds that controls how long it's cached. This is one of the most practically important DNS concepts.

How TTL Affects Propagation

When you change a DNS record, the change takes effect at the authoritative nameserver immediately. But cached copies of the old record throughout the internet continue to be used until their TTL expires.

• TTL of 86400 (24 hours) — Changes can take up to 24 hours to propagate globally. Old record is served to cached resolvers for up to a day.
• TTL of 3600 (1 hour) — Changes propagate within an hour.
• TTL of 300 (5 minutes) — Changes propagate within 5 minutes.

When to Lower TTL

Before making significant DNS changes — migrating hosting, switching DNS providers, changing IP addresses — lower your TTL to 300 seconds at least 24 hours before the change. This means:

1. Existing caches expire within 5 minutes of the change
2. The new record is picked up quickly
3. If something goes wrong, rolling back is fast

After the change is confirmed working, raise the TTL again.

When to Keep TTL High

A high TTL (3600-86400) reduces DNS query load and makes resolution faster for users (more cache hits). For stable, rarely-changing records, a higher TTL is appropriate.

DNS Propagation

"Propagation" refers to the process of DNS changes spreading across the internet as cached records expire and are replaced with new ones.

Propagation is not simultaneous. Different users will see old and new records simultaneously during the propagation period, based on whether their resolver has a cached copy and when that cache expires.

Checking Propagation

Tools for checking what different DNS resolvers are returning:

• dig command: dig example.com A — checks from your local resolver
• dig @8.8.8.8 example.com A — checks against Google's resolver specifically
• Online tools like whatsmydns.net show results from multiple global locations

Why "Propagation" Is Often a TTL Issue

When a DNS change seems slow to propagate, it's usually because the TTL on the old record was high (like 86400). The records are being served from cache at various resolvers and won't update until those caches expire.

Lowering TTL before making changes (as described above) is the preventive fix. After the fact, you can only wait for caches to expire.

Common DNS Problems

DNS Not Resolving (NXDOMAIN)

NXDOMAIN means "non-existent domain" — the authoritative nameserver has no record for the queried name. See DNS_PROBE_FINISHED_NXDOMAIN fix.

Common causes:

• Typo in the domain or subdomain
• A record missing or deleted
• NS records pointing to wrong nameservers
• Domain expired

Slow DNS Resolution

DNS should be fast — typically under 100ms. Slow resolution adds to page load time.

Causes:

• High TTL causing fresh lookups when cache expires
• Resolver far from user
• Authoritative nameserver slow or under load

Fix: Use a fast DNS provider. Consider Cloudflare DNS for authoritative hosting.

Email Delivery Failures After DNS Change

If you change nameservers or modify DNS records, MX records can be inadvertently affected.

Fix: Always verify MX records are correctly configured after any nameserver change. Send a test email to verify delivery.

DNS Hijacking

Malicious actors sometimes alter DNS records — at the registrar, at the DNS provider, or via compromised credentials — to redirect your domain to a different server.

Detection: DNS monitoring compares your records against known-good values and alerts when they change. This is the primary defence against DNS hijacking that isn't caught by routine checks.

Slow DNS After Switching Providers

After switching DNS providers, some resolvers may have cached the old NS records with a long TTL.

Fix: This requires waiting for the old TTL to expire. Lowering TTL before the switch minimises this window.

DNS and Email Deliverability

DNS plays a critical role in email deliverability through three TXT records:

SPF (Sender Policy Framework) — Lists which IP addresses and mail services are authorised to send email for your domain. Prevents spoofing.

example.com    TXT    "v=spf1 include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail) — A public key used to verify that emails were actually sent by your domain and weren't tampered with in transit.

DMARC — A policy defining what to do with emails that fail SPF and DKIM checks, plus a reporting address to receive feedback from mail servers.

Without these records, your emails are more likely to be marked as spam. Email providers like Google and Microsoft use these records to determine whether to deliver your email.

DNS Monitoring

DNS failures have an immediate and total impact — if your A record is wrong or missing, your entire website is unreachable. If your MX records change, email stops working.

DNS monitoring automatically detects changes or failures in your DNS records and alerts you immediately. This catches:

• Accidental record deletion or misconfiguration
• DNS hijacking (records changed by an attacker)
• Nameserver failures
• Propagation issues during migrations

Domain Monitor monitors DNS records alongside website uptime and SSL certificate expiry. Create a free account and set up DNS monitoring for your domain.

For Domain Monitor's specific DNS monitoring features, see DNS monitoring is here. For a broader monitoring setup, see the ultimate guide to website uptime monitoring.

Choosing a DNS Provider

Most domain registrars include basic DNS hosting. For better performance and reliability, consider a dedicated DNS provider:

Cloudflare DNS — Fast, free, DDoS-protected DNS hosting. Includes CDN and security features if you proxy through Cloudflare. Generally the best choice for most websites.

Amazon Route 53 — AWS's DNS service. Good for applications already running on AWS. Supports advanced routing policies (latency-based, weighted, geolocation).

NS1 — High-performance DNS with advanced traffic management. Used by large-scale applications requiring sophisticated routing.

For most websites, Cloudflare's free DNS hosting is fast, reliable, and well-supported. The key is ensuring DNS records are correct and monitored, regardless of provider.

Related Articles

• DNS Record Types Explained - A, CNAME, MX, TXT and More
• "What Is Domain Hijacking and How to Detect It"
• The Ultimate Guide to HTTP Status Codes