Website Down? How to Perform DNS Lookup and Troubleshoot Domain Resolution Issues

When a website suddenly becomes inaccessible, many people's first reaction is to check the server: whether the CPU is maxed out, if Nginx is running properly, if the database is down, or simply restart the server. Often, you'll find that the server itself shows no issues, and directly accessing the origin IP works fine, but the domain name fails. Or, your own computer accesses it without problems, but customers report that some regions keep showing "server not found." In most cases, this points to DNS resolution issues.

Before a domain can access a website, it must first use DNS to find the corresponding server IP. If the A record still points to the old server, the CNAME is misconfigured, the local DNS cache hasn't been refreshed, or different ISPs' recursive DNS servers return inconsistent results, the final symptom can be "website inaccessible."

So, when a domain suddenly becomes inaccessible, instead of immediately tinkering with the server, it's better to first check: Where is this domain currently being resolved to? Below, following the typical troubleshooting order in website operations, we'll see how to use DNS lookup to quickly determine whether the problem lies in domain resolution, CDN, network routing, or the origin server.

1. Why Check DNS First When a Website Is Down?

When a user enters a domain name in a browser, it doesn't directly connect to the website server. The normal access process is roughly:

User enters domain
    ↓
Local DNS cache
    ↓
Recursive DNS server
    ↓
Authoritative DNS server
    ↓
A / AAAA / CNAME records
    ↓
CDN node or origin IP
    ↓
Website server

In other words, before the browser establishes an HTTP or HTTPS connection, it must first complete a DNS lookup. If DNS doesn't return the correct address, even if the server is perfectly fine, users still can't access the website.

For example, if the website was originally hosted at:

103.10.1.10

And later migrated to:

103.20.2.20

But the DNS record still returns the old IP:

example.com → 103.10.1.10

Then no matter how well the new server is configured, it's meaningless because user requests never reach it. During troubleshooting, you can quickly assess whether to prioritize DNS checks based on a few symptoms:

Therefore, when a website is down, DNS lookup is often the lowest-cost and fastest way to pinpoint the issue.

2. How to Perform DNS Lookup When a Website Is Down?

When troubleshooting DNS, you don't need to dive into complex records right away.

For typical website access issues, start with three things:

• A record

• AAAA record

• CNAME record

The most critical question is:

Does the IP or CNAME you're getting match what you've actually configured?

1. Use an Online DNS Lookup Tool

If you're not comfortable with the command line, you can use an online DNS lookup tool.

For example, use Chahu DNS Lookup, enter the domain you need to troubleshoot, and you can see the current A, AAAA, CNAME, and other records.

Suppose you query:

www.example.com

And get:

A → 203.0.113.20

First, go to your server or CDN console and confirm:

203.0.113.20

Is that the server address you're actually using?

If the backend has been changed to:

203.0.113.80

But DNS still returns .20, the problem is likely in the DNS record or cache. An online lookup also helps avoid relying solely on your local DNS cache.

2. Use nslookup

Windows, macOS, and Linux all support command-line DNS queries.

On Windows, you can use:

nslookup example.com

Normally, you'll see something like:

Name:    example.com
Address: 203.0.113.20

If you see:

Non-existent domain

Or no valid address at all, you need to check the domain itself and DNS configuration.

You can also specify a public DNS, for example:

nslookup example.com 8.8.8.8

Then try another DNS:

nslookup example.com 1.1.1.1

If different DNS servers return different results, the issue may be related to DNS caching or propagation.

3. Use dig for More Detailed Checks

On Linux, macOS, or environments with the necessary tools, you can use:

dig example.com

To view only the A record:

dig example.com A

To query CNAME:

dig www.example.com CNAME

To query a specific DNS server:

dig @8.8.8.8 example.com

dig provides more information than nslookup, making it especially useful for troubleshooting TTL, authoritative DNS, and CNAME chains.

However, for most site owners, the core isn't the tool itself, but confirming:

Are the resolution results from different queries what you expected?

3. The 4 Most Common A Record and CNAME Resolution Failures

