Visitors experience one website, but a request may cross a registrar, authoritative DNS, a CDN or security proxy, an encrypted connection, the origin host, application code, a database, and third-party services. Understanding those boundaries prevents a common mistake: blaming “the host” for every outage or speed problem.
Image disclosure: These AI-generated editorial images illustrate realistic infrastructure work. They do not show a named provider's facility or a ChoiceRidge test environment.
Short answer
DNS tells clients where to connect; a CDN or reverse proxy can answer at the edge or relay traffic; TLS protects each encrypted connection; the origin runs the application and generates uncached responses. Design and monitor each layer independently. Keep an inventory of ownership, expiration, configuration, and rollback because a healthy origin cannot compensate for broken DNS or TLS.
Follow one request
- The browser asks a recursive resolver for the site's address.
- The resolver follows the domain's delegation to authoritative nameservers and caches the answer according to TTL.
- The browser connects to the returned edge or origin address and negotiates TLS for HTTPS.
- A CDN checks whether it can safely serve a cached response.
- On a miss or dynamic request, the edge contacts the origin over a second connection.
- The origin may call a database, object store, payment service, or other dependency.
This creates two potentially separate TLS legs: visitor-to-edge and edge-to-origin. Both need a valid trust model. Cloudflare's Full (strict) mode, for example, validates the origin certificate and is safer than accepting an unvalidated certificate. An origin certificate trusted only by a proxy may show browser errors if visitors bypass the proxy, which is an architectural choice that must be documented.
DNS: small records, large consequences
Inventory the registrar, registry lock, nameservers, zone administrator, DNSSEC status, A/AAAA/CNAME records, mail records, verification records, and TTLs. Use role accounts and multifactor authentication. Domain and DNS compromise can redirect the entire service even when the web server is secure.
TTL is a cache duration, not a promise that a change becomes universal at a precise minute. Lower it before a planned migration and allow the previous TTL to expire. After the change is stable, restore a sensible value. Avoid changing unrelated mail or verification records during a web cutover.
CDN and cache: acceleration with rules
A CDN reduces distance and origin work when it can serve reusable content. But caching the wrong response can expose private data or show stale carts, sessions, or account pages. Cloudflare's default behavior generally considers request method, response status, file extension, and cache-control directives; exact behavior depends on configuration and product.
Establish explicit policies:
| Content | Typical treatment | Validation |
|---|---|---|
| Versioned CSS, JS, images | Long edge and browser lifetime | New filename on change |
| Public article HTML | Short or moderate edge cache | Purge/update workflow tested |
| Account, cart, checkout | Bypass shared cache | Two-user privacy test |
| API responses | Endpoint-specific | Authentication and headers reviewed |
| Errors and redirects | Deliberate short policy | No accidental long-lived outage page |
Inspect response headers and cache status from more than one location. Test purge behavior, origin fallback, cookies, query strings, compression, and mobile variants. Do not use a higher cache-hit ratio as the only goal; correctness comes first.
TLS and origin protection
Automate certificate issuance and renewal, monitor expiry externally, and keep hostname coverage documented. Redirect HTTP to HTTPS only after confirming certificate validity. Use modern protocol defaults supplied by a maintained platform rather than inventing a cipher policy without expertise.
When traffic should always pass through a proxy, restrict origin access to the proxy's documented network paths and consider authenticated origin connections. Cloudflare's Authenticated Origin Pulls adds client-certificate authentication between its network and the origin; it complements, rather than replaces, normal certificate validation and origin security.
Do not expose administration ports or database services to the public internet. Maintain a documented emergency access path that does not require weakening the normal perimeter.
Diagnose by layer
| Symptom | First checks |
|---|---|
| Domain does not resolve | Delegation, authoritative answers, DNSSEC, expiry |
| Certificate warning | Hostname, expiry, trust chain, edge/origin TLS mode |
| Stale page | Cache status, cache-control, purge, service worker |
| Fast cache hit, slow miss | Origin, application, database, upstream APIs |
| Only one region fails | Edge route, regional DNS answer, origin firewall |
| Login or cart leakage | Shared-cache rules, cookies, authorization handling |
Use external DNS checks, certificate monitoring, edge analytics, synthetic journeys, origin metrics, and application logs. A single “site up” monitor cannot distinguish these failure domains.
Change checklist
- Registrar and DNS ownership documented
- Current zone exported before modification
- TTL changed in advance when appropriate
- Edge and origin certificates valid and monitored
- Dynamic and authenticated paths excluded from shared caching
- Purge, rollback, and origin access tested
- Direct-origin exposure reviewed
- Multi-region and real-device validation complete
For provider selection and the rest of the infrastructure stack, continue through the ChoiceRidge Infrastructure & Hosting hub. This guide complements, rather than replaces, the hosting guide for small businesses because it evaluates architecture instead of vendors.
Method and limitations
This product-neutral guide uses official Cloudflare documentation as a concrete, widely used implementation reference. Other DNS and CDN platforms differ. Apply the principles to their documentation and validate the actual account configuration.