How does DNS work? Following one request from address to website
DNS turns a name like shop.example.co.uk into the address of a server. Your device asks a resolver; the resolver asks a chain of servers, each knowing a little more, until it reaches the one that holds the domain's records; then it caches the answer. Knowing that chain tells you where every setting lives and which company to log in to when something needs changing.
One request, step by step
Someone types shop.example.co.uk into a browser for the first time today. Here's what happens before the page starts loading.
- The device checks its own cache. If it looked the name up recently and the answer hasn't expired, it uses that and skips the rest.
- It asks a recursive resolver. Usually the one run by the internet provider or a public service the device is set to use. The resolver does the legwork on the device's behalf.
- The resolver asks a root server where to find servers for
.uk. The root doesn't know the answer, but knows who's responsible for each top-level domain. - It asks the
.ukservers aboutexample.co.uk. They reply with the domain's nameservers: the servers its owner has said hold the records. - It asks those authoritative nameservers for
shop.example.co.uk. They return the record: an address (A or AAAA), or a CNAME saying "this name is an alias of another name", in which case the resolver looks that name up too. - The resolver caches the answer for as long as the record's TTL allows, and passes it back to the device.
- The browser connects to the address it was given and asks for the page. From here it's the web server's job, not DNS's.
The design is set out in RFC 1034, the original description of the domain name system: resolvers fetch answers for clients, name servers are authoritative for the parts of the name space they hold, and every record carries a time to live that limits how long it may be cached.
Three places, three jobs
| Place | What it holds | You go there to… |
|---|---|---|
| Registrar | Your registration, renewal date, contact details, and which nameservers the domain uses | Renew, transfer, or point the domain at a different DNS host |
| DNS host | The records: A, AAAA, CNAME, MX, TXT and others | Point a name at a website, set up email, add a verification record |
| Website host | The site's files and its HTTPS certificate | Publish, change content, connect a hostname to a site |
Often the registrar is also the DNS host, which is why the two get confused. But if the domain's nameservers point elsewhere, for example to Cloudflare, that other service is the DNS host, and changes made at the registrar's DNS page are ignored.
Nameservers vs DNS records
Nameservers answer "who holds this domain's records?"; records answer "where does this particular name point?". Changing nameservers moves the whole domain to a new DNS host, and every record you need must exist there first, or email and the website stop working. Changing a record alters one name and leaves everything else alone. For connecting a website, you almost always want to add or change a record, not the nameservers.
Records you'll meet
- A / AAAA
- A name's IPv4 or IPv6 address.
- CNAME
- An alias: this name is the same as that name. Can't sit at the bare domain alongside its other records, which is why hosts often ask you to use
wwwor a subdomain. The CNAME vs A record guide covers this. - MX
- Which servers accept email for the domain.
- TXT
- Free text, used for email authentication and for proving to a service that you control the domain.
- NS
- The domain's nameservers.
Mistakes that come from the chain
- Editing records at the wrong company. Check the domain's nameservers first; records only count at the DNS host they name.
- Switching nameservers to fix one record. It moves everything, and anything you didn't recreate breaks.
- Expecting instant changes. Resolvers keep cached answers until the TTL runs out. See how long DNS propagation takes.
- Deleting unfamiliar records. A TXT or MX record you don't recognise is often what keeps email working.
See it for yourself
On macOS or Linux, dig +trace www.example.com walks the chain from the root, printing each step. dig example.com NS +short shows the nameservers, which tells you which company is your DNS host. On Windows, nslookup -type=NS example.com does the same. Running these before you make a change saves most DNS headaches.
Where Anticode fits
Anticode is the website host in the table. When you connect your own domain on a paid plan, Anticode shows a CNAME for your hostname and sometimes a TXT record for ownership; you add them at your DNS host. Verification and the HTTPS certificate are handled through Cloudflare for SaaS. Anticode isn't a registrar or a DNS host, so renewals, nameservers and email records stay with whichever companies hold them now.
Questions people ask
Is my registrar the same as my DNS host?
Often, but not always. Look up the domain's nameservers. If they belong to your registrar, it's also your DNS host; if they belong to another company, make record changes there.
Why do different people see different results after a change?
Their resolvers cached the old record at different times, and each keeps it until its TTL expires.
Does DNS affect my email?
Yes. MX and TXT records in the same zone route and authenticate email, so changes to nameservers or careless deletions can stop mail.