Web Delivery Basics: Domains, DNS, HTTP, and HTTPS

Launching on the web means more than uploading files or running a server. A user must be able to type an address, reach the right destination, and trust the connection. That path depends on domains, DNS, HTTP, HTTPS, certificates, and sometimes a CDN or load balancer.

The most useful beginner model is simple: DNS gets the browser to the right place, HTTP asks for resources, HTTPS protects the connection, and hosting returns the bytes.

The request path

When a user opens a URL, the browser follows a chain of decisions.

1. It reads the URL and identifies the protocol, host, path, and query.
2. It asks DNS where the host should point.
3. It opens a network connection to the resolved destination.
4. If the URL uses HTTPS, it validates the server certificate.
5. It sends an HTTP request.
6. The platform, server, or CDN returns a response.
7. The browser loads HTML, scripts, styles, images, and follow-up API requests.

A launch can fail at any step. That is why "the site is down" is not specific enough. The domain may not resolve. DNS may resolve to the wrong target. HTTPS may fail. The server may return a 404. The page may load but scripts may fail. Each symptom points to a different layer.

Domains and DNS

A domain is the human-readable name users remember. DNS is the distributed system that maps that name to routing information.

The apex domain is the root host, such as example.com. A subdomain is a host under it, such as www.example.com or app.example.com. Many managed platforms prefer CNAME records for subdomains because the platform can change its own infrastructure target without asking you to update an IP address.

DNS has caching. A record change may work in one place before it works everywhere. That delay is often called propagation, but it is usually a mix of TTL settings, resolver caches, authoritative nameserver behavior, and where the lookup is made from.

HTTP and HTTPS

HTTP is the application protocol browsers use to ask servers for resources. The request includes a method, path, headers, and sometimes a body. The response includes a status code, headers, and often a body.

Common launch status codes:

HTTPS is HTTP over TLS. It protects confidentiality and helps the browser confirm that it is talking to the expected server. Modern browsers also require secure contexts for many capabilities. A public product should use HTTPS by default.

Certificates and validation

A TLS certificate connects a hostname to a cryptographic identity. Certificate authorities usually require proof that you control the domain before issuing a certificate. Platforms often automate this, but the validation still depends on web or DNS reachability.

Common validation approaches include serving a challenge over HTTP or placing a specific TXT record in DNS. HTTP-based validation is often easier when the web server is reachable. DNS-based validation is useful for wildcard certificates and cases where the web server path is not public yet, but it can be harder to automate safely.

The product lesson is that HTTPS is not just a switch. It depends on domain control, validation timing, certificate issuance, renewal, and correct routing.

CDN and caching basics

A CDN stores and serves content from locations closer to users. Static assets often benefit from long cache lifetimes. HTML documents and API responses usually need more careful caching because they change more often or depend on user identity.

Caching mistakes can look like deployment failures. If users still see the old page after a release, check whether the old HTML, JavaScript, or image files are cached. Fingerprinted assets help because each new build gets new file names.

First DNS troubleshooting checklist

• Confirm the domain is registered and not expired.
• Confirm the nameservers at the registrar match the DNS provider you are editing.
• Query the exact hostname, not only the apex domain.
• Check whether you need an A, AAAA, CNAME, or TXT record.
• Remove conflicting records for the same hostname when the provider disallows them.
• Wait for TTL and provider propagation before assuming the platform is broken.
• Test both example.com and www.example.com if users might use both.

Flash Launch note

Flash Launch exposes domain binding as a stateful process because domain work has hidden waiting periods. A good launch platform should show whether it is waiting for DNS, verifying ownership, issuing a certificate, or already serving traffic.

Related reading

• Bind a Custom Domain
• Debugging First Launch Failures
• Identity, Security, and Trust Basics
• Launch Glossary