Nameservers explained: who answers for your domain, and where the records live

Nameservers say who answers for your domain; the records say what those answers are, and mixing up the two layers is how routine moves turn into outages.

The move to a new provider was supposed to be routine. Someone edited the records carefully, saved, and waited for the website to follow. Nothing changed. Hours later the site is still answering from the old place, or worse, answering from nowhere, and nobody can say which of the two layers was actually touched. This is the moment the difference between nameservers and records stops being trivia.

There are two layers, and they answer different questions. The nameservers say who answers for your domain: which service the world should ask when it wants anything about it. The records say what the answers are: where the website lives, where the mail goes, what verifies a sender. Change the records and you change the answers while the same authority keeps answering. Change the nameservers and you change who is asked at all.

That split explains the timing people find mysterious. A record changed at the answering service can take effect quickly, because the authority itself now gives the new answer. A change of nameservers travels differently: the wider world asked the old authority recently and trusted the answer, so it keeps using it until it re-asks. One fix acts in minutes; the other is patient by design. Neither is broken; they run on different clocks.

Moves between providers come in the same two shapes. Some are delegation changes: you point the domain at the new provider's nameservers, and the records travel inside the new panel, already in place. Others mean rebuilding the records by hand at the new home while the delegation still points at the old one. Knowing which move you are making, before you make it, is the difference between a quiet afternoon and an outage.

The practice is short. Before touching records during a move, check the delegation first, and confirm the new nameservers actually answer for the domain. Write down the current answers before changing anything, so the old state can be restored without guesswork. Change one layer at a time, and keep the old panel intact until the new one demonstrably answers. Layers changed together cannot be told apart when something misbehaves.

We manage domains for our clients, and the delegation check is the first thing we do on any move, before a single record is touched. The procedures of a specific registrar or provider belong to that provider's documentation, and we route them there. Guidance, not guarantees: your domain's answers come from a chain of services that has to agree, and the moving parts deserve to be moved one at a time.