Getting a DNS result doesn't mean the configuration is correct.

Many websites fail because DNS "has a result, but it's the wrong one."

1. A Record Still Points to the Old Server

This is very common after server migration.

For example, old server:

198.51.100.10

New server:

198.51.100.50

But DNS still returns:

example.com → 198.51.100.10

In this case, check:

• Whether the A record in the DNS console was actually modified successfully;

• Whether you modified the wrong domain;

• Whether @ and www are configured separately;

• Whether there are multiple A records;

• Whether the old record is still present.

After migration, a common situation is:

example.com → new server
www.example.com → old server

So accessing the domain without www works, but www fails.

Therefore, don't just check one address; at least check both:

example.com
www.example.com

2. Incorrect CNAME Configuration

If your website uses a CDN, you typically don't point the domain to a fixed IP but use a CNAME.

For example, the CDN provider gives you:

abc123.cdn-provider.com

In DNS, you should configure:

www.example.com
        ↓
CNAME
        ↓
abc123.cdn-provider.com

If the CNAME is misspelled, the record wasn't saved, or it still points to an old CDN address, the website may fail to load.

So, if the website fails after enabling CDN, the first thing to check is:

www.example.com's CNAME

Does it exactly match the target domain provided in the CDN console?

Pay special attention to extra characters during copy-paste, incorrect host records, and leftover old configurations.

3. A Record and CNAME Conflict

The same hostname should not have both A and CNAME records simultaneously.

For example:

www.example.com → A → 203.0.113.20

And also:

www.example.com → CNAME → abc.cdn.com

Such conflicting configurations may be rejected by the DNS provider or leave anomalies during migration or historical settings.

If you've just enabled CDN, re-check whether the original A record has been handled as required by the provider.

Don't assume that just because "the website was configured this way before," the old record can stay.

4. AAAA Record Points to an Invalid IPv6 Server

This is a commonly overlooked issue.

Suppose the A record is correct:

A → 203.0.113.20

But there's also:

AAAA → 2001:db8::1234

And that IPv6 address is no longer valid.

Some devices that support IPv6 may prioritize the AAAA record, leading to a strange situation:

Some people access it fine, while others can't at all.

If your server doesn't have IPv6 properly deployed but the DNS still has an old AAAA record, this is worth checking.

4. Why Can I Access It, but Other Regions Can't?

The most troublesome scenario isn't when everyone can't access the site, but when:

It loads instantly for you, but customers in other regions always fail.

This often makes admins think "the website is clearly fine."

In reality, DNS doesn't give all users the same cached result globally at the same time.

DNS Cache and TTL Cause Resolution Desynchronization

Suppose the previous resolution was:

example.com → 103.10.10.10
TTL = 3600

Now changed to:

example.com → 103.20.20.20

Although the authoritative DNS record has been updated, recursive DNS servers in different regions may still cache the old result.

So for a short period, you might see:

Shanghai Telecom    → 103.20.20.20
Beijing Unicom     → 103.10.10.10
Guangzhou Mobile   → 103.10.10.10
Overseas DNS       → 103.20.20.20

This naturally leads to different access experiences.

If the old server has been shut down, users still getting the old IP will directly fail to access.

Don't Just Check Your Own Computer

Running locally:

nslookup example.com

Only tells you what your current DNS returns.

It doesn't represent what users in other provinces, ISPs, or overseas networks see.

A more effective method is to use a multi-node DNS lookup, such as Chahu, to see resolution results from different regions and ISPs for the same domain.

If most nodes already return the new IP, but a few still show the old one, the issue is likely:

• TTL hasn't fully expired;

• Some recursive DNS servers still have cached data;

• ISP DNS updates are slower.

If you see completely unrelated IPs, you need to investigate DNS pollution, resolution routing, or CDN scheduling.

5. DNS Is Normal but the Site Still Won't Load—What to Check Next?

If the query confirms:

example.com → correct IP

That only means DNS is basically fine.

There are still TCP, TLS, HTTP, CDN, and origin server stages.

