The domain is configured, but the site will not open: debugging DNS

The container is running, deployment is green, and the A record has changed, yet the site will not open on your laptop. Comparing request paths is a better starting point than restarting the application.

Every address here is illustrative: example.com is the domain, 203.0.113.10 is the new server, and 198.51.100.20 is the old one. Command output is simulated and contains no real infrastructure data.

Where an old address can remain

Browser → OS cache → router / VPN / ISP resolver → authoritative DNS

This is a simplified path. A browser may use its own DNS over HTTPS, and a VPN may provide separate resolvers. A successful dig therefore does not prove that the browser receives the same answer.

Start with two otherwise identical HTTPS requests. Change only how curl selects the IP.

1. Compare normal resolution with a pinned IP

curl --head --location --max-time 15 https://example.com
curl --head --location --max-time 15 --resolve example.com:443:203.0.113.10 https://example.com

--resolve supplies an IP for one host/port pair in that curl invocation. The URL still contains the domain, so TLS verification uses example.com. This avoids the certificate name mismatch you might get by opening https://203.0.113.10. See the curl manual.

Use the results to narrow the investigation:

Normal request	Pinned request	What to check next
Timeout or DNS error	Expected site	DNS answers and caches
Certificate error	Valid HTTPS	Whether normal DNS reaches another node
Both fail	Same failure	Server, ports, proxy, certificate
Both work	Both work	Browser, its DNS, proxies, or extensions

With a CDN, its public IP may intentionally differ from the origin server’s IP. Investigate the CDN path separately: bypassing it with --resolve does not establish that the CDN itself is healthy.

2. Inspect the DNS answer and TTL

dig example.com A +noall +answer
dig example.com AAAA +noall +answer

An illustrative stale answer:

example.com.  840  IN  A  198.51.100.20

840 is the remaining TTL in this answer, in seconds. This cache may retain the record for about another 14 minutes. TTL bounds DNS record caching; see RFC 1035.

A new TTL set at the provider does not retroactively shorten an already cached answer’s lifetime. A changed record therefore need not become visible to every device immediately.

For a planned move, lower TTL ahead of time and let the previous value expire before switching IPs.

3. Compare resolvers

Query public resolvers directly:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

Find the authoritative nameservers:

dig example.com NS +short

Replace the placeholder ns1.example.net with one of the returned names:

dig @ns1.example.net example.com A +noall +answer

If the authoritative server returns the new IP while your resolver returns the old one, inspect the latter’s TTL. If the authoritative answer is also old, you may have edited the wrong zone or the domain may be delegated to another provider.

Check the domain’s active nameservers in the registrar’s control panel. Adding a record in an unused DNS panel does not change the domain’s actual answer.

4. Account for OS and browser caches

On macOS, inspect the system resolver’s answer:

dscacheutil -q host -a name example.com

On Linux, query through the system’s name resolution mechanism:

getent ahostsv4 example.com

Compare this with dig. Also check the hosts file, the browser’s secure DNS setting, and resolvers supplied by a VPN. Avoid publishing your entire network configuration: it may contain internal domains and addresses.

Flushing a computer’s DNS cache does not flush a router’s cache. Clearing cached browser pages does not make an ISP resolver immediately discard an old IP either.

Testing through mobile internet can provide a quick comparison. It changes several conditions at once, so treat the result as a clue rather than proof of one particular cause.

5. Remember IPv6

A correct A record does not rule out a broken AAAA record. Compare:

curl -4 --head --max-time 15 https://example.com
curl -6 --head --max-time 15 https://example.com

If IPv4 works and IPv6 fails, check AAAA and actual IPv6 reachability. A failed curl -6 alone does not establish a domain problem: your current network might have no IPv6 route.

Keep an AAAA record only for a working IPv6 address. If IPv6 is not configured, remove the stale record rather than disabling IPv6 on every device.

When curl works but the browser does not

Open the full https:// URL. Check whether the browser ended up on www, which may lack DNS or a certificate. Record the browser’s exact error: name resolution failures, timeouts, and certificate errors need different checks.

Try another window or browser and compare DNS and proxy settings. If using a VPN, note whether the result changes with and without it. Change one setting at a time so you can identify which change affected the outcome.

What to share for diagnosis

The error text, timestamp, two curl results, and one dig result are often enough. Before sharing, replace real domains, client addresses, and authorization headers:

domain: example.com
expected_ip: 203.0.113.10
client_ip: ********
Authorization: Bearer ********

Do not share an unchecked HAR file: it may include cookies, tokens, query parameters, and response bodies.

When authoritative DNS is correct, the pinned request works, and the local resolver still returns an old IP with a decreasing TTL, restarting the app will not help. Wait for expiry or refresh the specific resolver serving the stale answer.