What is DNS? How the internet's address book works
Kofi Agyem, Founder and CEO, CloudzyroPublished · 7 min read
On this page
- 1. DNS in one paragraph
- 2. What happens when you type a web address
- 3. The servers involved
- 4. The DNS records you'll meet
- 5. TTL, caching and propagation
- 6. Nameservers: who holds your records
- 7. A worked example: pointing a domain at a site
- 8. Common DNS mistakes
- 9. How to check your DNS
- 10. Sources and further reading
DNS turns names like example.com into the addresses computers use. How a lookup works, the main record types, TTLs, propagation and how to check yours.
1. DNS in one paragraph
DNS, the Domain Name System, is the internet's address book. It turns names people can remember, like example.com, into the numeric IP addresses computers use to reach each other, like 203.0.113.10. Every time you open a website or send an email, your device asks DNS where to go first, usually in a few milliseconds.
Without DNS you'd have to type a string of numbers to visit any site, and every site would have to keep the same server address forever. DNS adds a layer in between: the name stays the same while the address behind it can change.
2. What happens when you type a web address
Say you type www.example.com into your browser. Behind the scenes:
- Your device checks its own memory. Browsers and operating systems keep recent answers for a while. If it already knows the address, it uses it and stops here.
- It asks a resolver. If not, it asks a recursive resolver: usually your internet provider's, your router's, or a public one like
1.1.1.1. The resolver's job is to find the answer for you. - The resolver asks a root server. Root servers don't know
www.example.com, but they know who runs.com, and they say so. - It asks the .com servers. These don't know the answer either, but they know which nameservers hold the records for
example.com. - It asks the domain's nameservers. These are authoritative: they hold the real records, and they answer with the address for
www.example.com. - The answer comes back and is remembered. The resolver hands the address to your browser and keeps a copy for as long as the record's TTL allows, so the next person who asks gets it straight away.
- Your browser connects. Now it can open a connection to that IP address and ask for the page.
In practice the resolver has usually cached the root and .com answers already, so most lookups take one or two steps, not five.
3. The servers involved
- Recursive resolver: does the legwork on your behalf and caches answers. Run by internet providers, companies and public services.
- Root servers: the starting point. There are 13 named root server identities (
a.root-servers.nettom.root-servers.net), each copied to many locations around the world. - TLD servers: run by the registry for each ending, like
.com,.orgor.uk. They point to each domain's nameservers. - Authoritative nameservers: hold a domain's records. Whoever runs these, often your registrar, your host or a DNS provider like Cloudflare, is where you edit your records.
4. The DNS records you'll meet
A domain's records are a short list of entries, each with a name, a type, a value and a TTL. These are the common ones:
- A: points a name to an IPv4 address, like
203.0.113.10. - AAAA: the same for an IPv6 address.
- CNAME: makes a name an alias of another name. See A record vs CNAME.
- MX: says which servers receive email for the domain. See What is an MX record?.
- TXT: free text, used to prove you own a domain and for email security (SPF, DKIM, DMARC).
- NS: names the domain's authoritative nameservers.
- CAA: lists which certificate authorities may issue HTTPS certificates for the domain.
Here's what a small domain's records might look like, written the way DNS servers store them:
example.com. 3600 IN A 203.0.113.10
www.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.example.net -all"The 3600 is the TTL in seconds (one hour). IN means internet, and you can ignore it. Most dashboards show the same thing as a table with Type, Name, Value and TTL columns, and use @ for the domain itself.
5. TTL, caching and propagation
Every record has a TTL (time to live): how many seconds resolvers may keep a copy before asking again. Caching is why DNS is fast, and it's also why changes don't show everywhere at once.
People call the wait DNS propagation, but nothing is being pushed out. Your nameservers update straight away; resolvers that cached the old record keep using it until its TTL runs out. A record with a one-hour TTL can take up to an hour to change for someone whose resolver cached it just before you edited it.
Two practical tips:
- Lower the TTL before a planned change. Set it to 300 seconds (5 minutes) a day ahead, make the change, then raise it again.
- Nameserver changes are slower. The servers for
.comand other endings hand out nameserver records with long TTLs, often a day or two, so switching DNS providers usually takes a few hours and occasionally up to a day or two.
6. Nameservers: who holds your records
When you register a domain, you tell the registry which nameservers hold its records. Those servers are the only place your record changes count. A common surprise is editing records at your registrar while the domain's nameservers point somewhere else, such as Cloudflare or an old host: the edits look saved but do nothing.
To find out who runs your DNS, look up the NS records (see below). With Cloudzyro Web Hosting, for example, a domain uses ns1.cloudzyroserver.com and ns2.cloudzyroserver.com, and its records are edited in cPanel's Zone Editor.
7. A worked example: pointing a domain at a site
Say you own mybakery.com, your DNS is at your registrar, and you want it to show a site hosted on Cloudzyro Sites & Apps. You'd add two records:
Type Name Value
CNAME www domains.cloudzyro.app
A @ 173.234.137.167The CNAME makes www.mybakery.com an alias for Cloudzyro's address, so if the servers behind it ever change, your record doesn't have to. The A record on @ (the bare domain) points to a server whose only job is to send visitors who type mybakery.com to https://www.mybakery.com. Within minutes, resolvers start returning the new answers, and the site gets an HTTPS certificate automatically.
The full walkthrough is in How to point your domain at your site. If you buy the domain in Cloudzyro Domains, you skip this: choose the site on the domain's page and the records are set for you.
8. Common DNS mistakes
- Editing records in the wrong place. Check the NS records first and edit where they point.
- Two records fighting over one name. A name with a CNAME can't have any other record. Delete the old A record or parking record before adding the CNAME.
- Typing the full name where the provider adds it for you. Entering
www.example.comas the name at a provider that appends the domain gives youwww.example.com.example.com. If unsure, look at how existing records are shown. - Deleting email records by accident. Changing nameservers replaces every record, including MX and TXT. Copy them to the new provider first.
- Expecting instant changes everywhere. Check with a few resolvers before deciding something's wrong.
- A proxy in the way. If your DNS is at Cloudflare and your host asks for DNS only, switch the record's cloud to gray.
9. How to check your DNS
On a Mac or Linux, dig is built in. On Windows, use nslookup, which works everywhere. These ask the question and show the answer:
# The address for a name
dig +short www.example.com
# Ask a specific resolver, to compare with your own
dig +short www.example.com @1.1.1.1
dig +short www.example.com @8.8.8.8
# Who holds the domain's records
dig +short NS example.com
# Follow the whole chain from the root
dig +trace www.example.com
# Windows
nslookup www.example.com
nslookup -type=NS example.comIf dig shows the new value when you ask the domain's own nameserver (dig www.example.com @ns1.yourprovider.com) but the old value elsewhere, your change is saved and resolvers are still holding the old answer. Wait for the TTL.
To flush your own computer's cache: on Windows run ipconfig /flushdns; on a Mac run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
If a domain on a Cloudzyro site isn't working, the site's Domains tab tells you what it found, and the domain troubleshooting guide explains each message.