On April 28, 2026, Cloudflare introduced an account-level enforce_dns_only setting. On paper, it looks like a convenience feature. In practice, it is a break-glass control: one API call can make Cloudflare answer DNS queries for proxied records with your origin IPs instead of Cloudflare anycast IPs. Once that happens, the proxy layer is no longer in the request path for the affected records, so the protections and behavior that depend on proxying disappear with it.
Cloudflare is clear about the tradeoff. Enable this setting and you expose origin IPs while losing proxy-based features such as DDoS mitigation, WAF enforcement, and caching across the affected zones in the account. The feature is available by API to all customers. The real question is not whether you can turn it on. It is whether your origin estate is ready if you do.
That is why this matters operationally. Many teams have long assumed they could bypass Cloudflare in an emergency if they really had to. Now that path is centralized, fast, and account-wide. If origin capacity, TLS behavior, firewall rules, or DNS hygiene have not been checked in advance, using the switch can create a second incident while you are still handling the first one.
What the switch actually changes
Cloudflare describes enforce_dns_only as account-level, API-only, and non-destructive. It does not rewrite your DNS records, and when you turn it off, standard proxy behavior comes back. That sounds reassuring, but it is still the kind of temporary state that needs to be treated as incident mode, not as a harmless toggle.
The scope is also wider than many teams will expect. Cloudflare says it affects standard proxied A, AAAA, and CNAME records, load balancing records, and records that match Worker routes. It works across full setup, partial CNAME setup, and certain proxied records in secondary zones. So this is not a narrow edge case buried in DNS administration. It can materially change how traffic reaches your infrastructure.
It is not universal, though. Cloudflare lists exclusions including Spectrum applications, Cloudflare Tunnel CNAMEs, R2 custom domains, Web3 gateways, and Workers custom domains. In other words, one account-level switch does not necessarily put your whole estate into one neat operating mode. If this is part of an incident plan, the exceptions should already be documented before anyone is under pressure.
Why five minutes is operationally significant
Cloudflare ties proxy status directly to DNS behavior. Proxied records use an Auto TTL of 300 seconds, and Cloudflare says recursive resolvers should not keep the old address longer than five minutes. It also notes that local DNS caches can stretch the cutover in the real world.
That detail matters more than it looks. Switching to account-level DNS-only mode is not a perfectly synchronized flip. For a period, some users may still resolve Cloudflare IPs while others begin resolving origin IPs. If your monitoring, rollback expectations, support guidance, or stakeholder communication assume an instant cutover, they are likely to be wrong at exactly the moment accuracy matters most.
Most origin exposure issues are already there before the emergency
Cloudflare’s proxy-status guidance is straightforward. When a record is proxied, Cloudflare can protect, optimize, cache, and apply edge features to the traffic. When a record is DNS-only, Cloudflare returns the real server IP and does not proxy HTTP or HTTPS for that hostname. That is why Cloudflare recommends proxying A, AAAA, and CNAME records that serve web traffic wherever possible.
The problem is that many environments already leak more than teams realize. Only A, AAAA, and CNAME records can be proxied. Other record types, including MX and TXT, are always DNS-only. Some verification-related CNAMEs also need to remain DNS-only. Cloudflare further warns that if a DNS-only record points at the same origin as a proxied record, a simple lookup against the DNS-only hostname can reveal the origin IP and make direct targeting easier.
There is also a hostname-level behavior that often gets missed during audits. If multiple A or AAAA records share the same name and at least one is proxied, Cloudflare treats all A or AAAA records for that name as proxied. Teams that review DNS one row at a time can miss the effective behavior of the hostname, which is what actually matters when you are trying to understand exposure.
That is why origin readiness starts with inventory, not with the API call. Which proxied records map to which origins? Which DNS-only records sit on the same infrastructure? Are mail services or validation hostnames quietly disclosing the same IP space? Cloudflare’s own origin-protection guidance recommends auditing DNS-only records for origin IP information, separating mail infrastructure where practical, and rotating origin IPs after onboarding because historic DNS data remains public.
Certificates are a common failure point in break-glass plans
TLS is the next place these plans break down. Cloudflare Origin CA certificates are useful for encrypting traffic between Cloudflare and your origin, and Cloudflare presents them as available on all plans. They fit well with Full (strict) mode when origins are protected by Origin CA or publicly trusted certificates.
But Cloudflare also warns that pausing Cloudflare or disabling proxying on hostnames that rely on Origin CA can trigger browser trust errors. The reason is simple: Origin CA secures the Cloudflare-to-origin hop, not the browser-to-origin hop. If your incident plan assumes customers, staff, or partners can reach the origin directly on the normal hostname while proxying is disabled, Origin CA alone is not enough.
In practice, any hostname that needs to remain directly browser-reachable should be checked for publicly trusted certificate coverage at the origin. That is not a knock on Origin CA. It is just the wrong trust model for direct browser traffic, and that distinction becomes very real during an outage.
Firewall rules and direct access need to be designed, not improvised
Cloudflare’s guidance on origin protection is consistent: proxy what you can, review DNS-only records for leaks, rotate origin IPs after onboarding, and restrict direct traffic so only Cloudflare IP ranges or other trusted parties can reach the origin. It also points to stronger patterns such as Authenticated Origin Pulls, Cloudflare Tunnel, and account-specific egress IP approaches.
The practical implication is clear. If your current setup assumes only Cloudflare should ever reach the origin, then direct-to-origin mode needs its own documented access path. That could mean temporary firewall changes, a standby origin design, or a tightly scoped exception for specific hostnames. The right answer depends on the environment. What should not happen is designing that path for the first time in the middle of an incident.
A practical readiness checklist
- Map every proxied
A,AAAA, andCNAMErecord to its actual origin, and note which hostnames are customer-facing. - List DNS-only records that share infrastructure with proxied hostnames, including mail-related services and validation records.
- Confirm which services can safely remain proxied and which ones would genuinely need direct-origin access during an incident.
- Verify origin capacity without Cloudflare caching and filtering in front of it, because Cloudflare explicitly advises testing that assumption.
- Check certificate coverage hostname by hostname. Anything that must work directly in a browser should not depend only on Origin CA.
- Review firewall rules, allowlists, and origin restrictions so any direct-access path is deliberate, limited, and reversible.
- Test the API workflow in a staging or test account, because Cloudflare specifically recommends rehearsing before relying on the feature in an emergency.
This is the sort of work Greg can help make concrete: inventory proxied versus DNS-only records, identify origin IP leaks, check where publicly trusted origin certificates are required, tighten direct-access firewall behavior, and turn the whole sequence into a usable runbook with staging tests.
The larger point is simple. On April 28, 2026, Cloudflare turned a vague fallback idea into a real account-level control. Teams that treat enforce_dns_only as a genuine incident mode can make it routine. Teams that assume they can always bypass Cloudflare if needed are now one API call away from finding out what was never prepared.
Need help with this kind of work?
Talk to Greg about Cloudflare origin readiness Get in touch with Greg.