At this point, stop focusing on DNS and move to the next layer.

1. Start with a Ping Test

Try:

ping example.com

Focus on two things:

First, whether the IP resolved during ping is still correct.

Second, whether there's obvious packet loss or latency anomalies.

If you need to check multiple regions, you can use Chahu's multi-node ping test to compare connectivity across different networks. But note:

Ping failure doesn't necessarily mean the website is down.

Many CDNs, cloud servers, or firewalls disable ICMP, so ping timeouts are only a reference, not proof of server failure.

2. Check Ports 80 and 443

For typical websites, the most important are:

TCP 80
TCP 443

Suppose DNS is correct:

example.com → 203.0.113.20

But port 443 can't establish a connection, then the problem is no longer DNS. Possible causes include:

• Nginx or Apache isn't running;

• Cloud security group doesn't allow 443;

• System firewall is blocking;

• CDN node can't connect to origin;

• Web service is listening on the wrong address.

Especially for HTTPS sites, if 443 is unreachable, browsers can't access normally.

3. Perform HTTP/HTTPS Tests

The website actually serves content over HTTP/HTTPS. So after DNS and ping are fine, continue testing HTTP responses. Key things to observe:

• HTTP status code;

• TCP connection;

• TLS handshake;

• TTFB;

• Whether the page returns successfully.

Different status codes point to different issues:

For example:

DNS OK
Ping OK
HTTPS returns 502

In this case, continuing to modify DNS is pointless; focus on CDN origin or the origin web service.

6. What Do Common Browser Errors Mean?

When troubleshooting a website that won't load, the worst thing is to say "the page shows an error." The English text in the browser often gives you the most direct clue. When you encounter an issue, first copy that error code, then check against the common scenarios below:

1. DNS_PROBE_FINISHED_NXDOMAIN

Simply put, this means "the internet's navigation system can't find this domain at all."

If your users see this, it's likely the domain resolution layer is broken. Check:

• The domain itself: Check if the domain has expired or is locked by the registrar.

• DNS records: Check if the NS (Name Server) settings are messed up, if A or CNAME records were accidentally deleted, or if changes haven't propagated yet.

• Security settings: If DNSSEC is enabled, check if the signature is misconfigured, causing validation failure.

Recommendation: First, use a webmaster tool or terminal to query a public DNS. If even third-party tools can't find anything, stop troubleshooting the server and go to the domain console to check resolution.

2. ERR_NAME_NOT_RESOLVED

This is also a DNS error, but unlike NXDOMAIN, it often leans more toward the client side (your computer/network) failing to resolve.

Recommendation: Run nslookup for your domain in the command line.

• If external and public DNS (like 114 or 8.8.8.8) can resolve the IP, but your local computer can't, the problem is local:

  • Check if the manually configured DNS is down.

  • Clear the local DNS cache (on Windows, run ipconfig /flushdns).

  • Restart your router, or suspect your ISP's DNS is having issues.

3. ERR_CONNECTION_TIMED_OUT

This error means: The domain resolved to an IP, but your computer sent a request and got no response until timeout.

Since you got an IP, DNS is likely fine. Now think about network path and server:

• Server status: Is the machine down? Or is CPU/memory maxed out, causing it to be unresponsive?

• Network and routing: Is the network path broken or experiencing severe packet loss?

• Security: Check if the cloud security group allows the port, and if the server's firewall (like iptables/ufw) is blocking requests.

• CDN and origin: If using CDN, check if nodes can reach the origin, or if the origin's network is congested.

4. ERR_CONNECTION_REFUSED

Timeout (TIMED_OUT) means "no response at all," while refused (REFUSED) means "the target server received the request but explicitly rejected it."

This indicates the network path is fine, and the IP and port are reachable, but no program is listening on that port, or it's being actively refused.

For example, if DNS and IP are fine but you get this error when accessing https, check:

• Is the service running? Is Nginx, Apache, or your Node/Java application actually up?

• Port listening: Did you forget to configure port 443? Or is it listening only on 127.0.0.1 instead of 0.0.0.0?

