Cloudflare added account-level enforce_dns_only on April 28, 2026. For most teams, the important change is not the API flag itself. It is that direct-to-origin failover is now a fast, account-wide operating mode. If you use Cloudflare for WAF, caching, rate limiting, or origin shielding, one toggle can remove that layer across every affected zone.
That makes this a business continuity issue, not a narrow DNS detail. Business owners care because downtime gets longer when fallback paths are untested. Operations leads care because the cutover is not perfectly clean, and security controls disappear at the same time. Agency teams care because a client who asks, "can we bypass Cloudflare if we have to?" now has a real switch, and that switch deserves a runbook.
| Check Area | What To Confirm Before You Use It | Why It Matters |
|---|---|---|
| DNS map | Know which proxied hostnames resolve to which origin, and which DNS-only records share the same infrastructure. | Prevents surprise origin exposure and easier direct targeting. |
| Certificates | Install publicly trusted certificates on any hostname that may need direct browser access. | Avoids client trust errors when Cloudflare is out of path. |
| Capacity | Test origin performance without Cloudflare caching and filtering in front of it. | Reduces the risk of turning one outage into a second outage. |
| Firewall rules | Define a narrow emergency access path and a rollback path before the incident. | Avoids self-lockout or overly broad last-minute exposure. |
| Ownership | Decide who can use the API token, who approves the change, and how status is communicated. | Keeps the switch from becoming an improvised high-risk action. |
What the switch actually does
Cloudflare describes enforce_dns_only as an account-level, API-only, non-destructive control. When enabled, Cloudflare answers DNS for proxied records with the underlying origin IPs or CNAME targets instead of Cloudflare anycast addresses. When disabled, normal proxy behavior returns.
The scope is broader than many teams assume. Current Cloudflare documentation says it affects standard proxied A, AAAA, and CNAME records, load balancing records, and proxied records matched by Worker routes. It does not apply to everything in the account: Spectrum, Tunnel CNAMEs, R2 custom domains, Web3 gateways, and Workers custom domains are excluded. If your estate mixes these products, incident behavior will not be uniform.
Cutover is also not instant. Cloudflare says proxied records use Auto TTL, five minutes by default, so some users may still hit Cloudflare IPs while others start resolving origin IPs. That is enough to confuse monitoring, support teams, and rollback decisions if nobody has rehearsed the timing.
Where teams get caught
DNS exposure is usually already present
Only A, AAAA, and CNAME records can be proxied. Everything else remains DNS-only. Cloudflare also warns that if a DNS-only record points to the same server as a proxied hostname, a simple lookup can expose the same origin IP. In practice, mail services, validation hostnames, and legacy subdomains are often where the leak already exists.
There is another detail worth checking during audits: if multiple A or AAAA records share the same name and at least one is proxied, Cloudflare treats all records on that name as proxied. Reviewing DNS line by line can miss the real behavior of the hostname. Map services by hostname and origin, not just by individual records.
TLS can fail the minute users connect directly
Cloudflare's preparation guidance is explicit: if origins will serve HTTPS directly, they need publicly trusted certificates for the relevant hostnames. Cloudflare Origin CA is only trusted by Cloudflare. It works well for the Cloudflare-to-origin hop, but it will cause client certificate errors if browsers hit the origin directly. That means your emergency path can look healthy in server metrics while users see trust warnings.
Firewalls and capacity assumptions change at the same time
When Cloudflare is out of path, the origin must absorb traffic that Cloudflare would normally cache or filter. That is a capacity problem, but it is also an access-control problem. Many hardened origins only allow Cloudflare IP ranges or depend on controls such as Authenticated Origin Pulls. That is good practice in normal mode. It is a failure mode if nobody has defined how direct traffic is allowed during incident mode.
The safer approach is to design a narrow emergency path now: decide which hostnames may ever go direct, define the corresponding firewall rule set, and document the rollback. If your security posture depends on hiding the origin entirely, evaluate whether Cloudflare Tunnel or a different standby design is better than public direct-origin failover.
A practical runbook to rehearse
For most teams, the right question is not "can we toggle it?" but "under what exact conditions is it safe enough to use?" A workable runbook is short:
- Inventory every proxied hostname and the origin it lands on, then flag any DNS-only records sharing that same infrastructure.
- Mark which hostnames must stay browser-reachable in an emergency and confirm publicly trusted certificates are installed there.
- Test origin capacity without Cloudflare caching, WAF, and rate limiting in front of it.
- Define who can use the account-level API token and who approves the change during an incident.
- Rehearse both enable and rollback in a staging or test account, including the five-minute DNS lag window.
If you want a minimal implementation check, Cloudflare's current API flow is straightforward: use a GET request to confirm the current DNS settings, then PATCH the account DNS settings with "enforce_dns_only": true to enable or false to disable. The value of the rehearsal is not the curl syntax. It is confirming that DNS resolution, certificates, firewall rules, monitoring, and client communications all behave the way your team expects.
curl 'https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/dns_settings' --request GET --header 'Authorization: Bearer $CLOUDFLARE_API_TOKEN'
curl 'https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/dns_settings' --request PATCH --header 'Authorization: Bearer $CLOUDFLARE_API_TOKEN' --json '{"enforce_dns_only": true}'The consultant's takeaway
This feature is useful. It gives teams a faster way to route around a Cloudflare-side problem. But it also turns an old assumption, "we can always go direct to origin if we need to," into something that can be triggered in seconds. If origin exposure, TLS, capacity, and firewall behavior are not already documented and tested, the switch is less of a safety net and more of a live-fire drill.
If you want this turned into a short runbook, DNS audit, and staging test plan, Greg can help as a practical delivery partner.
Need help with this kind of work?
Need help turning this into a tested Cloudflare runbook? Get in touch with Greg.