Nameservers vs Hosting: Stop Mixing the Two

Ask someone where their website is hosted and you will usually get a straight answer. Ask them who runs their DNS and you will often get a blank look, followed by the name of their web host — which may be correct, or may be an assumption that has been quietly wrong for two years.

The two jobs sound similar and are completely independent. Almost every migration disaster I have seen came from treating them as one thing.

What nameservers actually do

Nameservers answer DNS queries for your domain. They hold your zone — the collection of A, AAAA, CNAME, MX, TXT and other records — and they are the authoritative source of truth for it. When a resolver somewhere in the world wants to know where your website lives, these are the machines that give the final answer.

Crucially, nameservers know nothing about your website's files. They are a directory service. They will happily tell the world that example.com points at an IP address that has been switched off for six months.

Who runs them is a choice, not a consequence. Your registrar may run them by default. Your web host may offer them. Or you may use a dedicated DNS provider, which is common once a domain needs fast propagation, DNSSEC, or traffic steering.

What hosting actually does

Hosting stores and serves your actual site: the files, the application, the database. It has an IP address, and something somewhere points a name at that address.

That "something somewhere" is the only connection between the two worlds, and it is a single A or CNAME record. Everything else is separate.

The four combinations

Because the two are independent, there are four situations you can be in, and it helps to know which one you are in before you change anything.

You can keep both where they are and change nothing. You can move hosting and leave DNS alone — you update one A record and delegation never changes. You can move DNS and leave hosting alone — you copy the zone and change nameservers at the registrar, and no IP addresses change. Or you can move both, which is two projects that must not be run at the same time.

Most outages happen because someone believed they were doing the second and were actually doing the third, or vice versa.

The classic failure

Here is the scenario, which is depressingly common.

A team decides to move DNS to a new provider. They carefully build the zone there. They update the nameservers at the registrar. Delegation now points at the new provider, and everything works.

A week later someone notices a subdomain is broken. They open the old provider's control panel — the one the team used for years — and fix it there. The change has no effect, because that provider is no longer authoritative for anything. Worse, the fix is now in a place nobody will think to look, and the real zone still has the problem.

The mirror image is just as common. Someone moves hosting but keeps DNS at the old provider, then wonders why the new server is not receiving traffic. The A record was never updated, so the world is still being sent to the old address.

Both failures share a root cause: nobody confirmed which system was authoritative before editing.

Finding out who is actually in charge

There is one question that resolves this permanently: who answers authoritatively for the zone, right now?

Check the NS records for your domain. Those name the servers that hold the truth. Then compare them against the panel you are about to edit. If the panel is not the one operating those nameservers, your edits are notes in a notebook nobody reads.

Do this before every DNS-related change, and specifically after any migration. It takes a few seconds and it prevents the entire class of failure above. Try it on DNS Checkers Domain Health Check

Moving hosting without touching DNS

This is the easy one, and it should stay easy.

Confirm the new server is working by testing it directly — by IP, or with a hosts file entry on your own machine. Then lower the TTL on the A or AAAA record that points at the site, wait out the old TTL, and update the address. Delegation never changes, so nothing about authority is in question.

The records that matter here are the web ones. If mail also lives on that server, you have a second, separate migration on your hands, and it should be scheduled on its own.

Moving DNS without touching hosting

Also straightforward, with one rule: copy everything before you switch anything.

Export the full zone from the current provider, not just the records you remember. Build the complete zone at the new provider and compare the two as text. Then lower TTLs, wait, and change the nameservers at the registrar.

Nothing about your IP addresses changes, so if the new zone is a faithful copy, no user should notice anything. If something breaks, the most likely cause is a record that did not survive the copy.

Moving both, in the safe order

Do them one at a time, hosting first.

Move the site, verify it, and let the web records settle. Then move DNS. Trying to change both at once means that when something breaks you are debugging two migrations with one set of symptoms, and you cannot tell which change caused what.

If you genuinely must do both, at least separate them by a full TTL window and take a verified backup of the zone between the two steps.

What breaks when the two disagree

When delegation and zone content disagree, the symptoms are specific, and recognising them speeds up diagnosis considerably.

If delegation points at nameservers that are not answering, the whole domain disappears — no website, no mail, nothing resolves at all. That is a hard failure, and it is usually obvious within minutes.

If delegation points at the correct nameservers but the zone there is incomplete, you get the quieter failure: the site loads, but mail bounces, or a subdomain has vanished, or a verification record is missing. The domain is technically "up", which is exactly why these take longer to notice.

If you are editing a provider that is no longer authoritative, you get the strangest symptom of all — changes that have no effect whatsoever, with the interface cheerfully reporting success each time. Nothing is broken. You are simply writing into a copy that nobody reads.

The first of those three is loud, the second is quiet, and the third is invisible. Of the three, the invisible one wastes the most time.

Where the registrar fits

The registrar is the middleman, and its role is easy to forget until it bites.

The registrar does not answer DNS queries. What it does is hold the delegation: it tells the top-level domain which nameservers are authoritative for you. When you "change your nameservers", you are editing that delegation, not the zone.

That distinction matters during migrations because the delegation is a separate system with its own propagation. Your zone can be perfect at the new provider while the delegation still points at the old one, and during that window the pair of them are not yet connected.

The records people lose

When copying a zone, the same handful of records goes missing almost every time.

CAA records, which restrict which certificate authorities may issue for you — lose them and renewals fail weeks later. Delegation records for subdomains, which quietly hand part of your zone to another provider. Verification TXT records for search consoles, payment providers and monitoring services, which fail silently. And DMARC reporting addresses, which point at a mailbox that may not exist after the move.

None of these announce themselves. That is exactly why they belong on a checklist rather than in someone's memory.

Keeping a written record

A surprising number of incidents come down to nobody remembering which provider holds what. A short note in your runbook — registrar, nameservers and where they are operated, DNS provider, hosting provider, and the date of the last change to each — removes that uncertainty permanently.

Write the delegation down separately from the zone, because they are the two things people confuse under pressure. Add the mail provider and the certificate authority settings to the same page: those are the dependencies that fail quietly weeks after a migration, and the ones nobody can reconstruct from memory when something suddenly breaks.

It takes five minutes to write and saves an afternoon the next time somebody asks who actually owns the DNS.

The one-page checklist

Before any change: confirm who is authoritative right now, and export the current zone.

For a hosting move: test the new server directly, lower the TTL on the web records, wait out the old TTL, update the address, verify, then decommission.

For a DNS move: export everything, build the new zone completely, diff the two, lower TTLs, switch delegation at the registrar, monitor, keep the old provider active for at least a week, and only then cancel it.

And after either move: check CAA, subdomain delegations, verification TXT records and your mail records, because those are the ones that break quietly. Try it on DNS Checkers Lookup All DNS Records

Two independent systems, one shared record between them. Keep that picture in your head and you will avoid the mistake that catches almost everyone else.