DNS Fundamentals
Chapter 1 — DNS Fundamentals
Almost every problem with web hosting eventually traces back to DNS. A misconfigured record, an expired cache, or a CNAME in the wrong place can make a perfectly healthy server completely unreachable. Understanding how DNS actually works — not just how to copy and paste records — gives you the ability to diagnose these problems confidently rather than guessing.
What this chapter covers: What DNS is and why it exists. The full resolution chain — how a browser turns "osztromok.com" into an IP address. Record types: A, AAAA, CNAME, MX, TXT, NS. TTL and why it controls how long changes take to propagate. Querying DNS with dig and nslookup. The CNAME-at-apex limitation that catches everyone out.
What DNS Is and Why It Exists
The internet routes traffic using IP addresses — numbers like 82.2.236.221. Humans are bad at remembering numbers and good at remembering names. DNS (Domain Name System) is the phone book that translates between the two: you type osztromok.com, DNS looks up the IP address, and your browser connects to that address.
DNS is a distributed, hierarchical database. No single server knows all domain names — instead the responsibility is delegated down a tree of servers, each authoritative for their own portion of the namespace. This design means it scales to handle billions of queries per second across the entire internet.
Why this matters for web hosting: When you set up your website, you're not just configuring the web server — you're also configuring the DNS records that tell the internet how to find it. Get the DNS wrong and nobody can reach your server, even if the server itself is working perfectly. This is what happened with osztromok.com earlier — the server was running fine but DNS was pointing to the wrong IP.
How DNS Resolution Works
When you type osztromok.com in a browser, several servers are consulted in sequence before the IP address is found. This happens in milliseconds, but understanding each step helps you diagnose where things go wrong.
Your browser
│
│ 1. Check local DNS cache — is the answer already known?
│ If yes → use it (no network request needed)
│
▼
Recursive Resolver (your ISP's DNS server, or 8.8.8.8 / 1.1.1.1)
│
│ 2. Check resolver cache — has it recently looked this up?
│ If yes → return cached answer
│
│ 3. If not cached, start from the top:
│
▼
Root Nameservers (13 clusters worldwide, addresses hardcoded)
│
│ "I don't know osztromok.com, but .com is handled by Verisign"
│ Returns the address of the .com TLD nameservers
│
▼
TLD Nameservers (.com, .net, .org, .co.uk etc.)
│
│ "I don't know osztromok.com specifically, but IONOS is
│ authoritative for it" — Returns IONOS nameserver addresses
│
▼
Authoritative Nameserver (IONOS, Cloudflare, etc.)
│
│ "Yes! osztromok.com has an A record pointing to 82.2.236.221"
│
▼
Recursive Resolver (caches the answer for TTL seconds)
│
▼
Your browser → connects to 82.2.236.221
The recursive resolver does the legwork — it consults the root, TLD, and authoritative servers so your browser doesn't have to. It also caches answers so subsequent lookups for the same domain are instant. The length of time it caches is controlled by the TTL value on each DNS record.
Authoritative vs recursive: The authoritative nameserver is the one that holds your actual DNS records — for osztromok.com this is IONOS (or Cloudflare, if you transfer DNS there). A recursive resolver is the intermediary that queries on your behalf — your ISP runs one, and so do Google (8.8.8.8), Cloudflare (1.1.1.1), and others. When you change a DNS record at IONOS, you're changing the authoritative answer — but resolvers around the world keep serving their cached copy until the TTL expires.
DNS Record Types
Each DNS record has a type that defines what kind of information it holds. You'll encounter these constantly when managing a website.
A
Address record
Maps a domain name to an IPv4 address. The most fundamental record — this is what tells the internet where your website lives. Every publicly accessible domain needs at least one A record.
osztromok.com. 300 IN A 82.2.236.221
AAAA
IPv6 address record
Maps a domain name to an IPv6 address (the newer, longer address format). Works exactly like an A record but for IPv6. Most modern websites have both A and AAAA records. If your ISP doesn't give you an IPv6 address, you can skip this.
osztromok.com. 300 IN AAAA 2001:db8::1
CNAME
Canonical name (alias)
Points one domain name to another domain name (not an IP). The resolver follows the chain until it finds an A record. Used for subdomains and services like Cloudflare Tunnel. Cannot coexist with other records for the same name, and cannot be used at the root domain (apex) on most providers.
www 300 IN CNAME osztromok.com.
MX
Mail exchanger
Tells email servers where to deliver mail for your domain. Has a priority number — lower number = higher priority. Multiple MX records provide redundancy. If you use Google Workspace or Microsoft 365 for email, they give you specific MX records to add.
osztromok.com. 300 IN MX 10 mail.osztromok.com.
TXT
Text record
Stores arbitrary text data. Used for domain verification (Google, GitHub, etc. ask you to add a TXT record to prove you own the domain), SPF (specifies which servers are allowed to send email for your domain), and DKIM (email signing keys).
osztromok.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
NS
Nameserver record
Declares which servers are authoritative for your domain. Set at your registrar (where you bought the domain), not in your DNS management panel. Changing NS records is what "moving DNS to Cloudflare" means — you point them at Cloudflare's nameservers instead of IONOS's.
osztromok.com. 86400 IN NS ns1.ionos.co.uk.
The CNAME-at-apex limitation: You cannot use a CNAME record for your root domain (
osztromok.com) on most DNS providers — only for subdomains (www.osztromok.com). This is a limitation of the DNS specification: the root domain must have an SOA and NS record, and CNAME cannot coexist with any other record type. Cloudflare solves this with "CNAME flattening" — it internally resolves the CNAME and serves the resulting IP as an A record, making it transparent. This is one of the main practical reasons to move DNS to Cloudflare.
TTL — Time To Live
Every DNS record has a TTL value measured in seconds. This tells resolvers how long they're allowed to cache the answer before asking again. A record with TTL 300 can be cached for 5 minutes; a record with TTL 86400 can be cached for 24 hours.
TTL directly controls how long a DNS change takes to take effect across the internet. If your A record has a TTL of 86400 and you change the IP address, resolvers that cached it will keep serving the old address for up to 24 hours.
60–300
1–5 minutes
Use when you're about to make a change. Set this 24 hours before the change so caches clear quickly when you update the record.
3600
1 hour
A sensible default for most records. Balances propagation speed with resolver load. Good for records that change occasionally.
86400
24 hours
For stable records that rarely change — MX records, NS records. Reduces DNS query load. Don't use for A records on a dynamic IP.
The golden rule for DNS changes: Before making a significant change (moving hosts, changing IP, moving DNS to Cloudflare), lower the TTL on the affected records to 300 (5 minutes) and wait for the current TTL to expire. Then make your change. This means the old cached values drain away quickly. Once the change is stable, you can raise the TTL again.
DNS Propagation — what it actually means
"DNS propagation" is often described as taking 24–48 hours. In practice with a low TTL it can be as fast as a few minutes. What's actually happening is that resolvers around the world are all waiting for their cached copies to expire at different times — some cached it an hour ago, some cached it 30 seconds ago. "Propagation" is just waiting for the last cached copy in the world to expire.
Checking propagation: The tool dnschecker.org queries DNS servers in dozens of locations around the world simultaneously and shows which ones have picked up your new record. This is much more useful than just checking on your own machine, where your local resolver might have a long-lived cache.
Querying DNS with dig and nslookup
dig is the standard tool for querying DNS from the command line on Linux. It shows you exactly what a nameserver returns, including TTL, record type, and which server answered. nslookup is an older alternative available on Windows and Linux.
# ── Basic lookups ────────────────────────────────────────────────
$ dig osztromok.com
;; ANSWER SECTION:
osztromok.com. 300 IN A 82.2.236.221
# Domain TTL Class Type Value
# TTL=300 means this answer will be cached for 5 minutes
# Look up a specific record type
$ dig osztromok.com MX
$ dig osztromok.com TXT
$ dig osztromok.com NS
$ dig osztromok.com CNAME
# ── Useful flags ────────────────────────────────────────────────
$ dig osztromok.com +short # just the answer, no extra info
82.2.236.221
$ dig osztromok.com +noall +answer # answer section only, cleaner output
# ── Query a specific DNS server (bypass your local resolver) ────
$ dig osztromok.com @8.8.8.8 # ask Google's public resolver
$ dig osztromok.com @1.1.1.1 # ask Cloudflare's public resolver
$ dig osztromok.com @ns1.ionos.co.uk # ask IONOS directly (authoritative)
# Asking the authoritative server directly shows the "true" value
# without any resolver caching. Useful when checking if your change
# has taken effect at the source before waiting for propagation.
# ── Trace the full resolution chain ─────────────────────────────
$ dig osztromok.com +trace
;; Received 97 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms
;; Received 172 bytes from 192.5.6.30#53(a.gtld-servers.net) in 8 ms
osztromok.com. 300 IN A 82.2.236.221
;; Received 62 bytes from 212.227.123.16#53(ns1.ionos.co.uk) in 14 ms
# Shows every step: root → .com TLD → IONOS authoritative → answer
# ── Find which nameservers are authoritative for a domain ────────
$ dig osztromok.com NS +short
ns1.ionos.co.uk.
ns1102.ui-dns.org.
# ── Check TTL on a cached record ─────────────────────────────────
# Query the same record twice — the second TTL will be lower if cached
$ dig osztromok.com +noall +answer
osztromok.com. 298 IN A 82.2.236.221
# TTL=298 (not 300) means your resolver cached this 2 seconds ago
# ── Windows: nslookup ───────────────────────────────────────────
C:\> nslookup osztromok.com
C:\> nslookup -type=MX osztromok.com
C:\> nslookup osztromok.com 8.8.8.8 # query Google instead of local resolver
Scenario — Diagnosing Why a Domain Isn't Working
Scenario · Chapter 1
Your website was working yesterday but is unreachable today. You haven't changed anything on the server. Use dig to systematically identify whether this is a DNS problem.
1
Find out what IP the domain currently resolves to.
$ dig osztromok.com +short
82.2.236.221
# Note this IP — you'll compare it to the server's actual IP next.
2
Confirm what IP your server actually has right now.
$ curl ifconfig.me
86.11.204.43
# The server's public IP is 86.11.204.43 but DNS says 82.2.236.221.
# The IP has changed (common on residential connections without a static IP).
# This is a DNS problem — the A record needs updating.
3
Check the TTL to know how long the fix will take to propagate.
$ dig osztromok.com +noall +answer
osztromok.com. 82847 IN A 82.2.236.221
# TTL=82847 seconds (~23 hours) — the old IP could be cached for nearly a day.
# Update the A record in IONOS immediately, but also lower the TTL to 300
# so anyone who queries fresh will get the new address quickly.
4
After updating the record, confirm the authoritative server has the new value.
# Find the authoritative nameserver first
$ dig osztromok.com NS +short
ns1.ionos.co.uk.
# Query it directly — no caching
$ dig osztromok.com @ns1.ionos.co.uk +short
86.11.204.43
# Good — the authoritative server already has the new IP.
# The rest of the world will catch up as their cached copies expire.
5
Flush your local cache to see the new value immediately on your own machine.
# Linux (systemd-resolved)
$ sudo systemd-resolve --flush-caches
# macOS
$ sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Windows (run as Administrator)
C:\> ipconfig /flushdns
This is exactly what happened with osztromok.com earlier in this session — the server's IP changed after the router reset, but the DNS record still pointed to the old address. Dynamic IPs are covered in depth in Chapter 7 (Dynamic DNS with DuckDNS and ddclient), which automates this update process.
Quick Reference — Chapter 1
| Command / Concept | Purpose | Notes |
|---|---|---|
| dig domain.com +short | Quick A record lookup — returns just the IP | Add MX, TXT, NS, CNAME to look up specific record types |
| dig domain.com @8.8.8.8 | Query a specific resolver (bypass local cache) | Use @ns1.ionos.co.uk to query your authoritative server directly |
| dig domain.com +trace | Show the full resolution chain from root → TLD → authoritative | Useful for diagnosing delegation problems |
| dig domain.com +noall +answer | Show only the answer section including TTL | TTL decreasing between queries confirms the resolver is caching |
| curl ifconfig.me | Your server's current public IP address | Compare to dig output — a mismatch means the A record needs updating |
| A record | Domain → IPv4 address. The core record every website needs. | Use AAAA for IPv6. Both can exist simultaneously. |
| CNAME record | Domain → another domain name (alias) | Cannot be used at the root/apex domain. Cannot coexist with other records. |
| MX record | Where to deliver email for the domain | Has a priority number — lower = higher priority. Multiple allowed. |
| NS record | Which servers are authoritative for the domain | Set at your registrar. Changing this = moving DNS to a new provider. |
| TTL | How long resolvers cache a record (in seconds) | Lower TTL before making changes. 300 = 5 min, 3600 = 1 hr, 86400 = 24 hr. |