NOETRION

Browse by topic

← All articles
TECHNOLOGY · 10 MIN READ

DNS, HTTPS, and CDNs: three different jobs behind one working website

Trace a page request from domain lookup to encrypted connection and cached response, then diagnose the right layer without changing unrelated settings.

Reviewed October 1, 2026. This is a conceptual troubleshooting guide, not a report on any particular domain's current configuration. Provider-specific behavior is identified explicitly.

Conceptual illustration of a browser, address lookup, shielded connection, edge server, and origin.
Finding an address, protecting a connection, and delivering content are separate responsibilities. The illustration is conceptual; the labeled sequence below describes the actual roles.

A website can have correct DNS and still fail to load. It can display HTTPS and still be a dishonest website. It can sit behind a CDN and still serve a stale page. These outcomes are not contradictions: DNS, TLS, and content delivery solve different problems.

Understanding the boundaries saves time when connecting a custom domain or investigating a broken deployment. Instead of flipping several switches, ask which layer has failed and gather evidence for that layer first.

The short version: address, connection, content

Three layers and the questions they answer
LayerMain questionWhat it does not prove
DNSWhere should this hostname resolve?The destination serves the correct site or accepts HTTPS.
HTTPS through TLSCan the client establish an authenticated, protected connection?The site's claims, downloads, or business practices are trustworthy.
CDN / reverse proxyCan an intermediary deliver or forward this request efficiently?Every response is cached, every origin is healthy, or every route works.

The DNS specification describes a distributed naming system. The TLS 1.3 specification defines a secure channel. A CDN is a deployment architecture that uses distributed servers, often with caching and proxying, rather than a replacement for either protocol.

Follow one request from the browser

Resolve
Find a destination
→Connect
Negotiate TLS
→Request
Send HTTP
→Deliver
Cache or origin
A simplified HTTPS request. Existing DNS answers and reusable connections can skip some work; an actual network trace may therefore look shorter.
  1. The browser needs a destination for the hostname. A resolver may answer from its cache or query the DNS hierarchy.
  2. The client connects to the resulting service. For HTTPS, it validates the server's certificate and negotiates a protected session.
  3. The browser sends an HTTP request containing the hostname and requested path.
  4. A CDN may return an eligible cached response, or forward the request to the origin that generates or stores the content.
  5. The browser parses the HTML and makes further requests for stylesheets, scripts, fonts, and images.

This explains why the home page can work while an image does not. They are different requests and may have different paths, cache rules, permissions, or origins.

DNS records are not all website settings

Cloudflare's DNS explanation distinguishes recursive resolvers from authoritative servers. The authoritative provider holds your zone's records; the recursive resolver answers users by finding or caching those records. Changing one does not transfer ownership of the domain itself.

Common record types in a domain zone
RecordPurposeCommon mistake
A / AAAAAddress records for IPv4 / IPv6.Updating only one while the other still points elsewhere.
CNAMEAn alias to another hostname.Entering a full URL with a path instead of a hostname.
MXMail-routing information.Deleting working email records during a website migration.
TXTText used by verification and policy mechanisms.Removing a verification record without understanding its owner.
NSNameserver information used for delegation.Editing a zone that the domain does not actually use.

Before changing a zone, save its current records and identify the service using each one. The safest migration is narrow: update the website target while preserving unrelated mail and verification settings.

“Propagation” is mostly a cache and delegation question

DNS answers carry a time to live, or TTL. A resolver can reuse an answer while it remains valid. A record change at the authoritative server does not instantly replace every cached answer already distributed.

For a planned migration, record the old TTL before changing anything. Lowering it immediately before the cutover cannot shorten an answer already cached under the previous value. Keep the previous destination available during a sensible transition window, and check authoritative and recursive answers separately.

If two networks disagree, that is evidence to investigate, not proof that one network is broken. They may be using different caches or different address families. A repeatable check records the hostname, record type, resolver, returned value, and time.

HTTPS protects a channel, not the truth of a page

TLS provides confidentiality and integrity for the connection and normally authenticates the server to the client. A browser checks that the presented certificate is appropriate for the requested hostname and trusted under its certificate policy.

Do not bypass a certificate warning to make a setup “work.” A wrong hostname, expired certificate, incomplete chain, or interception can require different fixes. Equally, do not infer that a download is safe simply because it arrived over HTTPS. A malicious operator can also obtain a valid certificate.

Two HTTPS hops can exist. When a reverse proxy terminates TLS, the browser-to-proxy connection and proxy-to-origin connection are distinct. A secure first hop does not establish the security of the second.

For Cloudflare specifically, Full (strict) encrypts the origin connection and validates its certificate. The origin certificate must meet the documented validity, issuer, and hostname requirements. Check the hosting provider's integration instructions before selecting a mode; this article does not verify any existing site's setting.

What a CDN can cache—and why that matters

A CDN can deliver assets from distributed locations and reduce repeated origin work. It is not the origin's source of truth. An uncached request still depends on upstream availability, and a cache hit may deliver an older permitted representation.

Cache policy should match content. A versioned public image can tolerate a long lifetime. A personalized account page must not become a shared response for unrelated users. An updated article may need revalidation or a targeted purge, depending on the host and CDN.

MDN's HTTP caching guide explains three easily confused directives: private restricts storage to private caches, no-cache requires validation before reuse, and no-store tells caches not to store the response. Managed CDN rules can have their own behavior, so inspect both headers and provider configuration.

Proxying is an integration decision

In Cloudflare's proxied mode, supported web records resolve to Cloudflare addresses and HTTP traffic passes through its network. DNS-only mode returns the configured destination without that HTTP proxy layer.

Do not enable proxying for every record indiscriminately. Mail routing, verification aliases, non-HTTP services, and some hosted-platform integrations require different treatment. A target already behind another provider can also have compatibility restrictions. Follow the platform's documented custom-domain procedure, then test before and after the change.

A calm troubleshooting order

  1. Define the failure: exact hostname, path, time, network, and visible error.
  2. Inspect delegation and DNS: confirm the active nameservers and expected address or alias records.
  3. Inspect TLS: certificate identity, validity, and whether the failure occurs at the edge or origin.
  4. Inspect HTTP: status, redirects, cache headers, and whether the requested route exists.
  5. Inspect dependencies: missing images or scripts may fail independently of HTML.
  6. Change one layer: preserve a rollback path and record the result.

A useful incident note says “the authoritative answer is correct, but one recursive resolver still returns the previous target.” That narrows the problem. “DNS is not safe” does not. Evidence at the right layer makes fixes smaller, faster, and easier to defend.