Registries and registrars: who actually holds your domain

When you change your domain's nameservers - moving your-website.com from one DNS provider to another - three organisations are involved, and only one of them is ever the reason it feels slow. Here is the split, and how to see each part from a terminal.

Three roles, kept apart on purpose

• The registry runs one top-level domain. For .com that is Verisign. It holds the master database of every .com name and operates the .com nameservers.
• The registrar is an ICANN-accredited company you buy the domain from - Namecheap, Cloudflare, GoDaddy. It is authorised to write to the registry's database on your behalf.
• The registrant is you. You never touch the registry directly; you tell the registrar what you want.

The registrar talks to the registry over EPP (Extensible Provisioning Protocol) - a provisioning API for creating, updating and transferring domains. It is not DNS; no name resolution happens over EPP. The separation is deliberate: one registry per TLD, many registrars competing on price and service in front of it.

What the registry stores for your domain

Less than you might think. For your-website.com, the .com registry holds:

• the sponsoring registrar, and creation / expiry dates
• status codes (clientTransferProhibited, serverHold, and so on)
• the delegation - the set of nameserver names, e.g. xxx.ns.cloudflare.com
• glue - the IP addresses of those nameservers, but only when the nameserver's hostname sits inside the domain being delegated (ns1.your-website.com). Cloudflare's live under ns.cloudflare.com, so their glue is in the .com zone already and your domain needs none.
• DS records - DNSSEC key fingerprints, if you have signing enabled

Notice what is missing: your name, email, address. .com is a thin registry - contact details stay with the registrar. Most newer TLDs are thick and keep everything at the registry. That is why whois your-website.com returns a sparse record and refers you to the registrar for the rest:

whois your-website.com | grep -iE 'registrar:|name server:|domain status:'

The nameservers above yours

Resolution is a chain of delegations. The root zone, managed by IANA, delegates .com to Verisign's thirteen nameservers, a.gtld-servers.net through m.gtld-servers.net. Those servers in turn delegate your-website.com to whatever nameservers your registry record lists.

# the .com TLD nameservers
dig +short com NS

# ask one directly: who does .com say is authoritative for your domain?
dig NS your-website.com @$(dig +short com NS | head -1)

# or walk the whole chain, root → .com → your zone
dig +trace your-website.com

That middle command is the one that matters during a migration: it is the registry's own answer, not a cached one.

What actually happens when you change nameservers

1. You save the new nameservers in your registrar's dashboard.
2. The registrar sends an EPP <domain:update> to the registry, replacing the delegation. Seconds.
3. The registry updates its database and regenerates the .com zone.
4. The new zone is published out to the thirteen gtld-servers.net hosts. On a modern registry this is minutes, not hours.

From step 4 on, the .com servers hand out your new nameservers to anyone who asks.

So why does it still take hours

Because "anyone who asks" is the catch. A resolver that looked your domain up before the change cached the old delegation, with the TTL the .com zone puts on referrals: 172800 seconds, 48 hours. Until that entry expires, that resolver keeps talking to your old nameservers - it has no reason to re-ask the TLD.

That is the real "up to 48 hours." It is not the registry being slow; the registry was done in minutes. It is a few million independent caches, each holding the previous answer until its own timer runs out. New resolvers, and ones whose entry already lapsed, see the change immediately.

On top of that sits a second layer: once your new provider is authoritative, resolvers still hold cached A / MX / TXT records from the old one, bounded by whatever TTL those records carried. Lower those TTLs a day before you move and that tail shrinks.

# the referral, straight from a .com server - note the TTL, then watch it fall
dig +trace your-website.com

The DNSSEC landmine

If DNSSEC was enabled at your old provider, there is a DS record in the .com zone that fingerprints your old signing key. Switch nameservers without removing that DS first and the chain breaks: the registry still says "expect this key", your new provider signs with a different one, and validating resolvers - Quad9, Google - return SERVFAIL. The domain goes dark for a meaningful slice of the internet.

dig DS your-website.com @$(dig +short com NS | head -1)

If that returns anything, disable DNSSEC at the old registrar, wait about 24 hours for the DS removal to clear caches, then change nameservers.

The shape of it

• Registry - one per TLD, holds the delegation database and runs the TLD nameservers. Updates in minutes.
• Registrar - your write access to that database, over EPP. Where you actually make the change.
• The wait - never the registry. It is caches of the old delegation, and old record TTLs, timing out.

The companion piece, Tracking DNS propagation from the command line, is the full sequence for watching a Namecheap to Cloudflare move go through, step by step.