Contents and search
Introduction to Cloud Computing

Chapter 11 · Part III · Containers, orchestration, and the edge

Cloudflare, Domain Name System, and the Network Edge

Nia, a student in Singapore, opens store.campuscart.example during registration. CampusCart's origin application runs in a cloud region in Virginia. Nia's browser first needs an Internet Protocol address. If the recursive Domain Name System

Approximately 2,608 words · 12 minute read

Nia, a student in Singapore, opens store.campuscart.example during registration. CampusCart's origin application runs in a cloud region in Virginia. Nia's browser first needs an Internet Protocol address. If the recursive Domain Name System resolver has no fresh cached answer, the resolver follows referrals and ultimately asks an authoritative nameserver for the domain. The returned address leads Nia's packets to a nearby Cloudflare location rather than directly to the Virginia origin.

Cloudflare terminates Nia's Transport Layer Security connection, evaluates configured security rules, and checks an edge cache. A catalog image has a fresh cached response, so Cloudflare returns the image without contacting Virginia. A checkout request is not cached. Cloudflare creates or reuses another encrypted connection to the origin load balancer, which forwards the request to the CampusCart application.

Nia can observe the resolved address, certificate, Hypertext Transfer Protocol response headers, timings, and path changes. The CampusCart team can observe authoritative Domain Name System records, Cloudflare request logs or analytics, cache status, origin load-balancer logs, and application request identifiers. No single artifact proves the whole path. Each institution produces evidence about the portion that the institution operates.

Prerequisites and earlier lessons

  • Chapter 3 supplies packets, routing, Domain Name System resolution, Transport Layer Security, ports, and load balancing.
  • Chapter 5 supplies cloud regions, load balancers, object storage, and origin applications.
  • Chapter 10 supplies Services and external exposure for a Kubernetes origin.
  • The reader should understand that one Hypertext Transfer Protocol request can produce several dependent network exchanges.

Learning outcomes

After completing the chapter, the reader can distinguish authoritative and recursive Domain Name System roles, explain proxied and direct records, follow a request through an anycast edge and an origin, compute a cache hit ratio and a latency budget, interpret cache and certificate evidence, and diagnose common failures without treating Cloudflare as a replacement for origin security or reliability.

Observable evidence

dig store.campuscart.example asks the configured recursive resolver for a Domain Name System answer. The response names the status, answer records, time to live, responding resolver, and query duration. The recursive resolver produces the response from its cache or from iterative queries. An answer establishes what that resolver returned at that moment. The answer does not prove that every resolver has the same cached value.

dig +trace performs iterative referrals from root servers toward authoritative nameservers. The transcript identifies delegations and final authoritative data under the tool's network conditions. A corporate firewall, split-horizon configuration, or local override can make an application's actual resolution path differ. Compare the application environment rather than assuming a laptop transcript represents a production container.

curl -v https://store.campuscart.example/catalog/42 shows connection addresses, Transport Layer Security negotiation, certificate names, request headers, response status, and response headers. Cloudflare can add a CF-Cache-Status header describing cache handling for the response. HIT supplies evidence that a Cloudflare cache served an eligible stored response in the observed exchange. The header does not establish that every location has the object or that a later request will hit.

An origin load-balancer access log is produced when the origin receives a request. A Cloudflare edge response with no matching origin entry can support a cache-hit inference when identifiers and time windows align. Absence alone is weak evidence because log delivery can be delayed, sampled, filtered, or misconfigured. A request identifier forwarded end to end gives a stronger correlation key than timestamps alone.

Mechanism and terminology in context

The Domain Name System, abbreviated DNS, maps names to typed data through a distributed hierarchy. A stub resolver in an application or operating system asks a recursive resolver. The recursive resolver follows or caches referrals and asks an authoritative nameserver for the final zone data. The authoritative nameserver stores the domain owner's configured records. The recursive resolver and authoritative nameserver occupy different sides of the query relationship and can cache different information.

A DNS time to live, abbreviated TTL, states how many seconds a resolver may cache a record before refreshing it. Changing an authoritative record does not recall copies already cached under the previous TTL. A 300-second TTL bounds compliant positive caching under ordinary conditions but does not guarantee every client changes within exactly five minutes because applications and intermediaries can add behavior.

For a Cloudflare-proxied address record, authoritative DNS returns Cloudflare anycast addresses rather than the origin address. Anycast means multiple network locations announce reachability for the same address prefix through the Border Gateway Protocol. Internet routing selects a reachable path according to routing policy and topology. “Nearest” therefore means a routing result, not necessarily minimum geographic distance or minimum measured latency.

