← All products

DNS

Cloudflare provides authoritative DNS served from its anycast network, with DNSSEC signing, CNAME flattening and per-record proxy control. This page documents the resolution path, record model, DNSSEC procedure, limits and plan availability.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

Authoritative DNS answers queries for a zone. It is a dependency of every connection to a domain, including web, mail and machine-to-machine traffic. A failure in authoritative DNS makes a domain unreachable regardless of the state of the servers behind it.

Cloudflare serves authoritative DNS from its anycast network. Cloudflare states that its network operates in 348 cities (https://www.cloudflare.com/network/, retrieved 2026-08-28).

Published resolver benchmark rankings are produced by third parties with their own measurement populations and methods. Where response time is a requirement, measure it from your own client population.

Cloudflare DNS is also the attachment point for the rest of the platform. A record is either DNS-only, in which case Cloudflare returns the address you configured, or proxied, in which case Cloudflare returns its own addresses and the hostname's traffic transits the Cloudflare network.

Architecture

Cloudflare's nameservers share a set of IP addresses announced by anycast from its data centres. A resolver querying those addresses is routed to a nearby announcing location, and a location that becomes unavailable causes queries to be routed elsewhere by ordinary BGP behaviour rather than by a DNS failover mechanism.

Zone data edited in the dashboard or through the API is distributed to the serving infrastructure. The relevant distinction for planning is between two things that are often conflated:

• Authoritative answer change. The answer Cloudflare returns for a new query changes shortly after the edit is applied.
• Resolver-visible change. Downstream recursive resolvers continue to serve the previous answer until the record's TTL expires in their cache. Some resolvers and client stacks retain answers beyond the TTL.

Consequently, the time for a change to become visible to all clients is bounded by the previous TTL, not by the speed of the authoritative update. Cutovers must be planned around the TTL that was in effect before the change.

Zone setups differ. A full setup makes Cloudflare authoritative through a registrar nameserver delegation. A partial (CNAME) setup keeps another provider authoritative and delegates individual hostnames. Secondary DNS allows Cloudflare to serve as a secondary to an external primary, or the reverse, using zone transfers.

Capabilities

Configuration model

A zone contains records, each with a type, name, content, TTL and, for address and CNAME records, a proxy status. When a record is proxied, its TTL is managed by Cloudflare and the returned content is a Cloudflare address rather than the configured origin address.

Record types supported include the common types used for web and mail, along with types used for service discovery and verification. Support is broad but not universal; confirm a specific type against the supported record types reference.

Key settings that affect resolution behaviour:

• TTL. Configurable per DNS-only record. It governs how long resolvers may cache the answer and therefore how long a change takes to become visible everywhere.
• Proxy status. Determines whether the hostname is served through the Cloudflare network. Mail records and other non-HTTP service records must remain DNS-only.
• CNAME flattening. Configurable for the apex only or for all CNAME records in the zone.
• DNSSEC. Enabled per zone; produces DS record values that must be published at the registrar.

Records are manageable through the dashboard, the API, the Terraform provider and zone file import or export. Where zones are managed as code, hold the zone file in version control so that a cutover has a reviewable diff and a reversible state.

Limits and constraints

• Change visibility is bounded by the TTL that was in effect before the change, plus the caching behaviour of downstream resolvers and client stacks. Cloudflare updating its authoritative answer quickly does not shorten that bound.
• Record counts per zone and zone counts per account are limited and differ by plan. Confirm current values at https://developers.cloudflare.com/dns/manage-dns-records/ (retrieved 2026-08-28) before importing a large zone.
• Supported record types are extensive but not universal. Verify any uncommon type against https://developers.cloudflare.com/dns/manage-dns-records/ (retrieved 2026-08-28) before migrating.
• Proxied records return Cloudflare addresses. Any external system that validates your origin address from DNS, or that connects to a hostname on a non-HTTP port, must use a DNS-only record.
• DNSSEC requires a DS record at the registrar. Cloudflare adds the DS record automatically only for domains using Cloudflare Registrar and for .ch and .cz top-level domains; for other registrars the operator must publish it (https://developers.cloudflare.com/dns/dnssec/, retrieved 2026-08-28).
• Secondary DNS and multi-provider configurations are Enterprise features.
• Health-checked failover is not part of DNS. It requires the separately billed Load Balancing product.
• Analytics and audit log retention differ by plan.

Plan availability

Deployment

Prerequisites.

• Export the current zone from the existing provider and record every record, including those created by third parties for domain verification, mail authentication and certificate issuance.
• Record current TTLs, because they determine the cutover window.
• Identify mail configuration in full: MX, SPF, DKIM selectors, DMARC, and any provider-specific verification records.
• Identify hostnames that must remain DNS-only, including mail hosts, VPN endpoints and services on non-HTTP ports.
• Check whether DNSSEC is currently enabled at the registrar for the domain.
• Confirm registrar access and the ability to change nameservers and DS records during the planned window.

Staged validation. Import the zone into Cloudflare without changing delegation. Query the Cloudflare nameservers directly for each record and compare the answers with the current production answers, record by record. Resolve differences before proceeding. Where a partial (CNAME) setup is possible, use it to validate a subset of hostnames under production traffic first.

Configuration.

1. Set every record's proxy status deliberately. Leave mail and non-HTTP service records DNS-only.
2. Lower TTLs at the existing provider to a short value at least one previous-TTL interval before the cutover, so that the old values have expired from resolver caches by the time delegation changes.
3. Document the rollback: the previous nameserver set, the exported zone file and the registrar steps required to restore them.
4. Confirm DNSSEC is disabled at the registrar and that the DS record is no longer published in the parent zone.

Cutover. Change the nameservers at the registrar during the agreed window. Keep the previous provider's zone populated and serving for the duration of the previous TTL plus a margin, so that resolvers still holding the old delegation receive correct answers.

Verification.

• Query the new nameservers and several public resolvers for each critical record and compare against the expected values.
• Send and receive test mail, and confirm SPF, DKIM and DMARC evaluation results in the message headers.
• Confirm certificate issuance and renewal flows that depend on DNS validation still succeed.
• Confirm that third-party domain verification records are still resolvable.
• Only after resolution is confirmed correct, enable DNSSEC in Cloudflare and publish the generated DS record at the registrar. Confirm the chain of trust validates before closing the change.

Rollback. Restore the previous nameservers at the registrar. If DNSSEC has already been enabled with Cloudflare, remove the DS record at the registrar and wait for it to clear the parent zone before restoring the previous delegation, otherwise validating resolvers will fail. Because rollback is also bounded by TTL, keep TTLs low until the migration is confirmed stable.

Operational considerations

Manage records as code where possible. DNS changes are high impact, easy to make and difficult to review after the fact. A version-controlled zone with a reviewed diff removes a common class of incident.

Enable audit logging and alerting on record changes, and restrict who may change nameservers and DS records at the registrar. Registrar-level access is the highest-privilege control in the domain and is frequently outside the change process applied to the rest of the infrastructure.

Set TTLs deliberately. Long TTLs improve resilience against a control plane problem but lengthen every planned change. Short TTLs make changes fast but increase query volume and shorten the window in which a stale cached answer protects you during an outage.

Monitor resolution externally from several networks rather than relying on internal checks, and monitor DNSSEC validation status separately, because a signing or key problem presents as a total outage for validating resolvers while unvalidating resolvers continue to work.

Failure modes to plan for: a DS record left in place across a provider change, an expired DNSSEC signature, a proxied record placed on a mail host, and an automation script that recreates a record with the wrong proxy status.

Known caveats

• DNSSEC is not a single-step operation for most registrars. Cloudflare generates the DS record values, but publishing them at the registrar is the operator's responsibility except for Cloudflare Registrar domains and .ch and .cz domains.
• DNSSEC must be disabled and the DS record removed before a nameserver change, and re-enabled afterwards.
• DNSSEC protects clients whose resolvers validate. Clients using non-validating resolvers gain no protection from it, so it reduces but does not remove exposure to forged answers.
• Fast authoritative updates do not shorten TTL-bounded caching downstream. Plan cutovers around the previous TTL.
• Anycast removes single-location dependency for query serving, but a control plane or configuration error remains a shared failure mode. Design for it with change review and external monitoring rather than assuming the architecture prevents it.
• Proxying a record changes the answer returned to every client. Systems that expect the origin address, including some monitoring and allow-list configurations, will break.
• Record type support is broad but not complete; verify uncommon types before migrating.

Interoperability

The proxy toggle is the attachment point for the CDN, WAF, DDoS protection, Bot Management and Workers routes. A hostname must be proxied for those products to apply to its traffic.

Cloudflare Load Balancing operates above DNS and provides health-checked steering; it is configured separately and can target both proxied and DNS-only endpoints.

Certificate issuance for proxied hostnames depends on DNS validation, so DNS configuration and certificate lifecycle are coupled. Confirm validation records remain in place after any zone edit.

Email Security, Email Routing and third-party mail platforms depend on DNS-only MX records and on TXT records for SPF, DKIM and DMARC. Those records are unaffected by proxy status and must not be proxied.

Cloudflare Registrar, where used, changes DNSSEC handling by submitting DS records automatically.

FAQ

How long does a record change take to reach all clients? Up to the TTL that was in effect before the change, plus any additional caching by downstream resolvers and client stacks. Lower the TTL in advance of a planned change.

Is it necessary to use the CDN and security products when moving DNS to Cloudflare? No. Records can be set to DNS-only, in which case Cloudflare acts as authoritative DNS only. Proxying can be enabled per hostname later.

What is required to enable DNSSEC? Enable DNSSEC for the zone in Cloudflare, then publish the generated DS record at the registrar. Cloudflare adds the DS record automatically only for Cloudflare Registrar domains and for .ch and .cz domains.

References

• https://developers.cloudflare.com/dns/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dns/dnssec/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dns/zone-setups/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dns/cname-flattening/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dns/manage-dns-records/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dns/proxy-status/, retrieved 2026-08-28.
• https://developers.cloudflare.com/load-balancing/, retrieved 2026-08-28.
• https://www.cloudflare.com/network/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog