Three jobs, and why they are constantly confused
Almost every my-domain-is-broken question resolves to a misunderstanding of which of three parties owns the problem. The registry operates the extension and holds the authoritative record of every domain under it. The registrar is the retailer you buy from, and the only party that can write to that record on your behalf. The DNS host runs the nameservers that actually answer queries for your zone.
These are frequently three different companies. They are also frequently the same one: most registrars bundle basic DNS hosting and set their own nameservers by default, which is why so many people believe the registrar is the DNS. Either arrangement is fine. What is not fine is not knowing which you have, because the three roles fail in different ways and are fixed by different people.
What the registrar actually controls
The registrar holds an accreditation agreement with ICANN for gTLDs, a contract with the relevant registry, or both, and writes your domain's record into the registry database. ICANN describes an accredited registrar as an entity offering registration services with direct access to the gTLD registries, which is the wholesale structure in a phrase: for most extensions you cannot buy from the registry directly.
What the registrar controls is a specific and limited list: who is listed as the registrant, which nameservers are delegated, whether the domain is locked, whether it auto-renews, and the DS record used for DNSSEC. Your legal relationship for the domain is with the registrar, governed by a registration agreement between you and them.
What the registrar does not necessarily control is a single DNS record. If you have delegated the domain to someone else's nameservers, the registrar's DNS panel is an empty room. You can edit it all day and nothing you type will ever be served.
What the registry holds
The registry operates the top-level domain. It runs the authoritative nameservers for the extension itself, and maintains the master database of every domain registered under it. Verisign operates .com and .net, Public Interest Registry operates .org, and Nominet operates .uk. When a resolver asks who is authoritative for your domain, it is the registry's servers that answer with your delegation.
The registry also holds the status codes that determine what may be done to the domain. Codes prefixed with server, such as serverHold or serverTransferProhibited, are set by the registry and your registrar cannot remove them. Codes prefixed with client are your registrar's own settings, applied on your behalf and removable by them. Reading that prefix tells you immediately who is in a position to help.
Registry-level problems are rare and unmistakable: a server-prefixed status you did not ask for, or an outage affecting an entire extension. Neither is something your registrar can resolve on its own, though the registrar remains your route to the registry.
What the DNS host does
The DNS host is whoever actually answers queries for your zone: the servers holding your A, AAAA, MX, TXT, CAA and SRV records and returning them to resolvers. It might be a dedicated managed DNS provider, a CDN, your web host, your registrar, or servers you run yourself. Nothing about the identity of the DNS host is recorded at the registry; only the hostnames of its nameservers are.
Everything that determines where your website and your email go lives here, not at the registrar and not at the registry. A site resolving to the wrong address, mail that stops arriving, a certificate that will not issue: these are DNS host problems, they are fixed in the zone, and they take effect at the speed of the record's own TTL rather than on any registry timetable.
What changing nameservers does, and what it does not
Changing nameservers changes the delegation: the NS records the registry publishes for your domain, telling the world which servers are authoritative for your zone. You make the change through your registrar, which submits it to the registry. From that point, resolvers asking the extension's servers who is authoritative get the new answer.
It does not move any of your records. Pointing a domain at a new DNS host without first recreating the zone there, meaning every A record, every MX record, SPF and DKIM, CAA and the rest, takes the website and the email offline the moment resolvers pick up the new delegation. The old zone file is not migrated for you. This is the single most destructive routine change a non-specialist makes to a domain.
It also does not change the registrar, does not change the registrant, does not renew the domain, and does not affect any lock, although an active clientUpdateProhibited status or a registry lock will block the nameserver change outright until it is lifted.
Why a nameserver change behaves differently from a record change
A record change happens on servers you already control, and the only delay is the TTL on the record you replaced. A nameserver change happens one level up, in a zone you do not control, and runs on two separate clocks.
The first is registry publication. Once your registrar submits the change, the registry writes it into the extension's zone. Modern gTLD registries publish continuously rather than on the old twice-daily batch schedule, so this is typically minutes rather than hours, though the exact cadence varies by registry.
The second is resolver caching, and it produces the long tail. Resolvers holding the old delegation keep using it until that entry expires, and the governing value is the TTL on the delegation NS records at the extension's servers, not any TTL you set in your own zone. For most gTLDs it is measured in a day or two rather than hours, and the reliable way to know is to query the extension's nameservers directly rather than trust a stated figure. The defensible summary: a nameserver change is usually visible to most of the internet within a few hours and effectively complete within about 48 hours, with the tail governed by cached delegation records rather than by any fixed propagation period.
Three scenarios you will actually face
Moving hosting without moving the domain. Nothing at the registrar or the registry needs to change. You edit the A and AAAA records, plus any apex alias, at your existing DNS host to point at the new server. Lower the TTL on those records well in advance, wait out the old value, then change them.
Moving the domain without moving hosting. An inter-registrar transfer changes who bills you and who can write to the registry record. Before you start, confirm that the gaining registrar will carry your existing nameserver delegation unchanged. A transfer that quietly resets nameservers to the new registrar's defaults takes everything down, because an empty zone at the new provider becomes authoritative. If the domain is signed with DNSSEC, deal with the DS record before the move rather than after.
Using a third-party DNS provider with either. Build the complete zone at the new provider first, verify it by querying their nameservers directly, then change the delegation at the registrar. Apex alias features are proprietary and do not travel between providers, so check that an equivalent exists before you commit to the move.
Working out who is responsible, from a lookup
A WHOIS or RDAP lookup gives you the sponsoring registrar and its abuse contact, the domain's status codes, the creation and expiry dates, the delegated nameservers, and whether the domain is signed with DNSSEC. Under ICANN's Registration Data Policy, operative since 21 August 2025, much registrant personal data is redacted and registrars provide a relay form in place of direct contact details, but every operational field you need for this purpose remains public.
What the lookup does not tell you is who operates those nameservers. You infer that from the hostnames, and it is usually obvious. That single inference is what separates a registrar question from a DNS host question.
The routing rules are short. A domain that has expired, been transferred without permission, or is showing a client-prefixed status is a registrar matter. A website resolving to the wrong address or mail that stops arriving is a DNS host matter. A server-prefixed status, or an entire extension failing, is a registry matter, reached through your registrar. And if you have been changing records at the registrar while the delegated nameservers belong to someone else, nothing you changed was ever being served.
Common questions
What is the difference between a registrar and a DNS host?
The registrar is the company you buy the domain from and the only one that can update the registry record, including the delegated nameservers. The DNS host runs the nameservers that answer queries and holds your actual records. They are often, but not always, the same company.
Does changing nameservers move my DNS records?
No. It only changes which servers are authoritative. If the zone has not been rebuilt at the new provider first, your site and email go down as soon as resolvers pick up the new delegation.
How long does a nameserver change take to work?
The registry usually publishes the change within minutes. The tail is caused by resolvers holding the old delegation until its TTL expires, so expect most of the internet within a few hours and completion within roughly 48 hours.
Do I have to move my hosting if I transfer my domain?
No. A transfer changes the registrar only. Confirm the gaining registrar will keep your existing nameservers, because a transfer that resets them to their defaults will take your site and mail offline.
How do I find out who my DNS provider is?
Look at the nameservers in a WHOIS or RDAP lookup. The lookup names the registrar directly, and the nameserver hostnames tell you which company operates your DNS.