At the selected edge location, Cloudflare acts as a reverse proxy. The browser creates a connection to Cloudflare, and Cloudflare creates a logically separate connection toward the configured origin when needed. The browser-to-edge and edge-to-origin connections have distinct source addresses, certificates, timing, and failure conditions. Origin software must recover the intended client information from authenticated proxy headers and must prevent untrusted callers from forging those values.

A content delivery network, abbreviated CDN, stores eligible response bytes at distributed cache locations. A cache key commonly includes the scheme, hostname, path, and selected query or header values under product configuration. The edge checks freshness and request rules. A fresh match can be served without an origin round trip. A miss or stale response can cause an origin fetch, validation, or configured stale response.

Cache-control directives are protocol inputs. Cache-Control: public, max-age=300 makes shared caching permissible for five minutes under normal interpretation. Personalized checkout responses should normally be private or non-cacheable. A cache rule that ignores authentication or cookies can expose one user's response to another user. Cloudflare settings can override origin directives, so the effective policy includes both configurations.

Cloudflare can also evaluate a web application firewall rule, rate limit, bot rule, or distributed denial-of-service mitigation before forwarding. The edge has no automatic knowledge of CampusCart's business semantics. A valid but abusive checkout pattern may pass a generic rule, while an overly broad rule may block legitimate registration traffic. Rule events, sampled requests, application outcomes, and controlled tests must be compared.

Cloudflare is not synonymous with “the cloud.” Cloudflare operates a global network and offers DNS, proxy, compute, storage, and security products. An origin can run on Amazon Web Services, Google Cloud, Microsoft Azure, another provider, or private hardware. The edge and origin remain separate administrative and network domains even when one vendor supplies both types of capability.

Working model: cache effect on origin traffic and latency

During a five-minute catalog test, browsers make 60,000 eligible image requests. Cloudflare serves 48,000 from cache and sends 12,000 to the origin.

cache hit ratio = cache-served eligible requests / all eligible requests = 48,000 / 60,000 = 0.80

The origin request reduction is 48,000 requests during 300 seconds, or 160 avoided origin requests per second on average. The completed quantity is avoided origin requests; the interval is 300 seconds. The ratio applies only to requests defined as eligible in the measurement.

Suppose measured edge hits have a 35-millisecond sample mean, while measured origin-path responses have a 125-millisecond sample mean: 35 milliseconds for the browser-to-edge portion plus 82 milliseconds for the edge-to-origin round trip and origin work plus 8 milliseconds for remaining edge processing. A weighted mean approximation is 0.80 × 35 ms + 0.20 × 125 ms = 53 ms. The calculation predicts a population mean from path-specific sample means, not a percentile. The model assumes stable traffic mix, independent samples, and comparable object sizes. The model omits connection reuse, cache revalidation, tiered caching, queueing, loss, and regional variation. Percentiles cannot be combined with the same weighted arithmetic without distribution data.

Empirical test

Choose one versioned public image and one authenticated checkout endpoint in a staging zone. Purge the image once. Send a controlled request from one test location, record DNS answers, connection addresses, response headers, edge timing, origin log entry, and request identifier. Repeat the identical image request ten times while holding URL, query, headers, and deployment constant. Then change one cache-key input deliberately.

The mechanism predicts an initial miss followed by hits under a cacheable policy, plus a new miss when the effective key changes. The checkout endpoint should not return a shared hit. A repeated miss rejects the expected cache behavior for the tested location and inputs. Possible causes include a non-cacheable directive, cookie, rule override, oversized response, purge, location change, or cache eviction. Inspect configuration and edge status rather than assuming one cause.

Worked investigation

Initial question. Why do some CampusCart users receive the former origin address for up to ten minutes after a migration?

Operating conditions. The team changes an unproxied DNS A record from 192.0.2.10 to 192.0.2.20 at 15:00. The old record had a 600-second TTL. The old origin remains reachable but serves a maintenance page. Cloudflare authoritative nameservers immediately answer the new address after the change.

Evidence collected. An authoritative query directed to a Cloudflare nameserver returns the new address and a 600-second TTL at 15:01. A recursive resolver that queried at 14:59 returns the old address with 472 seconds remaining at 15:01. Browser connection evidence shows a user connecting to the old address. The old origin access log contains the user's request.

Interpretation. The authoritative answer establishes current zone data. The recursive answer directly establishes a still-valid cached copy of former data. The remaining TTL explains why the resolver does not yet ask the authoritative nameserver. The user's connection and old-origin log establish use of the former address. “DNS propagation” is an imprecise label; retained caches, not a broadcast moving slowly between all DNS servers, explain the recorded case.

