DNS proxied vs DNS only: what changes and when each mode makes sense

Most teams that migrate to Cloudflare treat the choice between orange cloud and gray cloud as a configuration detail. They activate proxied for everything, assume that more protection is always better, and discover the error weeks later when a database starts returning timeout without any error message — or when they realize that the source IP was always exposed in the records that really mattered.

What proxied mode actually does

When an A or CNAME record is in proxied mode, Cloudflare's authoritative DNS does not return your origin server's IP. It returns an anycast IP from Cloudflare itself. The client connects to one of the network's edge nodes, which completes TLS, inspects the request and only then forwards the traffic to its server — optionally with caching enabled, with WAF rules applied, with Workers intercepting the request midway.

The server's real IP is hidden from public DNS. Any external query to the registry returns Cloudflare IPs, not yours. This has concrete implications: an attacker who wants to bypass WAF would need to discover the source IP through another means — leaked logs, historical TLS certificates in crt.sh, email headers, or direct connections to ancillary services that were exposed without a proxy.

The externally visible TTL is always 300 seconds, regardless of what is configured internally in the zone. Cloudflare controls what external resolvers receive and cache — the internal configuration is only for synchronization between Cloudflare's own nameservers.

What DNS only mode delivers

With the gray icon, Cloudflare functions exclusively as an authoritative DNS. The name query returns the real IP of the server. There is no TLS termination at the edge, there is no WAF, there is no cache, there are no Workers in the path. The client connects directly to the origin server — and Cloudflare never sees the traffic.

For MX records, this absence of proxy is mandatory. The email delivery flow requires sending servers to connect directly to the email server indicated in the MX record. If the MX record tried to go through the Cloudflare proxy, the SMTP would reach an edge node that doesn't know what to do with traffic on port 25 — and the email simply wouldn't arrive. Cloudflare doesn't even allow you to enable proxying on MX records; The default is DNS only and cannot be changed.

The same applies to any TCP service other than HTTP or HTTPS on supported ports. Cloudflare proxy understands HTTP/HTTPS on ports 80 and 443 and a restricted set of documented alternative ports — 8080, 8443, and a few others. Everything outside this set is invisible to the proxy.

The database trap behind a proxied record

This is the scenario that appears most silently in incidents. An A record points to a server running MySQL on port 3306. The team turns on proxied mode because "we want more protection." The client tries to connect to port 3306 — but is now connecting to the Cloudflare edge node, which does not route arbitrary TCP traffic. The connection opens, waits, and closes due to a timeout. There is no clear error message. MySQL doesn't even see the connection attempt.

The same happens with PostgreSQL on port 5432, with Redis on port 6379, with any binary protocol other than HTTP. The proxy simply discards traffic it cannot interpret. To expose these services, the registry must be in DNS only mode — and the direct consequence is that the server's IP is publicly visible.

Subdomain registrations for direct SSH also belong to this category. If the team maintains a ssh.exemplo.com record pointing to a bastion server, it needs to be DNS only. Proxied will break the connection in the same way.

Auditing what is exposed in your area

The question worth asking periodically is simple: which zone records are in DNS only mode, and is the traffic passing through them protected in some other way?

DNS only records expose IPs that can be used to attack the origin directly, bypassing any WAF rules configured in the proxied records. If a server appears in both a proxied record and a different DNS only record — or if the IP was exposed at some point in the past and is indexed in services like Shodan — the protective effect of the proxy is partial.

To completely eliminate source IP exposure in HTTP services, Cloudflare Tunnel solves the problem definitively. The origin server establishes an outbound connection to the Cloudflare network using the cloudflared daemon. User traffic arrives at the edge, tunnels to the server, and the server never needs to accept incoming connections — there is no open port, no exposed IP. For arbitrary TCP traffic outside of HTTP, Cloudflare Spectrum covers this scenario but is exclusive to the Enterprise plan.

What to review before considering the configuration closed

Zones that grow over time accumulate records created in different contexts, by different people, with intentions that are sometimes not documented. A *.exemplo.com wildcard in proxied mode is legitimate and useful for dynamically created subdomains — but it can mask the fact that specific records within that wildcard were manually created as DNS only for reasons no one remembers anymore.

TXT and CAA records are never proxied — this is data that customers need to read directly, and Cloudflare doesn't interfere. SRV and NS are also outside the proxy. In these cases, the interface does not even present the option.