Cloudflare DNS Servers, Primary and Secondary: What the Two Nameservers Mean and What They Do Not

The two nameservers Cloudflare assigns to a zone, something like ada.ns.cloudflare.com and bob.ns.cloudflare.com, are not a primary and a secondary. They are two equal names for the same anycast DNS network, published as a pair because the DNS specification requires at least two nameservers per domain. Both answer every query from the same record set; neither is a fallback for the other. Real primary and secondary DNS is a different thing: a primary server where records are edited, and one or more secondaries that pull a read-only copy by zone transfer. Cloudflare can play either role in that arrangement on paid plans, but the ordinary setup that most people search for is simply the pair, and the pair is one service with two names.

The confusion comes from two vocabularies colliding. Registrars ask for a primary and secondary nameserver in their forms. DNS operators use the same words for a replication topology. Cloudflare’s assigned pair satisfies the first and has nothing to do with the second, and knowing which conversation you are in saves an afternoon.

Table of contents

• What the assigned pair actually is
• Real primary and secondary DNS, in one paragraph
• Where Cloudflare fits that topology
• Setting the records that point at a host
• The mistakes that produce a dead domain
• How this fits the rest of the stack
• FAQ

What the assigned pair actually is

When a domain is added to Cloudflare, the zone is given two nameserver hostnames from a pool of first names. The registrar form calls them primary and secondary because the form has two boxes. Behind both hostnames is the same globally distributed, anycast-routed DNS infrastructure, serving the same records from the same source of truth.

• A resolver that asks either name gets the same answer, at the same time, from the nearest location.
• If a location is unreachable, anycast routes the query elsewhere. The second hostname is not what provides that resilience; the routing is.
• Editing a record in the dashboard changes both simultaneously, because there is only one record set.
• The order you enter them at the registrar does not matter. Resolvers pick nameservers by their own logic, not by the order in a form.

The practical consequence is that there is nothing to configure about the pair. Enter both at the registrar exactly as shown, wait for the zone to become active, and the DNS side is done.

Real primary and secondary DNS, in one paragraph

In the operator’s vocabulary, the primary nameserver holds the editable copy of a zone. Secondary nameservers hold read-only replicas, kept in sync by zone transfer: the primary sends a NOTIFY when the zone changes, the secondary responds with an AXFR or incremental IXFR request and pulls the new data. Resolvers query primaries and secondaries alike; the distinction is only about where edits happen and which direction the data flows. A hidden primary is a variant where the editable server is not published in the NS records at all, so the public only ever sees the secondaries.

This arrangement exists for resilience across providers and for organisations that want to keep the source of truth on infrastructure they control. It is not a feature a small site needs, and a small site that sets it up gains a second thing to keep in sync.

Where Cloudflare fits that topology

On the plans that support it, Cloudflare can take either seat.

• Cloudflare as secondary. Records are managed on your own primary, perhaps an on-premises server or another provider, and Cloudflare pulls them by zone transfer and serves them from its network. You get the anycast footprint and DDoS absorption without moving your editing workflow.
• Cloudflare as primary with outgoing transfers. Records are edited in Cloudflare and pushed to secondaries at another provider, giving multi-provider redundancy in case one DNS operator has a bad day.
• Multi-provider with both directions. The full belt-and-braces arrangement for domains where DNS downtime is a headline.

All of those are paid-tier features aimed at organisations with a DNS operator. If you arrived at this post because a registrar form asked for two nameservers, none of it applies; the assigned pair is the answer to that form.

Setting the records that point at a host

With the nameservers delegated, the records that actually make a site work are the same as anywhere else. For a site on a hosting platform, you typically need:

Type    Name    Content                          Proxy
CNAME   www     your-site.hosting-platform.tld   as required by the host
CNAME   @       your-site.hosting-platform.tld   (Cloudflare flattens this at the apex)
TXT     @       verification-token-from-host     DNS only

Two Cloudflare-specific points. A CNAME at the apex, which DNS normally forbids, works because Cloudflare flattens it into an A record answer, so you do not need the host’s IP address. And the orange-cloud proxy toggle on each record decides whether traffic passes through Cloudflare or goes straight to the host; hosting platforms that issue their own certificates usually want the record set to DNS only during certificate issuance, and some want it that way permanently. Check the host’s instructions before proxying.

Changes to records inside Cloudflare propagate in seconds, because the TTL is short and the record set is one. Changes to the nameservers at the registrar take up to a day or two, because the parent zone’s TTL is long. Most propagation waits people experience are the second kind.

The mistakes that produce a dead domain

1. Entering one nameserver. Some registrar forms accept it. The zone will not activate, and a subset of resolvers will fail. Always enter both.
2. Mixing providers in the NS set. One Cloudflare nameserver and one from the old provider means half of all queries go to a server that has no idea about your new records. Replace the full set.
3. Leaving DNSSEC enabled at the registrar with the old provider’s keys. The signatures no longer validate and validating resolvers return SERVFAIL. Disable DNSSEC before moving, re-enable with Cloudflare’s DS record after.
4. Proxying a record the host needs unproxied. The certificate challenge fails, the host shows a verification error, and the site serves the platform’s default page. Toggle to DNS only for the records the host documents.
5. Assuming the second nameserver is a backup for the first. It is not. Resilience comes from the anycast network, and from a multi-provider setup if you genuinely need one.

How this fits the rest of the stack

The nameserver step is the last thing between a registered domain and a live site, and on a platform that handles the certificate for you, the records above are the whole job. Custom domains on RunxBuild document the exact CNAME to set and issue the certificate once the record resolves, for static sites and services alike. For the cost of what sits behind the domain, the RunxBuild hosting calculator lays out the site, the service and the database as separate lines, which is a more useful comparison than the DNS plan tier, since the DNS itself is the cheap part.

Useful related references:

• Dynamic DNS with Cloudflare: Pointing a Domain at a Home IP That Changes
• DNS Resolution Error: 6 Causes and the Right Fix
• What Does Flushing DNS Do? Clearing the Local Cache of Stale Answers
• Custom domains and certificates on RunxBuild

FAQ

Are Cloudflare’s two nameservers a primary and a secondary?

No. They are two hostnames for the same anycast DNS network, serving the same record set. Both are required because DNS mandates at least two nameservers per domain, but neither is a fallback for the other. Enter both at your registrar exactly as shown.

What is the difference between primary and secondary DNS?

The primary holds the editable copy of a zone. Secondaries hold read-only replicas kept in sync by zone transfer (AXFR/IXFR) after a NOTIFY from the primary. Resolvers query both alike; the distinction is where edits happen and which way data flows.

Can Cloudflare be a secondary DNS provider?

Yes, on paid plans. Cloudflare pulls the zone from your primary by zone transfer and serves it from its network. It can also act as primary and push to secondaries elsewhere, for multi-provider redundancy. Neither is needed for a typical site.

Does the order of nameservers at the registrar matter?

No. Resolvers choose among the listed nameservers by their own selection logic, not by the order in the registrar’s form. What matters is that all nameservers listed belong to the same provider and the full set is replaced when you move.

Why is my domain not resolving after switching to Cloudflare nameservers?

Usually one of: only one nameserver entered, a mix of old and new nameservers, DNSSEC still enabled with the previous provider’s keys, or the parent zone’s TTL has not expired yet. Check the zone status in the dashboard and verify the NS set with dig NS yourdomain.tld.