Secondary DNS Override: Serving Synced Records Through Cloudflare’s Network
Secondary DNS is typically a failover mechanism. A primary authoritative server holds the zone and pushes changes to secondaries via zone transfer. Those secondaries serve the same records, but only the primary can edit them. This setup is used in three common ways:
- Passive backup: the secondary stays idle and only answers if the primary fails.
- Active backup: primary and secondary serve records in parallel.
- Hidden primary: only the secondary’s nameservers are published at the registrar, so resolvers never touch the primary.
Cloudflare’s Secondary DNS Override takes the hidden-primary model further. Instead of merely serving transferred records, customers can proxy A, AAAA and CNAME records through Cloudflare’s network. That works just as it does when Cloudflare is the primary DNS provider: the origin IP stays shielded while security and performance features are applied to the proxied records.
The distinction matters. If both the primary and Cloudflare nameservers are visible to resolvers, the zone becomes inconsistent. A resolver could query either server and get answers that don’t match, which violates RFC 1034 and RFC 2182. It also exposes the origin IP. With a hidden primary, all queries flow to the Cloudflare secondary server, avoiding those problems.
How Overrides Are Applied
The dashboard for Secondary DNS Override looks like the primary DNS interface with one key difference: transferred records are read-only. Overrides are enabled per record name through the orange cloud button. When clicked, Cloudflare applies the proxy status to all matching A/AAAA and CNAME records under that name.
Behind the scenes, Cloudflare stores override records alongside the transferred ones, pairing them by record name. The record type is ignored for this match for two reasons:
- RFC 1912 forbids a CNAME from sharing a name with any other record (DNSSEC exceptions aside, per RFC 2181).
- A and AAAA records are both address records, so they should have the same proxy state under one name.
In practice, if a zone has multiple A and AAAA records for example.com and one of them is proxied, all of them become proxied. The UI abstracts this from the user by presenting the orange cloud as a per-name toggle. The exception to the read-only rule is a proxied or unproxied CNAME at the apex, which users may add manually per normal practice.
CNAME at the Apex
A CNAME at the zone apex is normally invalid because it would conflict with the SOA and NS records already published there. Cloudflare handles this on secondary zones the same way it does on primary zones: through CNAME Flattening, returning address records to resolvers in place of the CNAME. Users may create a CNAME at the apex even though other records are read-only; it can be proxied or not and will override any A/AAAA records transferred from the primary.
Merging Logic at Edit Time
Record merging happens when the zone is built, not at query time, so the edge answers quickly. The merge process is:
- If a CNAME at the apex exists, it overrides all other apex A/AAAA records.
- For every remaining secondary record, look for a matching override record and apply its proxy status to all records with the same name.
- All other secondary records are left as-is.
Secondary DNS Override suits customers who want Cloudflare’s network and security features without moving the zone fully into Cloudflare DNS. Access control stays on the primary side, where records are edited and pushed out. Unauthorized changes on the Cloudflare side are not possible since only proxy state and the apex CNAME exception are configurable there. The feature is currently available on the Enterprise plan; additional operational details are covered in Cloudflare’s support article.
