DNS and Reverse Proxy

The proxy status on a DNS record determines whether eligible HTTP or HTTPS traffic goes through Cloudflare or directly to the record target.

Choose the record mode

Only eligible A, AAAA, and CNAME records can be proxied. MX, TXT, and other record types remain DNS-only. Non-HTTP services and unsupported ports need another product or architecture; changing the cloud icon does not turn every protocol into proxied traffic.

Prepare a DNS cutover

1. Export and review the current zone.
2. Remove stale records and identify every record that reveals an origin address.
3. Lower TTLs at the current provider early enough for caches to expire.
4. Recreate records and mark only eligible web hostnames as proxied.
5. Validate mail, verification, certificate, and application records before changing nameservers.
6. If DNSSEC is active, follow the provider migration sequence; a stale DS record can make the zone fail validation.
7. After activation, enable DNSSEC and publish the new DS record at the registrar.

dig example.com NS +short
dig app.example.com A +short
dig app.example.com AAAA +short
dig example.com MX +short
dig example.com DS +short

A proxied hostname should normally return Cloudflare addresses rather than the configured origin. Compare results from more than one resolver during a cutover.

Encrypt both connections

Cloudflare terminates the client connection and creates another connection to the origin. Use Full (strict) so the origin presents a valid, unexpired certificate matching the hostname.

curl -sSvo /dev/null https://app.example.com
openssl s_client -connect origin.example.internal:443 \
  -servername app.example.com </dev/null

The second command is appropriate only from an authorized network path. A Cloudflare Origin CA certificate is trusted for the Cloudflare-to-origin connection, not by ordinary browsers. If engineers need direct browser access during recovery, use a publicly trusted origin certificate or a separate protected access path.

Prevent origin bypass

Proxying hides the current origin in ordinary DNS answers, but old records, mail headers, certificates, and other services may still reveal it. Do not rely on obscurity.

• Allow inbound web traffic only from current Cloudflare IP ranges, or use Tunnel to remove public inbound access.
• Keep administrative ports on a separate private path.
• Review DNS-only records for addresses shared with the web origin.
• Rotate a previously exposed origin address when the hosting design permits it.
• Log CF-Connecting-IP as the visitor address only after confirming the connection came through the trusted Cloudflare path.

Verify the request path

dig app.example.com A +short
curl -sSI https://app.example.com | sed -n '1,15p'
curl -fsS https://app.example.com/health

Then confirm at the origin that the request came from Cloudflare, the expected host was used, TLS validation succeeded, and the application saw the intended client context.

References

• Cloudflare DNS proxy status
• Full (strict) encryption
• Cloudflare HTTP headers
• Cloudflare DNSSEC