DNS Proxies CDNs and Safe Address Changes

01 The idea

The problem this lesson solves

A domain can point to a CDN, which forwards a cache miss through a reverse proxy to an application. These components solve different problems. DNS discovers an address; proxies relay traffic; a CDN may serve a permitted cached representation near the reader. Understanding the boundaries prevents migration plans that assume DNS changes are instant or caching rules that accidentally share private content.

Use the peak traffic and failure budgets from module 4 to judge whether an added server actually helps.

02 Worked example

Resolve a name, then connect to its entry point

03 The method

Understand the mechanism

Separate recursive lookup from authoritative ownership

A client usually asks a recursive resolver for a name’s address. The resolver can answer from cache or perform the necessary lookups through the DNS hierarchy. Authoritative servers provide the records for the zones they serve.

The client does not normally contact every DNS server in the hierarchy itself for each HTTP request. Cached answers at several layers can avoid repeated work. Records may also contain aliases that lead to another name before an address is obtained.

This structure separates who publishes a record from who answers a particular client using a cached copy. Changing the authoritative record does not immediately replace every copy already held by recursive resolvers, operating systems or applications.

After obtaining an address, the client makes its transport connection to the service entry point. The DNS resolver is not on the subsequent HTTP forwarding path merely because it helped find the address.

Treat TTL as cache lifetime, not a global switch

A TTL influences how long an answer can be cached under DNS rules. If an old answer was obtained with a long TTL, lowering the authoritative TTL at cutover time does not retroactively shorten that already cached lifetime.

For a planned address change, lower TTL sufficiently in advance, allow old cached answers to age under the previous policy, verify the new target, change the record and keep both targets serving during the required overlap. Existing connections may persist beyond the moment a client would otherwise resolve again.

DNS-based traffic steering is therefore useful but coarse. Different resolvers and clients observe changes at different times. Health-aware answers can reduce future traffic to an unhealthy destination, but caching delays and existing sessions remain relevant.

Test migration behavior with the actual clients and resolvers you care about. Do not define success as “dig on my laptop shows the new address” while shutting down the old endpoint immediately.

Distinguish forward and reverse proxies

A forward proxy acts on behalf of clients, such as an organization controlling outbound traffic. A reverse proxy acts as the entry point for servers, accepting incoming requests and forwarding them to an appropriate backend.

A reverse proxy can terminate TLS, apply routing, enforce size or timeout limits, and collect request metrics. An API gateway is a role that may combine reverse-proxy behavior with authentication integration, quotas, transformations or API-specific policies.

These functions introduce responsibility. If the proxy adds identity or client-address headers, the backend must trust them only from the intended proxy path and ensure callers cannot spoof equivalent authority. If the proxy retries requests, its retry behavior must match the API’s idempotency contract.

The proxy also has capacity and availability limits. A design with many healthy app servers behind one fragile entry process still has an entry-point failure problem. Redundancy, configuration rollout and certificate management belong to the operational design.

Explain what a CDN actually caches

A content delivery network places serving capacity near users and can cache eligible responses at its edges. A hit avoids some or all origin work. A miss or bypass forwards the request according to the CDN and origin configuration.

Cacheability is a policy, not a consequence of being public on the internet. Responses can vary by path, query, language, headers, cookies or authorization. The cache key and variation rules must distinguish representations that must not be shared.

Static versioned assets are a straightforward case: a changed file can receive a new URL, allowing long caching of immutable versions. Mutable destinations or personalized responses need a more careful freshness and privacy contract.

A CDN can reduce latency, origin bandwidth and repeated work, but it does not make an uncached origin infinitely scalable. Expiry waves, purges or a cold region can send a surge to the origin. Model that miss path and its capacity.

Handle invalidation and multiple layers

There may be a browser cache, edge cache, reverse-proxy cache, local app cache and shared object cache. Updating the database affects none of those copies automatically unless the design connects them through policy or invalidation.

Suppose a7’s destination changes. Deleting an app-cache key does not necessarily invalidate a cached HTTP redirect in the browser or edge. Choose redirect status and cache headers consistent with destination mutability, and include every layer in the freshness contract.

Versioned URLs simplify immutable assets because old and new representations have different identities. They do not solve every mutable-resource problem. Purge APIs can help, but their completion and propagation behavior must be understood rather than assumed instantaneous.

Observe cache status and origin fetches at each layer. A high edge hit rate with incorrect cache variation is a correctness problem, not a success. A low hit rate may be caused by unbounded query-string variation rather than insufficient cache capacity.

Plan safe change and failure behavior

For a domain migration, verify the new target’s certificate, routing, dependencies and responses before directing users to it. Keep the old target available during overlap. Record how to revert the record and how that interacts with caches already observing the new answer.

For a CDN origin outage, decide whether an acceptable stale representation may be served. That choice depends on the resource. A versioned documentation asset and a revoked access decision have very different stale-data consequences.

Monitor resolver outcomes, connection errors, TLS errors, edge status, origin status and cache hit/miss behavior separately. Otherwise an origin outage may be misdiagnosed as DNS merely because users say “the website does not open.”

The diagram should show two paths: name resolution and request forwarding. Label the authority for DNS records and the authority for application data. This makes migrations and cache failures understandable without treating every intermediary as the same kind of box.

dig example.com A
curl -I https://example.com
# Migration: lower TTL ahead of cutover → verify new target
# → change answer → overlap old/new serving → observe → retire old

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions