DNS for Web Hosting: From Domain Name to Server IP

DNS resolution for web hosting: the end-to-end path

When a user types www.example.com into a browser, DNS translates that name into an IP address the client can connect to. In hosting, DNS is also how you steer traffic to CDNs, load balancers, mail systems, and verification endpoints. Understanding the exact resolution chain helps you troubleshoot the common “works on IP but not on domain” problems quickly.

1) Stub resolver behavior (on the client)

The stub resolver is the DNS component on the client device (OS and/or browser) that asks a recursive resolver for answers. It typically does not walk the DNS hierarchy itself; it forwards queries to a configured resolver (ISP resolver, enterprise resolver, or a public resolver like 1.1.1.1/8.8.8.8).

• Cache first: The client checks local caches (OS cache, browser cache, sometimes a local DNS forwarder). If a cached record is still within its TTL, the client reuses it.

• Choose a resolver: The client uses the DNS servers learned from network configuration (often via DHCP or manual settings). VPN software may override these, which is a frequent source of split-horizon surprises.

• Ask for record types: For web access, the client usually requests A (IPv4) and/or AAAA (IPv6). Many clients try AAAA first or in parallel.

  Continue in our app.

  You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

  Or continue reading below...

  

  Download the app

• Follow CNAMEs indirectly: The stub asks for A/AAAA for the name; if the response contains a CNAME, the resolver will chase it and return the final address records (or the stub will re-query, depending on implementation).

2) Recursive resolver (the “DNS workhorse”)

The recursive resolver performs the full lookup on behalf of the client and caches results. This is the component that actually walks the DNS delegation chain: root servers → TLD servers → authoritative servers for the domain.

• Recursion and caching: The resolver queries upstream authoritative servers and caches answers for the duration of their TTL. It also caches negative answers (like NXDOMAIN) using the zone’s negative caching TTL (from SOA).

• DNSSEC validation (when enabled): Some resolvers validate signatures; misconfigured DNSSEC can cause “domain doesn’t work” for validating resolvers while it works for others.

• Resolver choice matters: Different resolvers can return different answers due to geo-DNS, CDN steering, split-horizon, or stale caches.

3) Authoritative servers (where the truth lives)

Authoritative name servers host the DNS zone for a domain and provide the definitive records. In hosting, these are often managed by your registrar’s DNS, a DNS provider (e.g., managed DNS), or your own authoritative servers.

• Delegation via NS: The parent zone (e.g., .com) lists which authoritative servers are responsible for example.com using NS records. The recursive resolver uses those NS records to find the authoritative servers.

• Glue records: If the authoritative server names are inside the domain they serve (e.g., ns1.example.com), the parent zone may also provide glue A/AAAA records so resolvers can reach them without circular dependency.

• Zone data: The authoritative server answers with the records you configured: A, AAAA, CNAME, MX, TXT, etc., plus the SOA and NS records that define the zone.

Record types you actually use in web hosting

A (IPv4 address)

Maps a hostname to an IPv4 address.

• Typical use: example.com → public load balancer IPv4, or www.example.com → CDN edge IPv4.

• Common pitfall: Pointing at a server’s old IP after a migration, or pointing at an internal/private IP by mistake.

AAAA (IPv6 address)

Maps a hostname to an IPv6 address.

• Typical use: Dual-stack hosting where clients can reach the site over IPv6.

• Common pitfall: Publishing an AAAA record that points to an endpoint not actually serving the site over IPv6. Some clients will prefer IPv6 and fail even though IPv4 works.

CNAME (alias to another name)

Aliases one hostname to another hostname. The target must resolve to A/AAAA (or further CNAMEs) eventually.

• Typical use: www.example.com → example.com, or app.example.com → yourapp.hosting-provider.net, or custom domains to SaaS/CDN endpoints.

• Rules that matter: A name with a CNAME generally cannot have other record types at the same name (e.g., you can’t have CNAME and MX at example.com in standard DNS).

MX (mail exchanger)

Specifies which servers receive email for a domain.

• Typical use: Pointing mail to Google Workspace, Microsoft 365, or a hosted mail gateway.

• Hosting relevance: Website migrations often forget MX/TXT mail records, causing email delivery failures even if the website works.

TXT (text records for verification and policy)

Used for domain ownership verification and email security policies.

• Typical use: SPF (v=spf1 ...), DKIM public keys, DMARC policy, ACME DNS challenges for certificates, and SaaS verification tokens.

• Common pitfall: Multiple SPF records (should be one), or incorrect quoting/formatting causing verification to fail.

NS (name server delegation)

Lists the authoritative name servers for a zone.

• Typical use: Set at the registrar (delegation) and within the zone itself.

• Common pitfall: Registrar NS points to one provider, but the zone is edited at a different provider. You change records in the wrong place and nothing happens.

Practical hosting scenarios and what they mean

Scenario 1: The site works on the IP but not on the domain

This strongly suggests DNS (or name-based virtual hosting/TLS SNI) rather than basic reachability. A quick way to separate causes is: if https://<IP> loads the expected site but https://www.example.com does not, DNS is the first suspect.

• Likely DNS causes: Missing/incorrect A/AAAA record, stale cached record due to TTL, wrong CNAME target, or resolver returning an internal address (split-horizon).

