ClueDNSSearch

advisory · intermediate

Onboard a domain to Cloudflare nameservers

Inventory records, sequence DNSSEC safely, replace parent delegation, verify web and email, and preserve a tested rollback path.

Published
Jul 28, 2026
Last verified
Review by
Risk
availability-impacting
Provider
cloudflare

This guide covers Cloudflare’s primary (full) DNS setup, where Cloudflare becomes the authoritative DNS provider. It does not cover a partial CNAME setup, secondary DNS, or an improvised multi-provider configuration.

Cloudflare’s current full-setup instructions require adding the zone, reviewing its records, and replacing the registrar-side nameservers with the two assigned Cloudflare nameservers [1].

Owners and control points

Setting Responsible system
Registration and parent nameserver submission Registrar and registry path
Imported and manually created zone records Cloudflare DNS
Old authoritative zone and export Previous DNS provider
Parent DS removal or addition Registrar and registry path
Child signing and generated DS values Cloudflare DNS
Website, origin, CDN, and certificates Web and Cloudflare application owners
MX, SPF, DKIM, DMARC, and mail delivery Email provider and DNS owner

Confirm human owners and account recovery for each control point before the window.

Stop conditions

Do not change the registrar-side nameservers if:

  • the current zone cannot be exported;
  • Cloudflare’s imported records have not been compared with authoritative data;
  • apex, www, email, verification, and delegated-subzone records are incomplete;
  • old DS records remain at the parent and their cache lifetime has not elapsed;
  • the Cloudflare-assigned nameserver pair is unknown;
  • the destination website, certificate, proxy, or mail service is not ready;
  • rollback nameservers and the old provider retention period are undocumented; or
  • nobody is available to verify web and email after the switch.

1. Inventory the current service

Export the complete old zone and query every current authoritative server. Capture:

  • SOA and child-apex NS;
  • apex and www address or alias records;
  • MX, SPF, DKIM, DMARC, and mail-host addresses;
  • CAA, SRV, verification, and uncommon TXT records;
  • delegated subzones and any required glue;
  • TTLs;
  • DNSSEC DS, DNSKEY, and validation state; and
  • application behavior for web, redirects, TLS, and email.

Quick scans are discovery aids, not complete migration sources. Cloudflare warns that its scan may not find every existing record [1].

2. Add and review the Cloudflare zone

Add the registered apex domain to the intended Cloudflare account. Record the assigned Cloudflare nameservers exactly.

Compare the Cloudflare zone with the inventory:

  • reproduce required records and TTL intent;
  • remove guessed or obsolete records only through a separate review;
  • preserve subdelegations;
  • ensure mail-related names are DNS-only;
  • decide whether each eligible A, AAAA, or CNAME is proxied or DNS-only; and
  • prepare the origin and certificate for any proxied web hostname.

With proxied records, DNS answers with Cloudflare edge addresses and web traffic goes through Cloudflare. With DNS-only records, DNS returns the configured target without Cloudflare’s HTTP reverse proxy. This setting changes the network and application path; it is not cosmetic.

3. Sequence existing DNSSEC before the switch

In the normal single-provider migration, remove the old DS record through the registrar before replacing nameservers. Wait for the parent DS TTL to expire, then verify that the parent no longer publishes DS.

Cloudflare warns that changing nameservers while a cached old DS still points to the previous provider’s keys can make validating resolvers return SERVFAIL [3].

Do not:

  • merely turn off signing at the old provider while DS remains;
  • submit Cloudflare’s future DS before Cloudflare serves the active child zone;
  • assume a dashboard change instantly clears cached parent DS data; or
  • use multi-signer instructions unless both providers support the reviewed design.

This creates an intentional insecure interval. DNS remains available but is not authenticated by DNSSEC until the new chain is established.

4. Replace the parent delegation

At the registrar:

  1. remove the previous authoritative nameservers;
  2. enter only the exact nameservers assigned by Cloudflare;
  3. submit the change once;
  4. record the submission time and parent NS TTL; and
  5. avoid unrelated registrar or registrant changes.

Additional old nameservers can produce inconsistent authority. Cloudflare’s troubleshooting guidance calls for an exact assigned pair and no extras <a href=“#source-cloudflare-full-setup-troubleshooting” aria-label=“Source 2”

[2].

5. Verify delegation and authoritative data

Verify from the inside out:

  1. Cloudflare reports the zone as Active.
  2. The parent referral lists only the assigned Cloudflare nameservers.
  3. Each assigned nameserver returns the intended SOA, NS, and key RRsets.
  4. Apex, www, mail, verification, and delegated-subzone records match the inventory.
  5. Named recursive resolvers return explainable answers and TTLs.
  6. Proxied hostnames reach the intended Cloudflare zone and origin.
  7. DNS-only services still reach their intended providers.

Label every observation with the server or resolver and time. Do not wait for a global propagation percentage.

6. Verify the application layers

For the website:

  • test apex and www;
  • verify certificate hostname coverage and TLS;
  • check redirects and canonical destination;
  • confirm expected HTTP status and headers;
  • verify origin access and host routing; and
  • test a cache bypass or known dynamic path when relevant.

For email:

  • confirm MX targets and their address records;
  • verify SPF, DKIM selectors, and DMARC;
  • test inbound and outbound delivery;
  • inspect authentication results; and
  • confirm mail hostnames remain DNS-only unless a supported Cloudflare product explicitly changes that architecture.

A green Cloudflare zone status does not prove either application works.

7. Enable DNSSEC on Cloudflare

After the Cloudflare delegation is active and the unsigned path is stable:

  1. enable DNSSEC in Cloudflare;
  2. record the generated DS values;
  3. submit the exact DS through the registrar;
  4. verify the parent publishes the intended DS;
  5. verify Cloudflare serves matching DNSKEY and valid signatures; and
  6. query a named validating resolver.

Cloudflare signs the zone and supplies DS values for the parent submission [3]. DNSSEC authenticates the DNS data; it does not encrypt queries [4].

If validation becomes bogus, stop unrelated changes and compare parent DS with the Cloudflare DNSKEY set.

Rollback

Keep the old DNS provider and zone available through the migration and expected cache window.

Rollback requires a reviewed sequence:

  • if a new Cloudflare DS was published, remove it and preserve Cloudflare signing until the DS TTL has elapsed;
  • restore the old parent nameserver set;
  • verify the old authoritative servers still publish the captured zone;
  • re-establish the old DNSSEC chain only after delegation and key state match; and
  • retest web, email, TLS, redirects, and resolver observations.

Do not flip nameservers repeatedly while cached DS or NS data remains mixed.

Evidence to retain

Archive:

  • before-and-after zone exports;
  • assigned and prior nameserver sets;
  • DS and DNSKEY values with observation times;
  • authoritative and resolver verification;
  • proxy status decisions;
  • web, TLS, redirect, and email results;
  • change owner and approval; and
  • rollback or closeout decision.

Provider UI and behavior can change. This guide was verified against Cloudflare documentation on the article’s Last verified date and must be reviewed by the displayed Review by date.