Cloudflare’s Enforce DNS-Only Switch: Test Your Origin Before an Incident

By Greg Nowak. Last updated 2026-07-14.

Cloudflare’s enforce_dns_only setting gives operations teams a fast way to bypass its reverse proxy across an entire account. That can be valuable during a Cloudflare-side incident, but it also sends visitors directly to your origins and removes the WAF, DDoS mitigation, caching, rate limiting, redirects, and other proxy-based services those origins normally sit behind.

This is therefore less a DNS convenience than a business-continuity decision. Before anyone uses the switch, the organisation needs to know which services will change, whether the origins can safely accept public traffic, and exactly how the team will roll back.

What the switch changes

Introduced on April 28, 2026, enforce_dns_only is an account-level, API-only break-glass control. It does not edit individual DNS records. Instead, Cloudflare’s edge answers queries for affected proxied records with their underlying IP addresses or CNAME targets. Setting it back to false restores normal proxy behaviour.

The scope is broad but not universal. It includes standard proxied A, AAAA, and CNAME records, Cloudflare Load Balancing records, records matched by Worker routes, and Cloudflare for SaaS fallback origins. Spectrum applications, Tunnel CNAMEs, R2 custom domains, Web3 gateways, and Workers custom domains are excluded. Mixed Cloudflare estates will therefore behave differently during the same incident.

The change takes effect immediately at Cloudflare’s edge, but users may not see it simultaneously. Proxied records normally have a 300-second Auto TTL, and recursive or local caches can retain an earlier answer for longer. During both cutover and rollback, expect a period when some visitors reach Cloudflare while others connect directly.

Readiness gate	Evidence that you are ready	Reason to stop
TLS	Every direct-access hostname presents a publicly trusted certificate and complete chain.	The origin only has a Cloudflare Origin CA certificate.
Ingress	A reviewed emergency firewall and authentication path is ready.	The origin accepts only Cloudflare IPs or requires Authenticated Origin Pulls.
Capacity	Direct traffic has been tested without Cloudflare caching or filtering.	Origin headroom and database impact are unknown.
DNS	Hostnames, targets, shared servers, and product exclusions are mapped.	The team cannot predict which addresses will become public.
Control	An approver, operator, token owner, monitoring plan, and rollback trigger are named.	The change would be improvised by whoever is online.

A go/no-go check for an account-wide direct-to-origin cutover.

Where an emergency bypass commonly fails

The certificate works through Cloudflare, but not in a browser

A Cloudflare Origin CA certificate is designed for the encrypted Cloudflare-to-origin connection. Browsers do not trust it directly. Any hostname that must remain publicly reachable during bypass needs a certificate issued by a publicly trusted certificate authority, with the correct names and chain installed at the origin.

Normal origin protection blocks the fallback route

Well-protected origins often allowlist Cloudflare IP ranges, require Authenticated Origin Pulls, validate a secret header, or have no public address because they use Cloudflare Tunnel. Those are sensible normal-mode controls, but ordinary visitors cannot satisfy them when connecting directly. Do not solve that during an incident by opening the server indiscriminately. Prepare a narrow, reviewed emergency ingress configuration and a reliable way to restore the hardened rules.

The origin has never carried the real workload

Once Cloudflare is out of path, cache misses become every request, unwanted traffic is no longer filtered, and application-level rate limits may change. Test the web tier, database, third-party dependencies, logging pipeline, and hosting-cost exposure. A bypass that overloads the origin merely replaces one outage with another.

The DNS inventory describes records, not services

Map each public hostname to its origin, certificate, application owner, and Cloudflare product. Also identify DNS-only records that reveal an address shared with a proxied service. Cloudflare treats multiple A or AAAA records on the same hostname as proxied when at least one is proxied, so reviewing records individually can give a misleading picture.

Rehearse the whole decision, not just the API call

Define the incident severity, affected services, approver, and evidence required before account-wide bypass is authorised.
Run the first rehearsal in a staging or test account, as Cloudflare recommends. Do not discover account scope in production.
Test each intended origin from an approved external network. The following command preserves the hostname for TLS and HTTP while connecting to a chosen IP:

curl --resolve 'www.example.com:443:203.0.113.10' \
  'https://www.example.com/'

Exercise the emergency firewall configuration, certificate renewal path, application health checks, and rollback.
Perform a controlled capacity test without depending on Cloudflare’s cache, WAF, or rate limiting.
Observe DNS from multiple networks during a rehearsal and record the real cutover and recovery times.
Give the API token only the required account DNS settings permission, protect it as an incident credential, and log every use.

The current API sequence is simple: inspect the setting, enable it when authorised, and explicitly disable it during recovery.

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}'

curl 'https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/dns_settings' \
  --request PATCH \
  --header 'Authorization: Bearer $CLOUDFLARE_API_TOKEN' \
  --json '{"enforce_dns_only": false}'

Make the emergency switch boring

The feature is useful when direct-to-origin traffic is an intentional recovery design. It is dangerous when “we can bypass Cloudflare” is only an assumption. Some organisations will conclude that a separate standby route is safer than weakening carefully designed origin controls—and that is a valid outcome of the exercise.

If you need a practical DNS inventory, readiness review, or rehearsal plan, Greg can help turn the technical option into a runbook your team can actually use.