Nameservers vs DNS records: who controls what

Three different companies are usually involved in getting a visitor to your website, and people confuse them constantly. The registrar is who you rent the name from and pay every year. The DNS host is who answers queries about that name, and the nameservers are the names of their machines. The web host is where the site actually runs. You can change any one of the three without touching the other two, and most of the fear around "moving a domain" is not knowing which one you are actually moving.

Nameservers and DNS records are two different layers of the same system. The nameservers say who answers. The records are what they answer with. Changing nameservers moves the whole zone to a new provider and every record with it. Changing a record moves one thing - the website, the mail, one subdomain - and leaves everything else where it was. Almost every time somebody says "I need to change my nameservers", what they actually need is to change one A record.

The three jobs, and who usually does each#

By default the registrar is also the DNS host, because they assign their own nameservers when you register the name. That default is why the two feel like one thing. The moment you point the nameservers somewhere else - a managed DNS provider, a CDN, a hosting company that runs its own - the registrar stops having anything to do with your records, and editing records in the registrar's panel has no effect at all. That one sentence explains a large fraction of all DNS support tickets: the customer is editing a zone nobody is serving.

How a lookup finds your server#

When a visitor's resolver has nothing cached, it walks down from the top.

1. It asks a root server where .com is answered. The root replies with the addresses of the .com nameservers. This part is cached for days.
2. It asks a `.com` registry server about example.com. The registry does not know your website - it only knows the delegation, which is the list of NS records your registrar wrote there. It replies with a referral: "ask ns1.dnsprovider.net".
3. It asks your nameservers for the record it actually wanted, and gets the answer with a TTL attached.
4. It connects to the address in that answer.

Two things follow from step 2, and they are worth holding on to.

The delegation lives at the parent, not in your zone. Your zone also contains NS records at the apex, and they should match, but the ones a resolver follows are the ones the registry hands out. That is why a nameserver change is made at the registrar and cannot be made anywhere else.

The delegation is cached for a long time. A .com referral is handed out with a two-day TTL, so a nameserver change takes up to 48 hours to be visible everywhere, no matter how low you set the TTLs inside your own zone. Record changes are fast because you control their TTL; nameserver changes are slow because you do not. DNS records explained covers the record types and why the cache is the confusing part.

Changing where the website lives#

This is the common case and it is the easy one. The zone stays exactly where it is. You change one record, or two.

1. A day or two beforehand, lower the TTL on the records you will change - example.com and www - from whatever it is to 300.
2. Get the new server fully working and serving the site on its address, before any DNS points at it.
3. Test it under the real hostname without changing DNS. Either add a line to your hosts file, or force the resolution for a single request:

$ curl -I --resolve example.com:443:203.0.113.10 https://example.com/$ curl -I --resolve www.example.com:443:203.0.113.10 https://www.example.com/

1. Change the A record (and AAAA if you have one) to the new address. Leave every other record alone - especially MX and any TXT records for mail, because touching those is how a site migration takes the email with it.
2. Watch both servers' access logs. Traffic drains from the old one over the length of the old TTL.
3. Keep the old server running for at least a day. Some resolvers ignore TTLs and some users have a browser that has been open for a week.
4. Put the TTL back up to something sensible once it is done.

On RE:NODE that new address is the one shown in the proxy slot on app and web plans. Point an A record at it, and the certificate is issued and renewed automatically inside a 21-day window. We do not register domains and we do not host DNS zones, so there is no zone editor here - you make the record at whichever provider your nameservers point at, and we only provide the address it points to. Pointing a domain at your server has the rest of the walkthrough, and www vs apex domain and redirects covers why both names need a record rather than one.

If it is a game server rather than a website, the shape is the same but the record may be an SRV as well as an A - see connecting a domain to a game server.

Changing who holds the zone#

Moving to a new DNS provider is a nameserver change, and it moves everything at once. Done carelessly it takes mail down along with the website, because mail records live in the same zone.

1. Export the current zone. Most providers offer a zone file export; if not, list every record by hand, including MX, every TXT (SPF, DKIM selectors, DMARC, domain verifications) and every subdomain. Verification TXT records that nobody remembers adding are the usual casualty.
2. Recreate the zone at the new provider in full. Do not switch yet.
3. Query the new nameservers directly and compare the answers with the old ones, record by record:

$ dig @ns1.newprovider.net example.com A +short$ dig @ns1.newprovider.net example.com MX +short$ dig @ns1.newprovider.net _dmarc.example.com TXT +short

1. Check DNSSEC. If the domain is signed, there is a DS record at the registry with your current provider's key in it. Moving nameservers without handling that gives validating resolvers a broken chain, and they return SERVFAIL - which is not "slow propagation", it is your domain being unreachable for a large slice of the internet. Either remove the DS record at the registrar and wait out its TTL before switching, or do a proper multi-signer rollover if both providers support it.
2. Change the nameservers at the registrar. This is the only step that happens there.
3. Leave the old zone in place, unchanged, for at least a week. Resolvers that cached the old delegation keep asking the old nameservers, and while those answer correctly nobody notices anything.

The window where both sets of nameservers are in play is exactly why step 2 matters: if both answer identically, the cutover is invisible. If they differ, some visitors get one answer and some the other, with no pattern you can debug.

Changing who you rent the name from#

A registrar transfer moves the billing relationship and nothing else. If your nameservers point at a third party, a transfer does not affect your records, your website or your mail at all. If your nameservers are the old registrar's, plan the DNS move first and separately, because a losing registrar has no obligation to keep serving DNS for a name they no longer hold.

The steps are the same at every registrar for .com, .net and .org:

