How to keep your domain at one registrar and DNS with another provider?

To keep your domain at one registrar and your DNS with another provider, create a DNS zone for your domain at the DNS provider, add all your records there, and then replace the nameservers at your registrar with the ones the DNS provider gives you. The registrar continues to handle the registration itself, including renewals, contact details and transfer locks, while the DNS provider answers every query for your records. If you use DNSSEC, the DNS provider signs the zone and you add its DS record at the registrar.

This split is common and fully supported. The registrar's only DNS job is to tell the registry which nameservers are responsible for your domain, and those nameservers can belong to anyone. In this article you'll learn how the two roles fit together, why you might want to separate them, how to set it up step by step, how DNSSEC works across two companies, and what you might lose from your registrar when you move DNS elsewhere.

Registrar vs DNS Host: Two Different Jobs

It's easy to think of "the place I bought my domain" and "the place my DNS lives" as the same thing, because many registrars offer free DNS hosting and set it up by default. They're actually separate services.

	Registrar	DNS host
What it manages	Your registration with the registry	Your zone and its records
You go there to	Renew, update contacts, lock or transfer the domain	Add or change A, MX, TXT and other records
DNS data it controls	NS records and DS records at the registry	Everything inside your zone
Answers DNS queries	Only if you also use its DNS hosting	Yes, for every record lookup

The registrar talks to the registry, the organisation that runs the TLD, such as Verisign for .com. When you set nameservers at your registrar, it sends them to the registry, which publishes them in the TLD zone as NS records for your domain. That's the delegation: the TLD's way of saying "for anything under example.com, ask these servers".

You can see the delegation by asking a .com server directly:

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

example.com.		172800	IN	NS	ns1.dns-host.example.
example.com.		172800	IN	NS	ns2.dns-host.example.

Those nameservers belong to your DNS host. The registrar's role in this lookup ended when it handed the NS records to the registry.

Why Separate Registrar and DNS?

There are good reasons to use a specialist DNS provider while leaving the domain registered where it is:

• Better DNS features: Dedicated providers often offer faster global anycast networks, better APIs, DNSSEC with one click, CNAME flattening, health checks and detailed analytics.
• Reliability: A large DNS provider's network is usually more resilient than a registrar's free DNS.
• Automation: Good APIs and Terraform or DNSControl support make DNS as code practical.
• Platform integration: CDNs and cloud platforms such as Cloudflare, AWS and Google Cloud can tie DNS directly to their other services.
• Independence: If you later want to change registrar for pricing or support reasons, your DNS doesn't move and nothing breaks.
• Security separation: A compromised DNS account can't transfer your domain away, and a compromised registrar account can be protected with extra locks.

The trade-off is that you have two accounts to secure and two companies to deal with if something goes wrong.

Step 1: Create the Zone at Your DNS Provider

Sign up with the DNS provider and add your domain. The provider creates an empty zone, or offers to scan your current records and import them.

Don't rely on a scan alone. Scanners query common names, but they can't find records with unusual names, such as DKIM selectors or verification TXT records. Export your existing zone from the registrar if it offers a download, or copy the records manually from its DNS page.

At the end of this step the provider will show you the nameservers assigned to your zone, for example:

ns1.dns-host.example
ns2.dns-host.example

Some providers assign different nameserver names to different customers, so always use the exact ones shown for your zone.

Step 2: Check the New Zone Before Delegating

Your new provider is already answering for your domain on its nameservers, even though the registry doesn't point there yet. Query them directly to make sure everything is right:

dig @ns1.dns-host.example example.com A +short
dig @ns1.dns-host.example example.com MX +short
dig @ns1.dns-host.example example.com TXT +short
dig @ns1.dns-host.example www.example.com +short

Compare each answer with what your registrar's DNS returns today. If you're not sure which nameservers those are, dig example.com NS +short will tell you. Only move on when both give the same results for every record.

Step 3: Change the Nameservers at Your Registrar

Log in to your registrar, open the domain's settings and find the nameserver section. It's often labelled Nameservers, DNS servers or Custom DNS. Choose the option to use custom nameservers, remove the registrar's defaults and enter your DNS provider's nameservers.

A few registrar-specific things to watch for:

• "Use custom nameservers" vs "Use our DNS": Many registrars have a toggle. Your records at the registrar stop being used as soon as you switch.
• Domain locked for changes: If the domain has a registry lock or a registrar setting that blocks updates, you may need to unlock it temporarily.
• Validation errors: Some registries check that the new nameservers respond for your zone before accepting them. That's another reason to set up the zone first.

After saving, confirm the registry has published the change:

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

Resolvers will gradually pick up the new delegation over the next day or two, as their cached NS records expire. Leave your records at the registrar in place during that time, so resolvers still using the old delegation get the same answers.

Checking From the Registrar's Side With RDAP

RDAP, the modern replacement for WHOIS, shows the registration data the registrar has sent to the registry, including nameservers:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.nameservers[].ldhName'

NS1.DNS-HOST.EXAMPLE
NS2.DNS-HOST.EXAMPLE

The RDAP server depends on the TLD. https://rdap.org/domain/example.com redirects to the right one for most TLDs.

Step 4: Set Up DNSSEC Across Both Companies

