How DNS works, from resolver to authoritative answer

Four actors, one question

The stub resolver lives on the device. The recursive resolver caches and walks the tree. The parent (TLD or registrar) holds NS delegation. The authority — Cloud DNS if you host the zone there — returns the record.

GeoDNS and health checks run at the authority. They cannot rewrite an answer already sitting in a recursive cache.

The delivery model

TTL is a contract with strangers

You publish a TTL. Many resolvers honour it. Some clamp it. Designing as if every resolver will forget in one second is how people get surprised.

Still use a low TTL on records you might move. Health-aware answers help even when a cache is sticky: you are less likely to keep publishing a dead target.

What the authority can still decide

On Cloud DNS the answer can depend on location, ASN, subnet, weight and current health. Resolvers receive different records without the application seeing the lookup.

That is why DNS load balancing is coarse. One recursive resolver represents many users. Use it to pick a region or a canary pool, not to fair-share every TCP connection.

Where CDN fits on this path

DNS returns an address or hostname. The CDN is what that name delivers. Flattening the apex to Cloud CDN is a DNS record strategy sitting in front of a delivery strategy.

If lookups fail, the CDN never gets the request. Protect both.

Validate before production

Use dig +trace to inspect delegation and a normal recursive query to inspect the answer clients receive. A trace is a diagnostic walk, not a measurement of every real client’s lookup path. Compare both A and AAAA.

• Record the configuration and expected result before changing traffic.
• Keep evidence of the test and a working rollback for the previous behavior.