DNS — the internet's phonebook

Nobody remembers phone numbers any more — you just tap a name. DNS is the same trick for the internet: you type a name, and something behind the scenes quietly looks up the number.

So what is DNS, really?

Every server on the internet is found by a number — its IP address, something like 203.0.113.10. Nobody wants to type numbers, so we gave servers names like example.com. DNS (Domain Name System) is the giant, always-on lookup service that turns those names back into numbers, millions of times a second, so your browser knows which machine to actually talk to.

It's your phone's contact list

You tap "Mum", not +44 7700 900123. Your phone quietly swaps the name for the number and places the call. DNS does exactly that for the web — you type github.com, DNS hands back 140.82.114.4, and off you go.

What happens when you open a website

One DNS lookup, step by step

Your laptop asks once. The resolver does all the running around.

Here's the whole trip in plain words. You type example.com. Your computer asks a resolver (usually your ISP's, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). The resolver doesn't magically know the answer — it walks a chain: it asks a root server ("who handles .com?"), then the .com servers ("who handles example.com?"), then finally the server that actually holds your domain's records — the authoritative server. It grabs the IP, remembers it for a while, and hands it back. All of this usually finishes in a few milliseconds.

Which record do I use for what?

This is the part support folks and developers ask about most. A domain's DNS settings are just a list of records, and each type has a job. Here's the cheat sheet — the one you'll keep coming back to.

Record	Use it when you want to…	Real example
`A`	Point a domain to a server by its IPv4 address. This is the everyday one — connecting a domain to a VPS, a hosting box, a load balancer.	`example.com → 203.0.113.10`
`AAAA`	Same as A, but for an IPv6 address.	`example.com → 2606:4700::6810`
`CNAME`	Make one name an alias for another name (not an IP). Great for `www` → apex, or pointing at a platform's hostname (Netlify, Vercel, a CDN, a load balancer's DNS name).	`www.example.com → example.com`
`TXT`	Prove you own the domain, and configure email. Domain verification (Google, Microsoft, Facebook, SSL issuers), plus `SPF`, `DKIM`, and `DMARC` for email all live in TXT records.	`google-site-verification=abc123…`
`MX`	Decide where email for this domain goes. Points at your mail provider (Google Workspace, Microsoft 365, Zoho…).	`example.com → aspmx.l.google.com` (priority 1)
`NS`	Say which nameservers are in charge of the domain. This is what you set at the registrar when you move DNS to Cloudflare, Route 53, etc.	`example.com → ns1.cloudflare.com`
`SRV`	Point at a service on a specific host + port. Used by things like Microsoft Teams, SIP, Minecraft, and service discovery.	`_sip._tcp.example.com → sip.example.com:5060`
`CAA`	Restrict which certificate authorities may issue SSL certs for your domain — a small but nice security lock.	`example.com → 0 issue "letsencrypt.org"`
`PTR`	The reverse lookup — turn an IP back into a name. Mostly set by whoever owns the IP block; matters for mail server reputation.	`203.0.113.10 → mail.example.com`

The 30-second version

A = point a name at a server IP. CNAME = point a name at another name. TXT = verify ownership + email security. MX = where email goes. NS = who runs the DNS. Learn those five and you'll handle almost every real ticket that comes your way.

A vs CNAME — the one people mix up

Both "point" a domain somewhere, so it's easy to confuse them. The difference is simple:

An A record points at an IP address — a number. Use it when you have a server's IP (a VPS, a dedicated box).
A CNAME points at another domain name — text. Use it when your host gives you a hostname instead of an IP (e.g. myapp.up.railway.app or d1234.cloudfront.net).

You usually can't CNAME the root domain

Classic gotcha: you can't put a CNAME on the bare example.com (the "apex" or "root"), because it clashes with the required NS and other records. You can only CNAME subdomains like www. If a host hands you a hostname for the apex, use their "ALIAS" / "ANAME" / "CNAME flattening" feature (Cloudflare, Route 53, and most modern DNS providers have it) or fall back to an A record with their IP.

TTL — why DNS changes "take time"

Every record carries a TTL (time to live), measured in seconds. When a resolver looks something up, it caches the answer for that long before asking again. So if the TTL is 3600 (one hour), a change you make can take up to an hour to reach everyone — their resolvers are still holding the old value. That's the whole reason "DNS propagation" is a thing; nothing is broken, it's just cached.

For the support team — a migration trick

Moving a customer's site to a new server tomorrow? Today, lower the TTL on the record you're going to change to 300 (5 minutes). Wait for the old TTL to expire, then do the switch. Now the change lands in 5 minutes instead of an hour — much less "it's still showing the old site" back-and-forth. Once things are stable, bump the TTL back up to 3600+ so lookups stay fast and cheap.

For the support team: pointing a customer's domain at our server

This is the single most common DNS task. Here's the whole thing, no assumptions:

Get the server's public IP. That's the IPv4 address of the VPS / hosting box you want the domain to land on — e.g. 203.0.113.10.
Find where the domain's DNS is managed. Not always the registrar! If the nameservers (NS records) point at Cloudflare, you edit records in Cloudflare — not at GoDaddy where they bought it. Check with dig NS thedomain.com.
Add or edit the A record for the bare domain: name @ (or the domain itself) → the server IP.
Handle www. Add a CNAME for www → the bare domain (so www.thedomain.com follows along), or a second A record for www → the same IP.
Wait for the TTL, then test: dig +short thedomain.com should return your server IP.
Only then issue the SSL certificate — the cert step checks DNS, so it has to be pointing correctly first. (Full walkthrough on the Point a Domain to a VPS page.)

"I changed it but the old site still shows"

Nine times out of ten it's one of three things: (1) the TTL hasn't expired yet, (2) you edited DNS at the registrar but the domain actually uses different nameservers, or (3) the customer's browser or router cached it. Check the real answer with dig +short thedomain.com and compare it to the server IP before touching anything else.

Where your computer looks before it even asks DNS

Before hitting a DNS server, your machine checks a couple of local shortcuts:

The hosts file — /etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows. Anything here wins over real DNS. Perfect for testing a new server before you flip DNS for real.
The OS cache — recent lookups it already remembers.
The configured resolver — only if the above two don't answer.

Test a new server before going live

Want to confirm the new server serves the site correctly before pointing real DNS at it? Add a line to your hosts file so only your machine resolves the domain to the new IP:

203.0.113.42  thedomain.com  www.thedomain.com

Load the site, confirm it works, then remove the line and do the real DNS change with confidence.

Try it yourself

# What IP does a domain resolve to?
dig +short example.com

# Who manages this domain's DNS?
dig NS example.com

# Where does its email go?
dig +short MX gmail.com

# See the answer WITH the TTL (the number before "IN")
dig example.com

# Ask a specific resolver (bypass your ISP's cache)
dig @1.1.1.1 example.com

# On Windows
nslookup example.com
nslookup -type=MX gmail.com

DNS inside the cloud and Kubernetes

The same idea shows up on the inside. Cloud VPCs run private DNS so servers can find each other by name (my-db.internal) without touching the public internet. In Kubernetes, CoreDNS gives every Service a name like db-svc.default.svc.cluster.local — which is exactly why pods talk to each other by name instead of by ever-changing IPs. Same phonebook, smaller building.

Key takeaways

DNS turns names into IPs so you never have to memorise numbers.
The resolver walks root → TLD → authoritative; your device just asks once.
A = point at an IP · CNAME = point at a name · TXT = verify + email · MX = mail · NS = who runs DNS.
TTL controls caching — lower it before a planned change, raise it after.
For support: always confirm where DNS is managed, then verify with dig +short before blaming anything else.