What Is the Difference Between a Domain Registrar and a DNS Host?

You log into the company that sold you your domain, add an A record, wait an hour, and nothing changes. Then someone points out that your DNS is actually hosted somewhere else entirely, and the records you just edited are never consulted by anyone. This confusion is extremely common, because many companies bundle two very different jobs under one login: registering a domain name and hosting the DNS for it.

This article separates those two roles clearly: what a domain registrar does, what a DNS host does, how the registry ties them together, how to tell which company is doing which job for your domain, and when it makes sense to split them across providers. If you want to see how a lookup travels through the whole system first, how DNS works is a good primer.

The Short Answer

A domain registrar is the company you pay to reserve a domain name. It records you as the registrant and tells the TLD registry which nameservers are responsible for the domain. That's essentially the full extent of its technical role in resolution.

A DNS host (sometimes called a DNS provider or authoritative DNS provider) runs the nameservers that actually answer questions like "what is the IP address of www.example.com?" It stores your zone, meaning your A, AAAA, CNAME, MX, TXT, and other records, and serves them to resolvers around the world.

The registrar holds the deed. The DNS host holds the map. They can be the same company, but they don't have to be.

The Three Parties Behind Every Domain

To understand the split, it helps to see the full chain of responsibility for a domain like example.com:

Party	Example	What it does
Registry	Verisign for .com and .net	Operates the TLD database and the TLD nameservers
Registrar	Namecheap, GoDaddy, Porkbun, Cloudflare Registrar	Sells registrations, submits changes to the registry on your behalf
Registrant	You or your company	Holds the right to use the domain for the registration period
DNS host	Cloudflare DNS, Route 53, NS1, your registrar's free DNS	Runs the authoritative nameservers for your zone

The registry is the operator of a top-level domain. It maintains the authoritative list of every registered name under that TLD and runs the TLD name servers that point resolvers onward. You never deal with the registry directly for gTLDs like .com; you go through an accredited registrar.

The registrar talks to the registry using a protocol called EPP (Extensible Provisioning Protocol). When you register a domain, renew it, change its nameservers, or lock it, the registrar sends an EPP command to the registry. The registry then publishes the updated delegation in the TLD zone.

The DNS host comes in at the next step. Once the TLD servers say "the nameservers for example.com are ns1.dnshost.net and ns2.dnshost.net," resolvers go to those servers for the actual answers. Whoever operates those servers is your DNS host.

What a Registrar Actually Controls

A registrar is responsible for the domain as an asset, not for its records. Concretely, it controls:

1. Ownership and contact data. Your registrant details, which feed the registration data shown by WHOIS and its modern replacement, RDAP.
2. Registration term and renewal. If the registration lapses, the domain stops resolving no matter how good your DNS host is.
3. Delegation. The list of nameservers published in the TLD zone. This is the single most important DNS-related setting the registrar holds.
4. Glue records (host objects). If your nameservers live inside your own domain, such as ns1.example.com, the registrar registers their IP addresses with the registry. See glue records for why this is needed.
5. DS records for DNSSEC. If you sign your zone, the registrar submits the DS record that links your zone into the chain of trust.
6. Locks and transfer codes. Transfer locks, the EPP auth code needed to move the domain to another registrar, and premium registrar lock services that block unauthorized changes.

Notice what's missing: the registrar does not answer queries for www.example.com. If you've delegated your domain to an outside DNS host, the registrar's own DNS editor becomes irrelevant, even though many registrars still let you fill it in.

What a DNS Host Actually Controls

A DNS host is responsible for the contents of your zone and the infrastructure that serves it:

1. Your records. Every A, AAAA, CNAME, MX, TXT, CAA, SRV, and other record you publish.
2. Authoritative answers. Its nameservers answer resolvers with the aa (authoritative answer) flag set.
3. TTLs and change propagation. How quickly your edits go live on its servers and how long resolvers may cache them.
4. Availability and performance. Anycast networks, geographic distribution, DDoS absorption, and query latency. This is where premium managed DNS services earn their price.
5. Extras. Provider-specific features like ALIAS/flattened records at the apex, health-checked failover, geo-routing, and DNSSEC signing.

A DNS host also is not the same thing as a web host. Your web host serves the website files; your DNS host only tells browsers where that web host is. Three separate companies, one for registration, one for DNS, one for hosting, is a perfectly normal setup.

How the Registrar and DNS Host Connect

The only link between the two is the NS delegation stored at the registry. You can see this link directly by asking a .com TLD server about a domain, bypassing your resolver's cache:

dig @a.gtld-servers.net example.com NS +norecurse

The AUTHORITY SECTION of the response lists the nameservers the registrar has published for the domain. Whatever company operates those hostnames is the DNS host, regardless of where you bought the domain.

Then compare with what the DNS host itself publishes:

dig example.com NS +short

This returns the NS records inside the zone at the DNS host. Ideally both lists match. If the registry says one set of nameservers and the zone says another, you have an inconsistent delegation, which is a common leftover from a half-finished migration.

To see the entire path from the root down, use +trace:

dig example.com A +trace

The trace shows the root servers referring to the .com servers, the .com servers referring to your delegated nameservers, and finally your DNS host returning the A record. The step where the referral lands is the moment control passes from registrar-managed delegation to the DNS host.

How to Find Your Registrar and Your DNS Host

These are two separate lookups, and they often return two different companies.

Finding the registrar

Use RDAP, which ICANN has made the authoritative registration data service for gTLDs in place of legacy WHOIS. The rdap.org bootstrap service redirects you to the correct registry server:

