How DNS Connects a Domain to a Website

Typing a domain into a browser starts a lookup, not a direct connection to a magical address book inside the website. DNS supplies records that help the browser find a destination. The browser must still reach that destination, negotiate security, and request the correct site. Understanding those separate stages prevents a certificate or hosting problem from being misdiagnosed as “DNS propagation.”

Separate the registrar, nameservers, and host

The registrar manages registration of the domain. Authoritative nameservers publish its DNS records. A hosting service serves content at an address or provider target. One company may provide all three, but the responsibilities remain separate. Moving hosting does not necessarily require transferring the domain registration, and editing a zone at a provider that is not authoritative will not change public answers.

RFC 1034 describes the domain-name hierarchy, authoritative servers, resolution, and caching concepts underlying DNS. It is a foundational specification with later extensions, not a complete guide to every modern provider feature. For everyday work, first establish which nameservers are delegated for the domain and which zone they actually serve.

A name is divided into labels. In a hypothetical address such as docs.example.org, the browser may ask for records for that entire hostname. Creating a record for example.org does not automatically create every subdomain. Wildcards have specific matching behavior and should not replace a deliberate inventory of the names your service uses.

Know which record answers which question

An A record supplies an IPv4 address; an AAAA record supplies an IPv6 address. A CNAME aliases a name to another name rather than directly holding an IP address. MX records concern mail delivery and TXT records carry text used by several verification and policy systems. Changing web hosting should not accidentally remove the email records that keep the domain's mail working.

Cloudflare's DNS explanation distinguishes recursive resolvers from authoritative servers and describes caching during lookup. The recursive resolver does work on behalf of the client, while the authoritative server supplies answers for its zone. A provider may also proxy web traffic, so an address returned to the browser might be the provider's edge rather than the origin server.

Ordinary DNS records do not contain an entire page URL with a path. Pointing a domain at a website and redirecting a visitor to a particular path are different operations. Provider-specific alias or flattening features can make apex-domain setup easier, but follow that provider's documented configuration rather than assuming every DNS editor accepts the same records.

1. The browser asks its configured resolver for the hostname.
2. The resolver uses cached answers or follows delegation to authority.
3. The authoritative zone returns the relevant record or alias.
4. The browser connects to the resulting service and checks TLS.
5. The web server uses the requested hostname and path to serve content.

Understand caches before changing records

A record's time to live, or TTL, tells caches how long they may retain an answer under the protocol's rules. Lowering a TTL after a resolver already cached an older answer does not retroactively replace that cached entry. Plan changes in advance where possible, keep the previous destination available during a transition, and verify the actual authoritative answer before blaming remote caches.

A missing-name answer can also be cached. Different clients can observe different results during a transition because they use different resolvers and cached state. That does not mean every inconsistent result has the same cause. A stale browser cache, an old service worker, an incorrect IPv6 record, and a hosting misconfiguration can each produce symptoms that resemble a DNS problem.

A hypothetical documentation-site move

Imagine a hypothetical team moving docs.example.org from one static host to another. The team exports or records the current zone, confirms its authoritative nameservers, and lists the existing A, AAAA, CNAME, MX, and verification records. Only the documentation hostname needs to change. The mail records and unrelated application subdomains remain outside the planned edit.

Before changing DNS, the team configures the new host to recognize docs.example.org and checks the provider's certificate process. It then updates the relevant record and queries both an authoritative server and a recursive resolver. If DNS now points to the new service but HTTPS presents the wrong certificate, the team investigates hosting and certificate configuration instead of repeatedly changing records.

This example is hypothetical and contains no real destination addresses. A successful lookup alone would not prove the documentation content is correct. The team still opens a deep link, checks redirects and assets, and verifies that the old host can remain available for the planned transition. Recovery instructions retain the previous record values without exposing unrelated account credentials.

Diagnose from the outside inward

Check the exact hostname, record type, authoritative answer, recursive answer, connection result, certificate, and HTTP response in that order. Tools such as dig or nslookup can inspect records, but their output needs context: which server answered, whether the result was cached, and whether you asked for IPv4 or IPv6. A screenshot of one successful lookup is narrow evidence.

DNSSEC, when properly configured, adds authentication of DNS data; it does not encrypt the website's content or replace TLS. A broken delegation or signing configuration can prevent resolution even if the origin server is healthy. Treat security-related DNS changes as a separate planned operation with provider-specific guidance and a recovery path.

DNS change checklist

• Confirm registrar, delegated nameservers, and authoritative zone.
• Inventory web, mail, verification, and IPv6 records before editing.
• Distinguish DNS targets from redirects and URL paths.
• Plan TTL and old-host availability before the transition.
• Check authoritative and recursive answers separately.
• Verify TLS, deep links, assets, and content after resolution.
• Retain prior record values and a clear rollback decision.