Cloudflare DNS: network infrastructure that goes far beyond resolving names

DNS is treated as commodity infrastructure: you point out the nameservers, configure an A record and an MX record, and forget about it. What Cloudflare does with a proxy record breaks that premise — the protocol still exists, but what happens when you turn on proxy mode changes what DNS means in your architecture.

What changes when you proxy a record

When you create an A record in Cloudflare and enable the proxy (the orange cloud icon), the IP address your clients receive in the DNS response is not your origin IP. Cloudflare returns one of its own IPs — addresses that belong to the company's anycast network, distributed across more than 300 points of presence around the world.

Every HTTP and HTTPS request that reaches that domain enters the Cloudflare network before reaching your server. TLS is terminated at the PoP closest to the client. The WAF inspects the request. Rate limiting rules are applied. The cache is consulted. DDoS mitigation works at the edge. Only then — if the request has passed through all these layers — is it forwarded to its origin, in a separate connection, via Cloudflare's internal network. Your server's real IP address remains hidden from any external client.

DNS, in this model, is the entry point for the entire security and performance chain — not the service that precedes it.

Anycast: Why 300 PoPs Matter for Latency

Most networks operate with unicast routing — each IP is advertised from a single location, and the packet travels the entire distance to that data center, regardless of where the customer is.

The Cloudflare network works with anycast: the same block of IP addresses is announced simultaneously from each of the more than 300 points of presence, via BGP. When a customer receives a Cloudflare IP in the DNS response, the internet's BGP infrastructure routes the packet to the geographically closest PoP. TLS is terminated there, just a few milliseconds away from the client. The route to its origin — which may be in another region of the world — takes place via Cloudflare's private network, with optimized routes between PoPs, invisible to the end user.

Propagation, TTL and the separation between authoritative and recursive

Two distinct roles coexist in Cloudflare's DNS offering, and confusing them leads to incorrect expectations during incidents. The authoritative service — when you delegate your domain to Cloudflare's nameservers — is what responds with authority over your records. 1.1.1.1 is a public recursive resolver, a separate service that queries authoritative servers on behalf of clients. You can use Cloudflare nameservers for your domain without ever using 1.1.1.1, and vice versa.

When you change a record in the Cloudflare dashboard, the change propagates through the authoritative network in about 30 seconds — a number that is impressive for those coming from providers that take hours to update zones. The problem is that "propagation" in the sense that it affects real users depends on another layer: the recursive resolvers.

Resolvers like Google's 8.8.8.8 and ISP resolvers cache responses by the registry's TTL. If the TTL was at 3600 seconds when a resolver made the query, it will continue responding with the old value for up to an hour — even if Cloudflare has already served the new record for 30 seconds. "Full propagation" to all clients takes exactly the maximum TTL that was in effect at the time of the change.

The default TTL for non-proxied registrations on Cloudflare is 300 seconds. Proxyed records always expose a TTL of 300 seconds externally, regardless of the internal value — Cloudflare needs this flexibility to manage its own anycast IPs. Before any planned change — source migration, failover, IP rotation — the correct procedure is to reduce the TTL to 60 or 300 seconds in advance, wait for the resolvers to update the cache, execute the change, and raise the TTL later. Doing it in reverse order means living with slow propagation exactly when the cost is higher.

CNAME Flattening and the apex problem

The original DNS specification prohibits CNAME at the domain apex — exemplo.com itself without a subdomain — because it conflicts with the required SOA and NS records. For years, this forced teams to fixed IPs in the root domain's A record, creating friction with services that don't guarantee static IPs: load balancers in AWS only expose DNS names, not IPs.

Cloudflare solves this with CNAME Flattening. When you configure a CNAME for the apex, Cloudflare resolves the target in real time — querying the target's A and AAAA at the time of the request — and returns these IPs directly to the client. From the external resolver's point of view, it is a normal A record.

What does this require of those who manage production

Teams that treat DNS as a static configuration have specific problems when operating on Cloudflare. The proxy mode of each registry—on or off—determines whether edge security and performance systems are in the way or not. An A record with proxy disabled exposes the source's real IP, invalidates DDoS protection, and removes the WAF from the stream. Auditing which records are proxied and which are not is not an initial implementation task; needs to be part of the change review process.

TTL deserves continued operational attention. High TTL reduces authoritative load and improves cache in resolvers, but increases recovery time for route changes. Propagation time tolerance is often different between critical records like MX and internal service subdomains — and this difference should be explicit in the zone settings.