curl -sL https://rdap.org/domain/example.com | jq '.entities[] | select(.roles[] == "registrar") | .vcardArray[1][] | select(.[0] == "fn") | .[3]'

This fetches the RDAP record and extracts the registrar's name from the entity with the registrar role. If you don't have jq, drop everything after the pipe and read the JSON directly. The classic whois example.com command still works for many TLDs too; look for the Registrar: line.

Finding the DNS host

dig example.com NS +short

Typical output looks like this:

amy.ns.cloudflare.com.
bob.ns.cloudflare.com.

The hostnames almost always reveal the provider: *.ns.cloudflare.com is Cloudflare, ns-NNN.awsdns-NN.com (and .net, .org, .co.uk) is Route 53, ns*.domaincontrol.com is GoDaddy, dns*.registrar-servers.com is Namecheap. If the hostnames are inside your own domain, such as ns1.example.com, the provider is using vanity name servers and you'll need to resolve those hostnames and look up who owns the IPs.

Here's a small Python script using dnspython that prints both the delegation and a hint about the provider:

import dns.resolver

domain = "example.com"

answer = dns.resolver.resolve(domain, "NS")
nameservers = sorted(str(r.target).rstrip(".") for r in answer)

print(f"Nameservers for {domain}:")
for ns in nameservers:
    ips = [r.address for r in dns.resolver.resolve(ns, "A")]
    print(f"  {ns} -> {', '.join(ips)}")

Install it with pip install dnspython. The script resolves each nameserver hostname to its IP addresses, which is useful when the names alone don't make the provider obvious.

Why You Might Split Them

Using the registrar's built-in DNS is fine for many small sites. There are good reasons to split the roles, though:

1. Better DNS infrastructure. Registrar DNS is often a free add-on. A dedicated DNS host typically offers a larger anycast network, faster propagation of edits, an API, and features like apex flattening or failover.
2. Price and policy on registration. Some registrars sell at cost and have strong security controls but basic DNS. Others have great DNS but higher renewal pricing. Splitting lets you choose the best of each.
3. Security through separation. If one account is compromised, an attacker who gets into your DNS host can change records, but can't transfer the domain away; someone who gets into the registrar can change nameservers but not quietly edit individual records at your DNS host. Each still needs strong 2FA, but the blast radius differs. Read domain hijacking for how attackers target the registrar side specifically.
4. Redundancy. You can delegate to nameservers at two different DNS hosts at the same time, something the registrar's bundled DNS rarely supports.
5. Easier registrar transfers. When DNS is hosted elsewhere, moving the registration to another registrar doesn't touch resolution at all, because the nameserver delegation stays the same.

The trade-off is one more account to secure and one more bill to track. For a personal blog, keeping both at one company is perfectly reasonable.

Moving One Without Breaking the Other

Because the two roles are independent, you can change one while leaving the other alone.

Changing DNS host, keeping the registrar

• Recreate every record at the new DNS host. Export a zone file from the old host if it offers one, and double-check MX, TXT (SPF, DKIM, verification), and any CNAMEs for third-party services.
• Lower TTLs at the old host a day or two in advance.
• Verify the new host answers correctly before switching, by querying it directly:

dig @new-ns1.dnshost.example www.example.com A +norecurse

• At the registrar, replace the nameservers with the new host's. The steps vary by registrar; see how to update nameservers.
• Keep the old zone active for at least the NS TTL plus a margin (often 48 hours), since some resolvers will still have the old delegation cached.

Changing registrar, keeping the DNS host

1. Unlock the domain and request the EPP auth code from the current registrar.
2. Start the transfer at the new registrar. Most will carry over the existing nameservers automatically, but confirm this before you approve the transfer.
3. Check that the nameservers listed at the new registrar match your DNS host once the transfer completes. Resolution should never blink.

Two gotchas apply here. Some registrars reset nameservers to their own defaults during a transfer if you don't specify otherwise. And if you're using the old registrar's free DNS, transferring the registration away often deletes that DNS zone, so migrate DNS first.

Common Mistakes

• Editing records at the wrong company. The most frequent issue by far. Always run dig NS before editing to confirm where the zone actually lives.
• Letting the domain expire because "DNS is with someone else." Renewal is the registrar's job. Enable auto-renew and keep the payment card current.
• Leaving a stale zone at the registrar. It's harmless until someone switches nameservers back to the registrar's defaults, and the outdated records suddenly go live.
• Mismatched NS sets. The registry delegation and the zone's own NS records disagree, usually after a migration.
• Forgetting the DS record. If DNSSEC is enabled at the old DNS host and you move to a new one without updating or removing the DS record at the registrar, validating resolvers will return SERVFAIL for your entire domain.

---

Registrar vs DNS Host FAQ

Conclusion

The registrar and the DNS host do fundamentally different jobs. The registrar manages the domain as an asset: who owns it, when it renews, whether it's locked, and which nameservers the registry should point to. The DNS host manages the zone: the actual records, how fast they're served, and how reliably. The NS delegation at the registry is the single thread connecting them.

Once you see that thread, most DNS confusion disappears. Before you change anything, check where the domain is delegated, edit records only at the DNS host that delegation points to, and treat the registrar account as the high-value target it is. Whether you keep both roles at one company or split them is a choice about features, price, and risk, not a technical requirement.

If you want to read more about how registration and delegation work, these references are a good place to start:

1. Cloudflare Learning Center: What is a domain name registrar? — an overview of the registrar's role.
2. RFC 5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping — the protocol registrars use to manage domains at the registry.
3. RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP) — the format behind modern registration lookups.
4. RFC 1034: Domain Names - Concepts and Facilities — the foundational description of zones and delegation.