Proposed intervention and prediction. Keep the old origin serving or forwarding valid responses for at least the former TTL plus operational margin. For future planned changes, lower the TTL sufficiently early, wait for the old TTL to expire, perform the address change, and later raise the TTL. The prediction is that resolvers refreshing after the preparatory interval retain the old value only for the lower TTL.

Observed result. The old origin remains available for 20 minutes. Queries to six controlled recursive resolvers all return the new address after their recorded remaining TTL reaches zero. No further maintenance responses appear after 15:10.

Bounded conclusion and uncertainty. Positive DNS caching under the prior 600-second TTL caused the observed split during the migration. The evidence does not cover every recursive resolver or application cache. Keeping both origins correct during the transition provides stronger safety than assuming uniform resolver behavior.

Normal case

CampusCart delegates authoritative DNS to Cloudflare, enables proxying for the public hostname, restricts origin ingress to authenticated or expected proxy traffic, uses end-to-end Transport Layer Security, and forwards a validated request identifier. Versioned public assets have explicit long-lived cache directives. HTML receives a shorter policy. Checkout responses are not stored in a shared cache. Edge and origin logs share enough identifiers for bounded correlation.

Failure and edge cases

An origin certificate can expire while browser-to-edge Transport Layer Security remains valid, causing an edge-to-origin failure. A cached object can remain available during an origin outage, which helps static reads but can hide origin failure from superficial monitoring. A cache key that omits a language, authorization, or content-negotiation input can return wrong bytes. Purging one URL may not remove variants under other keys.

Anycast route changes can move two consecutive connections to different edge locations. Internet routing incidents can create longer paths without any application deployment. A proxied record hides the ordinary origin address from DNS answers but does not remove an origin address already published elsewhere. A distributed denial-of-service network can absorb large traffic volumes, yet an attacker who reaches the origin directly can bypass the proxy unless origin controls prevent access.

Important qualifications

Cloudflare product limits, cache eligibility rules, default TTL behavior, and log availability are version-sensitive. Consult the current product documentation and the active account plan. The architectural principles—separate recursive and authoritative DNS roles, distinct proxy connections, cache keys, freshness, and origin controls—remain more durable than one product default.

Cache ratio alone does not measure user experience. A high ratio for tiny fast objects can coexist with a slow checkout. An edge location close to a user can still depend on a distant origin for dynamic responses. Measure the browser result, edge processing, origin work, and dependency time separately.

Common errors

“DNS sends the request to the server.” DNS supplies typed name data. The client uses an address to create later network packets.

“A low TTL changes every client immediately.” A new TTL affects responses that contain it. Resolvers can retain a prior answer for its prior remaining TTL.

“Anycast always selects the geographically closest location.” Border Gateway Protocol policy and reachable topology select a path. Geography is not the protocol input.

“Cloudflare eliminates the origin.” A cache hit can avoid one origin request. Dynamic misses, revalidation, storage, application logic, and data still require an origin unless the application has been deliberately implemented on edge compute and storage products.

Knowledge check

Question: A browser receives CF-Cache-Status: HIT, and no matching origin request appears in the immediate log search. What can the engineer conclude?

Answer: The header supports the observation that Cloudflare served a cached response for the exchange. The missing origin entry is consistent with no origin fetch but needs qualification because origin logs can be delayed, filtered, sampled, or correlated incorrectly.

Exercises

Check. Query one domain through the default recursive resolver and directly against an authoritative nameserver. Submit the two commands, answer sections, TTL values, and an annotation naming who produced each answer.

Practice. Serve a versioned static file through a test Cloudflare zone. Preserve two curl -v transcripts, edge cache-status headers, an origin access-log excerpt, and a causal explanation for the first and second results. Do not include authentication tokens.

Challenge. Build a migration runbook for an origin-address change with a 3,600-second initial TTL. Submit a timeline that includes the preparatory TTL change, verification queries, coexistence interval, rollback condition, and evidence required before old-origin removal. Test the timing with two controlled resolvers if you own an appropriate domain.

Authoritative sources and further reading

Required reading

Implementation documentation

Primary protocol standards

Advanced and version-sensitive material

Cloudflare cache eligibility, header behavior, plan limits, logging, and optional routing products change independently. Record the active zone configuration, account plan, test location, and documentation access date.

Transition

The request path now includes applications, clusters, cloud networks, DNS, and an edge proxy. Operators need measurements that connect user results with the responsible program and machine, plus decision rules for safe change and incident response. Chapter 12 develops production evidence, service objectives, security controls, cost models, and an investigation procedure.