How DNS Works: Records, Propagation, Diagnostics and Security

Why the Site Doesn't Work When "Everything Is Configured Correctly"

A client moved their site to a new server. IP changed, A record updated, server works. But half the users see the old site, and the other half see an error. Provider support says "wait 48 hours." The client is nervous because they're losing orders every hour.

The reason is DNS. More precisely, not understanding how it works. If the client had lowered the TTL a day before the move, the problem would have lasted 5 minutes instead of two days.

DNS (Domain Name System) is what transforms hostiserver.com into a server's IP address. A system that works billions of times a day and is invisible — until something breaks. In this guide, we'll cover how DNS works under the hood, how to avoid pitfalls during migration, and which records need to be configured so your email doesn't land in spam.

How a DNS Query Travels from Browser to Server

When you type a website address, a chain of requests occurs. The entire process takes 20-100 ms, but during this time up to 4 types of servers are involved.

Here's how it looks:

Browser → OS Cache → Recursive Resolver → Root Server → TLD Server (.com) → Authoritative Server → IP address!
                         (8.8.8.8)         ("who's .com?")   ("who's example.com?")   ("93.184.216.34")

Step by Step

1. Local cache — the browser checks if it already knows this domain's IP. If you visited the site before and TTL hasn't expired — the query doesn't go further. This is the fastest option: 0 ms.

2. Recursive resolver — if not in cache, the query goes to a recursive DNS server. This could be your provider's server or a public DNS (Google 8.8.8.8, Cloudflare 1.1.1.1). This server takes on all the further work.

3. Root servers — the resolver asks one of 13 root servers: "Where to look for .com domains?" The root server doesn't know the IP of a specific site but knows who's responsible for the .com zone.

4. TLD servers — the .com zone server says: "These name servers are responsible for example.com." And gives their address.

5. Authoritative server — the final point. It contains the actual DNS records for the domain and returns the IP address — for example, 93.184.216.34.

6. Caching — the result is stored at each level (resolver, OS, browser) for the TTL duration. The next query to the same domain will be processed in 1-5 ms.

4 Types of DNS Servers

DNS Records: What, Why, and How to Configure

DNS records are instructions that tell servers how to handle requests to your domain. Each record type is responsible for its own function.

Main Record Types

When Which Records Are Needed

Not all records are needed immediately. Here are typical scenarios:

• Website only: A + AAAA (optional) + CNAME for www
• Website + email (Google Workspace / Microsoft 365): A + CNAME + MX + TXT (SPF) + TXT (DKIM) + TXT (DMARC)
• Website via CDN: CNAME to CDN provider instead of A record
• SSL certificate restriction: CAA record (e.g., allow only Let's Encrypt)

SPF, DKIM, DMARC — Email Protection

Three TXT records that are critically important if you send email from your domain:

• SPF — specifies which servers are allowed to send mail on behalf of your domain. Without SPF, emails often end up in spam.
• DKIM — adds a digital signature to each email. The recipient can verify that the email wasn't forged.
• DMARC — policy for what to do with emails that fail SPF/DKIM verification (reject, quarantine, allow).

How to Check and Diagnose DNS

When something doesn't work — domain doesn't resolve, email doesn't arrive, or site shows old version — the first thing to check is DNS.

dig — The Main Tool

# A record for domain
dig hostiserver.com A
# MX records (mail servers)
dig hostiserver.com MX
# TXT records (SPF, DKIM, verification)
dig hostiserver.com TXT
# Query through specific DNS server
dig @8.8.8.8 hostiserver.com A
# Short output
dig +short hostiserver.com A

nslookup — Alternative for Windows

# Basic query
nslookup hostiserver.com
# Through specific server
nslookup hostiserver.com 8.8.8.8
# MX records
nslookup -type=MX hostiserver.com

Clearing DNS Cache

If you changed DNS records but see the old version — the problem is caching:

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

DNS Propagation: Why Changes Don't Apply Immediately

You changed the A record, but the site still shows the old IP. Clients in one country see the new site, while in another — the old one. This is DNS propagation — the process of spreading changes across all DNS servers worldwide.

Why It Takes Time

Every DNS server caches responses for the TTL (Time to Live) duration. If your A record's TTL was 86400 seconds (24 hours) — some servers will return the old IP for up to 24 hours after the change.

How to Speed Up Propagation

• Lower TTL in advance. 24-48 hours before planned changes, reduce TTL to 300 seconds (5 minutes). After the change — raise it back.
• Clear local cache. ipconfig /flushdns on your computer.
• Use fast DNS. Public DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) update faster than ISP DNS.

DNS and Security: DNSSEC, DNS over HTTPS

Standard DNS works in plain text — queries and responses are not encrypted or signed. This creates vulnerabilities.

DNS Spoofing (Cache Poisoning)

An attacker substitutes the DNS server's response and redirects the user to a fake site. Everything looks normal from the outside — the address in the browser is correct, but the IP points to the attacker's server.

DNSSEC

DNS Security Extensions adds a digital signature to DNS responses. The recursive resolver can verify that the response wasn't tampered with along the way. DNSSEC doesn't encrypt queries but guarantees their authenticity.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Encrypt DNS queries so that the provider or someone on the network can't see which sites you visit. Supported in all modern browsers and operating systems:

• DoH — DNS over HTTPS (port 443). Used by Chrome, Firefox, Edge.
• DoT — DNS over TLS (port 853). Used by Android, Linux.

5 DNS Mistakes We See Regularly

1. Forgot to update NS records after migration. Moved site to new hosting, changed A record, but NS records still point to old provider. Result: some queries go to the old server.

2. Missing SPF/DKIM. Domain email goes to spam or is blocked. Especially critical for eCommerce with transactional emails.

3. High TTL before migration. TTL 86400 (24 hours) means after IP change, some users will see the old site for another day. Lower TTL to 300 in advance.

4. CNAME on root domain. example.com cannot have CNAME (only A/AAAA). CNAME works only for subdomains (www, blog, shop). Some DNS providers work around this with ALIAS/ANAME records.

5. Don't verify DNS after changes. Changed records and waiting for "it to work." Use dig or online checkers to confirm changes applied correctly.

Frequently Asked Questions