DNSSEC needs both parties to cooperate:

1. The DNS host signs the zone and generates the keys.
2. The registrar publishes the DS record at the registry, linking the TLD to your DNS host's key.

The process is:

1. Enable DNSSEC at your DNS provider. It will show you a DS record, or the values needed to create one: key tag, algorithm, digest type and digest.
2. In your registrar's DNSSEC section, add a DS record with exactly those values.
3. Verify it's published and validating:

dig example.com DS +short
dig @1.1.1.1 example.com A +dnssec | grep flags

2371 13 2 1F987CC6583E92DF0890718C42C4D1B4D7D7F1E3A2C1B9E8D7C6B5A4F3E2D1C0
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

The ad flag means the resolver validated the answer.

Automatic DS Updates

Some registries and registrars support CDS and CDNSKEY records, which let a DNS host signal the DS record it wants published, so the registrar or registry can update it automatically. Support varies a lot between TLDs and registrars, so unless your registrar explicitly says it scans for CDS records, plan on adding and updating the DS record by hand.

Order of Operations Matters

If your domain already has a DS record from the registrar's own DNS hosting, remove it and wait for it to expire before you switch nameservers. Otherwise, validating resolvers will reject your new provider's answers, because they're signed with different keys, or not signed at all. Re-enable DNSSEC at the new provider once the switch is complete.

What You Might Lose From Your Registrar

When you stop using your registrar's DNS, any registrar feature that depends on its DNS stops working too. Check for these before you switch:

• URL forwarding or redirects: Usually implemented as an A record pointing at the registrar's redirect server. You'll need to recreate the redirect somewhere else, such as at your web host or with your DNS provider's redirect rules.
• Email forwarding: Free "forward info@ to Gmail" services rely on the registrar's MX records and mail servers. Replace it with a proper email service or a forwarding service that works with any DNS host.
• Bundled website builders or hosting: These often set records automatically. You'll have to add them manually at your new DNS provider.
• Automatic SSL or parking pages: These also tend to rely on registrar DNS.
• One-click integrations: "Connect to Google Workspace" style buttons usually only work when the registrar hosts your DNS.

None of these is a blocker, but they're easy to miss.

Using Custom Nameserver Names

Some businesses want their nameservers to carry their own brand, such as ns1.example.com, while the DNS provider actually runs them. This requires glue records, which are IP addresses for those nameserver hostnames published at the registry, and they're created at the registrar, not the DNS host.

Only a few managed DNS providers support white-label or "vanity" nameservers, and usually on paid plans. If yours does, it will tell you which IP addresses to register as glue at your registrar.

Changing Registrar Later Without Touching DNS

One of the nicest benefits of separating the two is that a registrar transfer becomes a non-event for DNS. When you transfer a domain between registrars, the nameservers are normally carried over with it, so your DNS provider keeps answering throughout.

Before transferring, still take a few precautions:

1. Note your current nameservers and DS record, so you can check them afterwards.
2. Confirm the new registrar supports DNSSEC for your TLD, and check after the transfer that the DS record is still present. Not every registrar keeps it.
3. Check after the transfer that the nameservers haven't been reset to the new registrar's defaults:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority
dig example.com DS +short

Keeping Both Accounts Secure

With two companies involved, you have two accounts that can affect your domain:

• Registrar account: Controls nameservers, DS records and transfers. Anyone who gets in can point your domain anywhere. Protect it with a strong unique password and two-factor authentication, and enable the registrar's transfer lock. For high-value domains, ask about registry lock, which requires a manual, out-of-band verification for nameserver changes.
• DNS provider account: Controls every record. Use two-factor authentication, individual user accounts and scoped API tokens.

Make sure the email addresses on both accounts are ones you'll always control, ideally on a domain other than the one being managed, so you can still receive password resets if that domain's DNS breaks.

Troubleshooting

Symptom	Likely cause	What to check
Changes at DNS host have no effect	Registrar still points to old nameservers	dig @a.gtld-servers.net example.com NS +norecurse
Changes at registrar's DNS page have no effect	Domain is delegated to the DNS host	Edit records at the DNS host instead
SERVFAIL from public resolvers	Old or wrong DS record at registrar	dig example.com DS +short and compare with the DNS host's key
Old redirect stopped working	Registrar URL forwarding needs its DNS	Recreate the redirect elsewhere
Some users see old records	Cached delegation from before the switch	Wait for the NS TTL, keep old records in place meanwhile

The second row catches a lot of people: once you've delegated to another provider, the registrar's DNS page may still let you add records, but nobody is asking the registrar's servers anymore.

---

FAQ: Separate Registrar and DNS Hosting

---

Conclusion

Keeping your domain at one registrar and your DNS with another is straightforward once you see them as two separate jobs. The registrar tells the registry which nameservers to use, and the DNS provider answers every question about your records. Build the zone at the DNS provider first, check it by querying its nameservers directly, then change the nameservers at the registrar.

If you use DNSSEC, the DNS provider signs and the registrar publishes the DS record, and the order of changes matters when you switch. Check for registrar features that quietly depend on its DNS, such as URL and email forwarding, and secure both accounts properly. Done that way, you get a specialist DNS service while keeping the freedom to change either provider independently.