LLM Best Practices

Cloudflare: DNS

4 min read

View markdown source

Overview

Cloudflare’s DNS sits in front of every other Cloudflare feature. Proxied records (orange cloud) hide the origin IP, terminate TLS at the edge, and enable caching, Rules, Workers, and WAF. DNS-only records (grey cloud) act as a plain authoritative DNS host. Pick proxy by default; turn it off only for records that genuinely cannot be proxied.

Orange-cloud records to proxy through the edge

A proxied record returns Cloudflare’s anycast IPs to resolvers and Cloudflare relays the request to your origin.

  • Cloudflare terminates TLS at the edge using its certificate, not the origin’s. The browser sees *.example.com; the origin sees Cloudflare IPs.
  • The cache layer, Cache Rules, WAF, Bot Fight Mode, and Workers all run on proxied requests. None of them touch grey-cloud records.
  • Origin IPs are hidden, which blunts most volumetric DDoS attacks and stops attackers from bypassing the WAF.

Orange-cloud the apex (@), www, and any subdomain serving HTTP(S) traffic from an origin you control. Pair the proxy with SSL/TLS Full strict (see cloudflare) so the back leg is also encrypted.

Grey-cloud the records the proxy breaks

The proxy assumes HTTP(S) on port 80 or 443. Anything else needs grey cloud.

  • Mail records: MX, plus the host the MX points to (mail.example.com). Cloudflare does not proxy SMTP, IMAP, or POP3; proxying the host breaks delivery.
  • Verification records: TXT for domain verification (Google, Vercel, GitHub, ACME challenges). The verifier reads the raw record.
  • Non-HTTP services: SRV for SIP, custom ports for game servers, VPN endpoints. Cloudflare Spectrum can proxy arbitrary TCP/UDP on Enterprise; the free plan cannot.
  • Direct-to-origin services: a development host that needs to bypass the cache, a status page that has to read raw origin behavior.

The pattern: HTTP(S) traffic goes orange, everything else goes grey.

Pick the right record type at the apex

The apex domain (example.com, no subdomain) traditionally cannot be a CNAME because RFC 1034 forbids CNAME alongside other record types at the zone apex. Cloudflare solves this with CNAME flattening.

  • CNAME flattening: Cloudflare lets you create a CNAME at the apex; it resolves the target server-side and returns A/AAAA records to clients. This makes apex routing to providers (cname.vercel-dns.com, <user>.github.io) work without copying their IP list.
  • Use CNAME flattening for managed hosts (vercel, github-pages, Netlify). The provider can change their IPs without breaking your domain.
  • Use A and AAAA when the origin has a fixed IP (a VPS like hostinger-vps). Always set both: IPv6 reach is now mandatory for some carriers.

For a subdomain, plain CNAME works; flattening is not needed.

Watch the TTL-1-means-auto gotcha

Cloudflare’s DNS UI shows TTL as Auto for proxied records and as numeric seconds for DNS-only records. The API and exports represent Auto as 1.

  • TTL 1 in the API means “Auto” (Cloudflare picks the TTL, typically 300 seconds for proxied records). It does not mean “1 second.”
  • A grey-cloud record exported as ttl = 1 via Terraform will read as “Auto” on import and “1 second” if applied literally on a non-Cloudflare DNS provider. Translate on migration.
  • For grey-cloud records that need precise control (migrating off the zone, mail records during cutover), set an explicit TTL: 300 for short, 3600 for stable, 86400 for archival.
  • Before a migration, lower TTLs to 300 at least 24 hours ahead and raise them again after the cutover settles. Same playbook as on namecheap-dns.

Enable DNSSEC and publish the DS record at the registrar

DNSSEC signs DNS records with a chain of trust rooted at the parent zone. Without it, resolvers cannot detect DNS spoofing or cache poisoning.

  1. In the Cloudflare DNS dashboard, click Enable DNSSEC. Cloudflare generates a DS record (digest of the public key).
  2. Copy the DS record and paste it at the registrar (Namecheap, Cloudflare Registrar, GoDaddy). The registrar publishes it in the parent zone.
  3. Verify with dig +dnssec example.com DS and check the AD (authenticated data) flag on a dig +dnssec query.

DNSSEC adds about 200 bytes per response and a small CPU overhead. The trade is real cryptographic verification of every record. Enable it on every production zone.

Test DNS changes before promoting them

Resolvers cache aggressively; bad records linger. Verify changes against the authoritative server before depending on them.

# Query Cloudflare's authoritative server directly, bypass resolver cache
dig @ali.ns.cloudflare.com example.com A
dig @ali.ns.cloudflare.com example.com AAAA
dig @ali.ns.cloudflare.com example.com CNAME
dig @ali.ns.cloudflare.com example.com MX
dig +dnssec example.com DS
 
# Then check public resolvers
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Two divergent values across resolvers means propagation has not completed; same value everywhere means the change is live. For DNS hosted at a registrar, the same dig pattern works against the registrar’s authoritative server (see namecheap-dns).

Graph View

Backlinks