DNS Proxies CDNs and Safe Address Changes

01 The idea

The problem this lesson solves

A stub resolver requests the service address from a recursive resolver.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

DNS selects an entry address under caching rules; downstream proxies and application contracts govern what happens to requests.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Separate DNS from per-request routing

A browser's stub resolver usually asks a recursive resolver for an address. On a cache miss, that resolver follows DNS delegations through root, top-level-domain and authoritative servers as needed. DNS answers are cached according to TTL and resolver behavior. DNS can direct users toward a region or entry point; it usually does not choose one app server for every HTTP request. Existing connections also do not migrate merely because a DNS record changes.

Place proxies and caches by responsibility

A forward proxy acts on behalf of clients; a reverse proxy fronts servers. An API gateway can add authentication, quotas and routing policies; a load balancer focuses on traffic distribution, though one product may do both. A CDN serves eligible cached content near users and reduces origin traffic. It must use correct cache keys and privacy policies: caching one user's private response as public content is a correctness and confidentiality failure.

Plan a DNS migration before changing the record

Lower the TTL sufficiently ahead of the change for previously cached long-lived answers to expire. Bring the new target up, verify it, change the record, and keep the old target serving during the overlap. Monitor both destinations. A low TTL reduces some caching delay; it does not flush all caches, terminate existing connections or make a failed new origin healthy.

Follow the naming chain

A client usually asks its configured recursive resolver. On a cache miss, the resolver follows delegation through the relevant root, top-level-domain and authoritative servers. Some answers are referrals rather than final host addresses. The client does not need to perform every step for every request because several layers cache results.

TTL is a lifetime for a cached DNS answer under the relevant resolver behavior. It is not an instruction that moves an already-open HTTP connection. A client can keep using an established connection even after a record changes; application and transport lifetimes matter during a migration.

Place each intermediary by whose request it handles

A corporate browsing proxy acts for clients and is a forward proxy. An ingress proxy represents the origin service and is a reverse proxy. An API gateway may add authentication, quotas and request policies. A CDN can answer eligible cache hits without contacting the origin.

One product can perform several roles, but the responsibilities remain useful. A CDN cache key and privacy policy must separate representations correctly. A personalized response cannot be made public merely because static images benefit from public caching. Cache eligibility is part of the resource contract.

Migrate with an overlap period

If the current TTL is twenty-four hours, lowering it to five minutes does not rewrite old cached answers immediately. Lower it ahead of the address change and allow the older lifetime to pass under the standard caching model. Bring the new service up, verify it, change the record and continue serving the old target during the overlap.

Monitor both addresses and client errors. Avoid a claim of one universal cutoff: resolvers, clients and existing connections can behave differently. A low TTL increases lookup activity and can reduce some propagation delay, but it cannot make an unhealthy origin usable.

Guided tutorial

1. Observe DNS

Run dig example.com A and identify the answer TTL without assuming a fixed address.

2. Classify proxies

Draw one forward proxy and one reverse proxy with their clients and servers.

3. Write cache eligibility

Choose public image and private profile responses and state different policies.

4. Plan the change

Write preparation, address cutover, overlap, monitoring and rollback steps.

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