1. Unlock the domain - the registry status clientTransferProhibited has to come off.
2. Make sure the registrant email address on file is one you can read, because the approval goes there.
3. Get the authorisation code, sometimes called the EPP code or auth code.
4. Start the transfer at the new registrar and pay. For most generic domains, a transfer adds a year to the registration.
5. Approve it. It can take up to five days to complete if nobody clicks anything, because the losing registrar has that long to act.

Two locks catch people. A domain cannot be transferred within 60 days of registration, or within 60 days of a previous transfer. Changing the registrant contact details also starts a 60-day lock at most registrars unless you opt out during the change. Check the dates before you promise anyone a migration window.

Renewal is the other thing that lives only at the registrar, and it is worth a calendar entry: an expired domain stops resolving regardless of how healthy the DNS and the hosting are. Every record, every certificate and every mail policy is downstream of the name still being yours.

Reading the delegation yourself#

You can see all of this from the outside, which means you never have to guess whose panel to log into.

# What the registry says: the authoritative nameservers$ dig NS example.com +short# What the zone itself says, asked of one of those nameservers$ dig @ns1.dnsprovider.net NS example.com +short# The whole walk, root to answer$ dig +trace example.com# Serial numbers from each nameserver, to see if they agree$ dig @ns1.dnsprovider.net SOA example.com +short$ dig @ns2.dnsprovider.net SOA example.com +short

On Windows without dig installed, PowerShell does the same job:

Resolve-DnsName example.com -Type NS -Server 8.8.8.8Resolve-DnsName www.example.com -Type A -Server 1.1.1.1

whois example.com shows the registrar's name and the nameservers as recorded at the registry, which is the definitive answer to "where do I change this". If whois and dig NS disagree, the change is mid-flight and you are looking at caching.

The SOA serial comparison is the most underused of these. Every nameserver serving a zone should report the same serial. Two different serials mean one of them has not picked up your last edit, and if you are debugging a record that "works sometimes", that is the reason.

Vanity nameservers and glue records#

If you run nameservers named after your own domain - ns1.example.com serving example.com - there is a bootstrap problem. To find ns1.example.com a resolver has to ask the nameservers for example.com, which is what it was trying to find. The answer is a glue record: an A record for the nameserver stored at the registry alongside the delegation, so the referral carries the address with it.

Glue is created at the registrar, usually under a heading like "register a nameserver" or "host records", and it is separate from the A record inside your zone. Both need to exist and both need to agree. If you change the address of a vanity nameserver and only update the zone, the glue keeps sending resolvers to the old machine and you get intermittent failures that clear up for you personally because your resolver happens to have the zone's own answer cached.

Unless you have a specific reason - a hosting brand, or a policy about which names appear in whois - vanity nameservers are not worth the extra failure mode. Use your DNS provider's names.

Where this goes wrong#

Editing records at the wrong provider. The registrar's DNS panel still shows a zone after you have pointed the nameservers elsewhere. Nothing you type there matters. Confirm with dig NS before editing anything.

A lame delegation. The NS records point at a nameserver that does not serve the zone - usually a leftover from a provider you stopped paying. Resolvers try it, get REFUSED, and fall back to the others, so the site works but every lookup is slower and some resolvers give up entirely. Remove nameservers you no longer use.

Mail lost during a website move. The MX record and the SPF TXT record were recreated wrong, or not at all, when the zone was rebuilt at a new provider. Mail failures are silent on your side - senders get the bounce, you get nothing. Check MX and every mail TXT record immediately after any zone move; SPF, DKIM and DMARC explained lists which ones to look for.

DNSSEC left signed at the old provider. Described above, and worth repeating because it presents as a total outage for some users and a working site for others, which is the hardest failure mode to diagnose over a ticket.

The TTL that was never lowered. A record with a 24-hour TTL changed at 09:00 is still serving the old answer at 08:00 the next day, for anyone who asked in the meantime. There is no way to flush other people's resolvers. Plan around it or lower it in advance.

A certificate issued before the record was right. Issuance validates that the name points at the server asking for the certificate. If the A record still resolves to the old host, it fails, and the error message is about the challenge rather than about DNS. Fix the record, wait out the TTL, try again.

FAQ#

Do I need to change nameservers to move my website?

No. Change the A record - and AAAA if you have one - to the new server's address. Nameservers only need to change if you are moving to a different DNS provider. Moving hosting and moving DNS are separate decisions and are easier done separately.

Can my registrar and my DNS provider be different companies?

Yes, and for anything important they usually should be. You register the name in one place and point the nameservers at another; the registrar then only handles renewal, the delegation and transfers. Nothing about your records is affected.

How long does a nameserver change take?

Up to 48 hours for .com and most gTLDs, because that is the TTL on the delegation the registry hands out. It is often much faster in practice, but you cannot shorten it, and you should not delete the old zone until the full window has passed.

Why does my DNS change work for me but not for everyone else?

Because your resolver has fetched the new answer and theirs is still inside the old TTL. Test with dig @8.8.8.8 and dig @1.1.1.1 as well as your own resolver, and compare the SOA serial across your nameservers in case one of them simply has not been updated.

What happens to my email if I change web hosts?

Nothing, as long as you only change the A record for the website. MX records and mail TXT records are separate entries in the same zone, and mail is delivered to whatever MX says. Problems only arise when a zone is rebuilt from scratch at a new DNS provider and those records are forgotten.

Does RE:NODE provide nameservers or register domains?

No. We do not register domains, run nameservers or host DNS zones, and there is no zone editor in the panel. You keep the domain with your registrar and the zone with whatever DNS provider you prefer, and point a record at the address the proxy slot gives you.