CDN and DNS Network Infrastructure: Performance and Reliability Architecture [2026]

Google's research shows that a 100ms increase in page load time reduces conversion rates by 7%. Amazon's internal data puts it at 1% revenue loss per 100ms of additional latency. These numbers are not hypothetical — they are the measured consequence of network infrastructure decisions that most engineering teams treat as operational details rather than architecture priorities.

CDN and DNS network infrastructure sits between your users and your application servers. Every request traverses it. Decisions about DNS provider, CDN caching strategy, load balancing algorithm, and TLS configuration accumulate into the latency budget that determines whether users experience your application as fast or slow. This guide covers the architecture of each layer — DNS, CDN, load balancing, TLS, DDoS protection, and HTTP/3 — with the configuration decisions that matter in production.

CDN and DNS Network Infrastructure: The Performance Model

Network latency has two components: physical propagation delay (the speed of light across fiber) and protocol overhead (TCP handshakes, TLS negotiation, DNS resolution). Physical propagation is constrained by geography; protocol overhead is addressable through architecture.

DNS resolution adds 20–120ms per request for uncached lookups. CDN edge caching eliminates the round-trip to origin servers for cached content. TLS 1.3 reduces handshake overhead from 2 round-trips (TLS 1.2) to 1. HTTP/3 eliminates head-of-line blocking that causes TCP-based protocols to stall on packet loss. Each optimization is independent; together they can reduce time-to-first-byte from 400ms to under 50ms for geographically distributed users.

DNS Architecture and Configuration

DNS (Domain Name System) translates domain names to IP addresses through a hierarchical resolution process. The resolution chain — recursive resolver, root nameserver, TLD nameserver, authoritative nameserver — adds latency at each step for uncached lookups.

DNS Provider Selection

Using a domain registrar's default DNS servers is the most common DNS configuration mistake in production environments. Registrar DNS servers are not optimized for performance or reliability. Managed DNS providers built on anycast networks provide substantially better query response times and availability.

Cloudflare DNS reports average global query response times of 11ms with 100% uptime SLA. AWS Route 53 uses anycast to route DNS queries to the nearest AWS edge location. Google Cloud DNS and Azure DNS provide equivalent managed capabilities in their respective ecosystems.

The performance difference between registrar DNS and managed DNS is typically 50–80ms per uncached lookup — significant for first-page-load performance where multiple DNS lookups occur.

DNS Record Configuration

Effective DNS configuration requires understanding record types and their use cases. A records map domain names to IPv4 addresses; AAAA records to IPv6. CNAME records create aliases that are required for CDN integration — pointing a domain to yourdomain.cloudfront.net or yourdomain.cdn.cloudflare.net without understanding CNAME aliasing produces misconfigured routing.

TTL (Time To Live) values control how long resolvers cache DNS responses. Low TTL values (60 seconds) enable rapid DNS changes during migrations or failovers but increase DNS query volume. Production records should use 300–3600 second TTLs. During planned cutovers (migrations, IP changes), pre-reduce TTLs to 60 seconds 24 hours before the change.

DNSSEC (DNS Security Extensions) cryptographically signs DNS responses to prevent DNS spoofing and cache poisoning. All major managed DNS providers support DNSSEC; it should be enabled for any domain handling financial transactions or authenticated user sessions.

DNS-Based Load Balancing and Failover

Route 53's routing policies demonstrate what DNS-based traffic management can do beyond simple A record resolution. Latency-based routing directs users to the AWS region with the lowest measured latency from their location. Geolocation routing serves regional content based on user country or continent. Failover routing health-checks the primary endpoint and redirects to a secondary automatically when the primary fails health checks.

Weighted routing enables gradual traffic shifts during migrations: start with 5% to the new environment, validate, increase to 25%, 50%, 100%. DNS-level traffic shifting is the safest migration pattern for high-traffic production services.

CDN Edge Caching

A CDN (Content Delivery Network) caches content at edge locations distributed globally. The primary effect: users receive content from a nearby edge node rather than from a central origin server. Secondary effects: origin server load reduction, DDoS absorption, and edge-side compute execution.

CDN Selection: Cloudflare, CloudFront, Fastly

