Module 2 · 2.1

English

Nederlands English Deutsch Français Dansk Español Svenska Italiano Polski Português Română Čeština Ελληνικά Български Hrvatski Norsk Lietuvių Slovenščina

Nameservers and records: the difference

Module 2: Nameservers and zones · Reading time: 7 minutes

Learning objective: After this lesson, you can work out where a domain's DNS is managed, and explain why a change in the wrong place does nothing.

Key concepts: nameserver (NS), zone, records, delegation, "whoever runs the nameservers manages the DNS"

Two questions people mix up

DNS always comes down to two separate questions:

Who manages the DNS of this domain? The answer is the nameservers.
What is in the DNS of this domain? The answer is the records, such as A, MX and TXT.

Here's a comparison: the nameservers are the address of the archive where your domain's phone book is kept. The records are the entries in that phone book. If you want to change an entry, you need to be at the right archive. Editing a copy of the phone book in a different archive is pointless: nobody looks there.

Nameservers: where the phone book is kept

The registry keeps a list of nameservers for every domain. In lesson 1.4 you saw that a resolver is pointed to those nameservers via the TLD. For example:

example.com.   NS   ns1.hosting.example.
example.com.   NS   ns2.hosting.example.

Every domain has at least two nameservers. If one fails, the other answers. Many registries, including SIDN (the registry for .nl in the Netherlands), require this. They're often placed in different networks or data centres.

You set the nameservers via your registrar (lesson 1.3). The registrar passes them on to the registry. Only then does the world start pointing to those nameservers.

The zone: what's in the phone book

The nameservers hold the zone of your domain: the collection of all records. A zone might contain, for example:

example.com.        3600  IN  A      192.0.2.10
example.com.        3600  IN  AAAA   2001:db8::10
www.example.com.    3600  IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mail.example.com.
mail.example.com.   3600  IN  A      192.0.2.25
example.com.        3600  IN  TXT    "v=spf1 mx ~all"

You'll learn exactly how to read a line like this in lesson 2.2. What each record type does is covered in modules 3 to 5.

The golden rule

Whoever runs the nameservers manages the DNS.

That sounds obvious, but in practice this is where things often go wrong. A few recognisable situations:

You registered your domain with provider A, but your nameservers point to Cloudflare. In that case, you change your records at Cloudflare. The DNS screen at provider A may still show records, but nobody reads them.
You had a website built on a platform such as Wix, and pointed the nameservers to that platform. The platform then manages your entire DNS, including your email records. So you need to set the MX records and other email records there. Forget that, and your mail will stop arriving.
Your hosting company shows a DNS zone in a panel, but your domain uses the nameservers of your previous provider. In that case, changes at your new hosting company do nothing until you switch the nameservers over.

The symptom is always the same: you change a record, you wait, and nothing happens. The first question to ask then is: am I changing it in the right place?

How to work out where the DNS is managed

Look up the nameservers. Use an online DNS lookup tool, or in a command prompt:
```
nslookup -type=ns example.com
```
or
```
dig NS example.com +short
```
Check the name to see who it is. Nameservers usually have the provider's name in them. *.ns.cloudflare.com is Cloudflare, ns*.wixdns.net is Wix, and you'll recognise your hosting company's nameservers by their domain name.
Change the records with that provider. That's where you log in and edit the zone.

A second check is the domain's whois (lesson 1.3). This shows the nameservers as registered with the registry: that's what the world uses. If the answer from the nameservers themselves differs from this, something isn't set up correctly.

Copying records is not the same as moving

If you change the nameservers, the records don't automatically come along. The new provider starts with an empty zone, or with a default zone of its own design. You need to recreate what was in the old zone yourself. If you forget the DKIM record or a verification record for Microsoft 365, for example, that part will stop working after the switch.

So the rule is: first prepare the zone with the new provider, only then change the nameservers. Lessons 2.3 and 6.3 go into this in more detail.

In practice: what this looks like in a panel

In My WebOké, the domain page's DNS tab shows at the top which nameservers the domain uses. If different nameservers are shown than those of the hosting provider, the panel will indicate that the DNS is managed elsewhere. In DirectAdmin, you'll see the NS records listed in the zone under DNS Administration. Note: these only show what's in the zone, not what's registered with the registry. Other panels, such as cPanel, Plesk or your registrar's panel, show the same information, usually under a heading like "Nameservers" or "DNS".

Summary

Nameservers determine who manages the DNS; records determine what's in it.
Every domain has at least two nameservers, set via the registrar.
The zone is the collection of records held on the nameservers.
Whoever runs the nameservers manages the DNS: changing things elsewhere does nothing.
When switching nameservers, records don't come along automatically: prepare the zone first, then switch.

Quiz

Exercise

Exercise Z2.1: Who manages the DNS? Look up the nameservers for wikipedia.org and for your own domain (if you have one). Enter them, and note which provider you'd need to change the DNS with for your own domain.

Cookies at WebOké

Cookie settings

Necessary

Marketing