Cloudflare’s DNS build update puts processing speed and cache timing in separate focus

Cloudflare describes a targeted build planner that chooses the smallest DNS build it can establish is safe, alongside a scheduler that combines work for the same zone. The company says zone-setting changes previously could trigger complete rebuilds even for zones containing tens of millions of records.

Its report says the changes cut peak memory use by 85% and halved the median build completion delay from a DNS change to its data being written to Quicksilver, Cloudflare’s distributed data store. These are Cloudflare’s reported engineering results, not independently measured results for an OrangeHat site or customer.

The reported endpoint is important: the work prepares data used by authoritative DNS servers. It is not a measurement showing that every browser or recursive resolver immediately stopped using an earlier answer.

Cloudflare’s TTL documentation explains that a record’s time to live controls how long it is cached. Longer caching can reduce repeat lookups, while also extending how long an older answer remains in use after a change.

The documentation gives Cloudflare’s proxied records an automatic TTL of 300 seconds and notes that local caches can make a change take longer to appear on a particular device. Its FAQ separately says data from a previous record may remain cached until that earlier TTL expires.

For an update review, the implication is to keep internal processing time separate from cache lifetime. Faster preparation of an authoritative answer does not, by itself, establish when an already cached answer will be replaced. That is a different question with a different observation point.

Cloudflare’s troubleshooting guide describes another case: a resolver may have cached an NXDOMAIN answer because someone queried a hostname before its record existed. That negative answer has its own caching rules, rather than simply adopting the TTL of the newly created record.

The guide explains that clearing a device’s local cache does not remove an upstream resolver’s cached negative answer. Different resolvers can also appear to update unevenly because they queried at different times or hold different cached results.

This distinction matters when a team treats “record created” as equivalent to “everyone can resolve it.” The dashboard can show the intended configuration while a particular lookup still reflects an earlier result. The observation identifies a path to investigate; it does not alone identify a provider fault.

Consider a hypothetical team moving a test hostname to a new destination. Its review could record when the change was submitted, which authoritative server was queried, which recursive resolver was used and the returned answer with its remaining TTL. No actual migration or performance outcome is implied by this example.

A direct authoritative lookup and a lookup through the user’s resolver answer different questions. Cloudflare’s troubleshooting guide includes authoritative-server queries as a way to check whether the record was created correctly. Comparing those observations can narrow an investigation without assuming that one person’s browser represents every user.

The same discipline applies to an engineering announcement. Cloudflare’s reported improvement concerns a defined internal interval; a business evaluating a DNS change needs evidence from the stages its users depend on. Neither an updated dashboard nor a faster build metric is a complete end-to-end measurement.