Cloudflare operates 310+ points of presence. Its edge network terminates TLS, applies WAF rules, and executes Workers (V8-based JavaScript at the edge) before requests reach origin. Cloudflare's free tier includes CDN, DDoS protection, and basic WAF — making it the default choice for small-to-medium applications.

AWS CloudFront integrates with ALB, S3, API Gateway, and Lambda@Edge without leaving the AWS network. For applications with most origin infrastructure on AWS, CloudFront eliminates egress costs between CDN and origin (CloudFront-to-origin traffic on AWS is free). CloudFront supports real-time logs to Kinesis and native integration with WAF and Shield.

Fastly is optimized for programmable CDN with its Varnish-based VCL configuration language and sub-150ms global purge times. Fastly's Compute@Edge supports WASM-compiled code in addition to JavaScript. For applications requiring sophisticated cache invalidation logic or sub-second global purge, Fastly's architecture is better suited than CloudFront or Cloudflare.

Cache-Control Strategy

Cache-Control headers determine what gets cached, where, and for how long. Incorrect cache configuration is either too aggressive (stale content delivered after updates) or too conservative (cache miss rate high enough that CDN provides no benefit).

Effective cache-control by content type:

Static assets (CSS, JavaScript, fonts, images): Cache-Control: public, max-age=31536000, immutable — one year, with immutable preventing revalidation requests. Pair with content-hash filenames (e.g., app.3f8a2c.js) so cache-busting happens through filename change, not TTL expiry.

API responses: Cache-Control: public, max-age=60, stale-while-revalidate=600 — serve fresh content within 60 seconds, serve stale content (up to 10 minutes) while revalidating in the background. Users never experience latency from cache misses.

HTML pages (non-personalized): Cache-Control: public, max-age=300, stale-while-revalidate=3600 — 5 minutes fresh, 1 hour background revalidation.

Authenticated or personalized content: Cache-Control: private, no-store — must not be cached at CDN edges.

Cache Invalidation

CDN cache invalidation clears cached content before its TTL expires. Common use cases: deployment of new application code, correction of incorrectly cached responses, urgent content updates.

Cloudflare's Cache Purge API supports URL-specific purge, tag-based purge (cache tags), and full-zone purge. CloudFront invalidation supports path patterns with wildcard support (/api/*). Fastly's surrogate keys enable invalidating thousands of URLs atomically with a single API call.

The standard practice for deployments: trigger cache invalidation of HTML files and versioned assets as part of the CI/CD deployment pipeline. Static assets with content-hash filenames do not require invalidation — new filenames serve new versions automatically.

Load Balancing Architecture

Load balancers distribute incoming requests across multiple backend servers. The architecture and configuration of load balancers determines application availability, request routing behavior, and handling of backend failures.

Layer 4 vs. Layer 7 Load Balancing

Layer 4 (transport layer) load balancers route based on IP address and TCP/UDP port. They are fast and handle non-HTTP protocols. AWS Network Load Balancer (NLB), Azure Standard Load Balancer, and GCP Cloud Load Balancing all provide L4 capabilities. NLB supports static IP addresses and handles millions of requests per second with consistent microsecond latency.