• Non-DNS causes to keep in mind: The server may host multiple sites and requires the correct Host header; TLS certificate may not match when using the IP directly. But if the domain fails to resolve or resolves to the wrong IP, fix DNS first.

Scenario 2: Wrong CNAME chain (or CNAME chain too long)

Many hosting setups use CNAMEs to point a custom domain at a provider-controlled hostname. Problems happen when the chain points to the wrong place, includes a typo, or ends at a name that has no A/AAAA.

• Symptoms: Intermittent resolution, NXDOMAIN at the end of the chain, or resolution to an unexpected provider.

• What to check: Each hop in the chain resolves, the final target has A/AAAA, and you didn’t accidentally create a loop (e.g., a CNAME to b and b CNAME to a).

Scenario 3: Split-horizon DNS (internal vs external answers)

Split-horizon DNS means the same name returns different answers depending on where the query comes from (internal network vs public internet). This is common when internal users should hit private IPs, while external users hit public load balancers.

• Symptoms: The domain works on mobile data but not on corporate Wi-Fi (or vice versa). Or admins see one IP, customers see another.

• What to check: Which resolver is being used (VPN/corporate resolver vs public). Query both an internal resolver and a public resolver and compare results.

Scenario 4: TTL and “propagation” expectations

DNS changes are not instantly visible everywhere because resolvers cache answers for the TTL. “Propagation” is mostly about caches expiring, not about records slowly traveling across the internet.

• Practical expectation: If an A record has TTL 3600 seconds, many resolvers may keep the old IP for up to about an hour after you change it (sometimes longer if intermediate caches exist, or if clients cache too).

• Change planning: Before a migration, lower TTL (e.g., from 3600 to 300) well ahead of time (at least one old-TTL period) so caches refresh faster during cutover.

• Negative caching: If a name didn’t exist and you create it, some resolvers may cache NXDOMAIN for the negative TTL defined by the zone’s SOA, delaying visibility.

Troubleshooting workflow with nslookup/dig (hosting-focused)

The goal is to confirm: (1) which resolver is answering, (2) what authoritative servers say, (3) whether the record chain is correct, and (4) whether the final IP matches the intended public endpoint (load balancer/CDN/origin).

Step 1: Identify which resolver you are using

First, check the DNS server your system is querying. Then test the same name against a known public resolver to compare.

# Query using your default resolver (shows which server answered in many setups) dig www.example.com A # Force a specific public resolver (Cloudflare) dig @1.1.1.1 www.example.com A # Force a specific public resolver (Google) dig @8.8.8.8 www.example.com A

If results differ between resolvers, suspect split-horizon DNS, geo-DNS/CDN steering, or caching differences.

Step 2: Check the authoritative sources (bypass recursion where possible)

Find the domain’s authoritative name servers and query them directly. This tells you what the “source of truth” is, independent of recursive caches.

# Get authoritative NS for the zone dig example.com NS # Query one authoritative server directly for the record you care about dig @ns1.dns-provider.net www.example.com A dig @ns1.dns-provider.net www.example.com AAAA

If the authoritative answer is correct but a recursive resolver is returning old data, you are likely waiting on TTL/negative caching, or the resolver is using stale cache.

Step 3: Validate record targets and CNAME chains

Walk the chain explicitly. Confirm each CNAME target exists and ends in address records.

# Show CNAME (if any) and follow-up targets dig www.example.com CNAME dig target.hosting-provider.net A dig target.hosting-provider.net AAAA # Or ask dig to show the full path it followed (useful for debugging) dig +trace www.example.com

• What “good” looks like: Either www has an A/AAAA directly, or it CNAMEs to a provider name that has A/AAAA.

• Common failure: www CNAMEs to a name that only exists internally, or to a name that was deprovisioned.

Step 4: Confirm returned IP matches the intended public endpoint

In hosting, the “right” IP is usually the public load balancer, CDN edge, or ingress—rarely a random VM IP. Compare the DNS answer to what your hosting platform expects.

# Compare DNS answer to known endpoint IPs dig @1.1.1.1 www.example.com A dig @1.1.1.1 www.example.com AAAA

If DNS returns an unexpected IP, fix the zone records. If DNS returns the expected IP but the site still fails, the issue is likely outside DNS (TLS, HTTP routing, firewall, origin health, etc.).

Step 5: Check TTL to set propagation expectations

Look at TTL values in answers to estimate how long caches may keep old data.

# TTL is shown in the answer section dig @1.1.1.1 www.example.com A

• If TTL is high: Expect slower change visibility. Consider lowering TTL ahead of planned changes.

• If you just created a record: If some resolvers still return NXDOMAIN, check SOA negative caching and confirm you created the record in the correct zone at the delegated provider.

Step 6: Quick checks for MX/TXT/NS when hosting changes affect more than the website

When moving DNS providers or editing zones during a web migration, verify that mail and verification records remained intact.

# Mail routing dig example.com MX # SPF/verification tokens dig example.com TXT # Delegation sanity check dig example.com NS

If NS at the registrar points elsewhere than where you are editing, you are changing the wrong zone. Fix delegation first, then re-check authoritative answers.