• Container mapping: If using Docker, check if the -p port mapping is missing or incorrect.

5. SSL Certificate Errors

SSL errors look like encryption issues, but often the root cause is inconsistent DNS resolution.

The most typical scenario: you just switched to a new server, changed IPs, or redeployed certificates. But because DNS propagation is delayed, some regions access the new server (certificate valid), while others still hit the old server (certificate expired or not configured), leading to "some access fine, others see certificate warnings."

Recommendation: When you see this error, don't rush to re-run certificate scripts. First, check the actual access situation of the affected users:

• Have them ping the domain to see if the resolved IP is the new or old server.

• Check the certificate status on the CDN, to see if you only updated the origin but forgot the CDN.

• Confirm the certificate's domain coverage, to see if you missed the www subdomain or the root domain.

7. How to Distinguish Between DNS, CDN, and Origin Server Failures?

Website access involves many layers. The most efficient troubleshooting isn't to review all configurations at once, but to eliminate layer by layer. Refer to this table:

8. Recommended Troubleshooting Order When a Website Is Down

If you're not sure where to start, follow this sequence:

Website down
   ↓
① Query DNS
   ↓
Get IP or CNAME?
 ├─ No → Check domain, NS, A/CNAME
 └─ Yes
      ↓
② Is the result correct?
 ├─ No → Check DNS records, TTL, cache
 └─ Yes
      ↓
③ Are multi-region DNS results consistent?
 ├─ No → Check regional DNS cache, routing
 └─ Yes
      ↓
④ Test Ping / TCP 80 / 443
      ↓
⑤ Test HTTP/HTTPS
      ↓
⑥ Check CDN nodes and origin
      ↓
⑦ Check origin server

The biggest advantage of this sequence is that it separates different failure layers. For example, if DNS doesn't resolve, there's no point adjusting Nginx; if DNS is correct but the site returns 502, there's no point refreshing DNS cache repeatedly.

In real troubleshooting, the most time-consuming part isn't the complexity of the problem, but repeatedly modifying configurations at the wrong layer from the start.

9. How Long After Changing DNS Does It Take to Recover?

Many site owners, after modifying A records or CNAME, keep refreshing the page and think the DNS is misconfigured if it doesn't recover within ten minutes.

In reality, DNS changes don't mean all users get the new record at the same second.

The main factor affecting update time is TTL (Time To Live).

For example, the original record:

TTL = 3600

Means recursive DNS servers can cache this record for 3600 seconds, about 1 hour.

If you change the IP before the cache expires, some DNS servers may still return the old address.

Additionally, other factors include:

• Local OS DNS cache;

• Browser cache;

• Router DNS cache;

• ISP recursive DNS;

• Public DNS update status;

Therefore, after changing DNS, don't just test on one computer repeatedly. Instead, use multiple DNS nodes to confirm the new resolution is gradually taking effect.

Lower TTL Before Server Migration

If you know in advance that you'll change servers or CDN, lower the TTL before the switch. For example, if it was:

3600

Change it to:

300

Wait for the old TTL to mostly expire before migrating. This way, the overlap period for old and new IPs is significantly shortened. After migration and confirming stability, restore the normal TTL.

A website being down is just the final symptom; the underlying cause can vary widely. Sometimes it's just an A record pointing to an old IP, sometimes a CNAME not properly connected to CDN, and sometimes DNS is perfectly fine and the real issue is port 443, SSL, CDN origin, or the origin service. So when troubleshooting, start with DNS.

First, confirm the domain resolves correctly, then verify the resolved IP or CNAME is correct; if only some regions are affected, use multi-node lookup tools like Chahu to compare DNS results from different ISPs. After confirming DNS is fine, continue checking Ping, TCP, HTTP, CDN, and origin.

Following this front-to-back, layer-by-layer elimination approach is usually more effective than repeatedly restarting the server when the site is down. DNS lookup isn't just a standalone speed test; it's the first dividing line in the entire website troubleshooting process: If DNS isn't working, don't touch the server; if DNS is correct, move to the next layer.