Layer 7 (application layer) load balancers route based on HTTP content: URL path, hostname, headers, cookies. AWS Application Load Balancer (ALB), Azure Application Gateway, and GCP HTTP(S) Load Balancing provide L7 routing. ALB enables path-based routing (/api/* → API service, /static/* → CloudFront), weighted target groups for canary deployments, and HTTP/2 to backend termination.

For most web applications: ALB for HTTP/HTTPS traffic, NLB for TCP/UDP traffic requiring static IPs or non-HTTP protocols.

Health Checks and Failure Handling

Load balancer health checks continuously test backend availability. When a target fails the configured number of consecutive health checks, the load balancer stops routing requests to it. When it recovers and passes health checks, it re-enters the pool.

Health check configuration decisions:

• Interval: 10–30 seconds for production; shorter intervals detect failures faster but add monitoring traffic
• Threshold: 2–3 consecutive failures before marking unhealthy; 2–3 consecutive successes before marking healthy
• Health check endpoint: /health should check application-layer dependencies (database connectivity, required services) not just HTTP 200 response. An application that responds 200 on /health while its database connection pool is exhausted provides misleading health status.

TLS Configuration

TLS configuration has security and performance implications. Misconfigured TLS is either insecure (old protocol versions, weak cipher suites) or slow (unnecessary handshake round-trips, no session resumption).

TLS version: Disable TLS 1.0 and 1.1; they have known vulnerabilities and browser support is removed. Require TLS 1.2 minimum; prefer TLS 1.3. TLS 1.3 reduces handshake from 2 round-trips to 1, and supports 0-RTT resumption for returning connections.

Certificate management: Let's Encrypt provides free DV (Domain Validated) certificates with 90-day renewal. ACME protocol clients (Certbot, acme.sh) automate renewal. Managed TLS at the CDN layer (Cloudflare, CloudFront) is simpler — the CDN provider handles certificate provisioning and renewal automatically.

HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ensures browsers never attempt HTTP connections to the domain. HSTS preloading submits the domain to browser-maintained lists, protecting even the first connection for new users.

OCSP stapling: Enables the server to include a timestamped OCSP response in the TLS handshake, eliminating the round-trip to the CA for certificate status verification. Reduces TLS handshake latency by 50–100ms.

DDoS Protection

DDoS attacks against web infrastructure increased in frequency and volume through 2025. Effective DDoS protection operates at multiple layers; relying on a single mitigation approach creates exploitable gaps.

Volume-based attacks (UDP flood, SYN flood, DNS amplification) are best mitigated at the CDN/network layer through anycast traffic absorption. Cloudflare, AWS Shield Advanced, and Azure DDoS Protection absorb volumetric attacks across their global networks before traffic reaches origin servers.

Application layer attacks (HTTP flood, slowloris, bot attacks) require rate limiting, behavioral analysis, and CAPTCHA challenges. CDN-layer WAF rules handle common attack patterns; custom rules address application-specific patterns.

AWS Shield Standard (included with CloudFront) provides automatic L3/L4 DDoS mitigation. AWS Shield Advanced ($3,000/month) adds application-layer DDoS mitigation, 24/7 DDoS Response Team access, and cost protection against billing spikes from DDoS-related traffic. Shield Advanced is appropriate for applications where DDoS downtime has significant revenue or reputational consequences.

HTTP/3 and QUIC Protocol

HTTP/3 runs over QUIC, a UDP-based transport protocol designed to eliminate the head-of-line blocking inherent in TCP-based protocols. For users on high-latency or lossy connections (mobile, satellite, congested networks), HTTP/3 can improve page load times by 15–20%.

QUIC combines transport-layer and TLS into a single handshake, reducing connection establishment from 3 round-trips (TCP + TLS 1.2) to 1 round-trip (QUIC + TLS 1.3). Connection migration allows in-flight QUIC connections to survive IP address changes — critical for mobile users switching between WiFi and cellular.

Cloudflare, Fastly, and AWS CloudFront (with HTTP/3 enabled) support QUIC. Browser support covers 95%+ of modern browser users. Server-side QUIC support typically requires CDN-layer configuration; deploying QUIC directly on origin servers is complex and offers less benefit than CDN-layer QUIC termination.

Production Network Infrastructure Checklist

Before deploying to production, validate:

• Managed DNS provider configured (not registrar default DNS)
• DNSSEC enabled for authenticated or financial domains
• CDN active with cache-control headers defined per content type
• Cache hit rate monitored (target: >85% for static assets)
• TLS 1.2 minimum enforced, TLS 1.0/1.1 disabled
• HSTS header active with appropriate max-age
• OCSP stapling enabled
• Load balancer health checks verify application-layer dependencies
• DDoS protection active at CDN layer
• WAF rules deployed and validated in log mode before enforcement mode
• HTTP/3 enabled at CDN layer
• Monitoring alerts on DNS resolution time, CDN cache hit rate, and TTFB

Network infrastructure failures are often invisible until they cause user-facing problems. Monitoring each layer independently — DNS, CDN cache hit rate, origin TTFB, TLS handshake time — provides the early warning needed to address degradation before it becomes an outage.