What to do if DNS resolution fails? Detailed troubleshooting methods

　　When setting up a website, migrating a server, or changing domain registrar, many people encounter the problem of DNS resolution not working. Even though A records, CNAME records, or MX records have been added, the website still won't open, the domain name still points to the old server, and it may even display a "This website cannot be accessed" message. If you encounter a similar situation, don't panic.

　　What does "DNS resolution not working" mean?

　　The role of DNS (Domain Name System) is to translate domain names into IP addresses. When you enter a website address in your browser, the system looks up the corresponding IP address through a DNS server and then accesses the server.

　　"DNS resolution not working" typically means: you've modified the DNS records, but access still points to the old IP; you've added a new domain name record, but access results in a "server not found" message; emails cannot be sent or received (MX records are not working); access is possible in some regions, but not in others.

　　Essentially, this situation is due to a DNS query result that is inconsistent with expectations.

　　Common Reasons for DNS Resolution Failure

　　Before formal troubleshooting, understand the common causes, such as incomplete resolution propagation (cache not refreshed), uncleared local DNS cache, domain name not pointing correctly to the current DNS service provider, incorrect DNS record entry, excessively high TTL setting, abnormal domain status (not registered, suspended), server not listening on the corresponding port, CDN cache not refreshed, and recursive DNS server cache issues. We will now troubleshoot in order of increasing complexity.

　　Step 1: Confirm if DNS resolution is truly not working

　　1. Use nslookup to check the resolution results

　　Execute the following in the Windows or macOS terminal:

nslookup yourdomain.com

　　Example output:

Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    yourdomain.com
Address: 1.2.3.4

　　Key points to check: Is the returned IP the target IP you set? Is the DNS server queried correct? If an old IP is returned, it means the cache has not been refreshed or the record has not taken effect.

　　2. Use the `dig` command (more professional)

　　Linux or macOS can use:

dig yourdomain.com

　　View key fields:

ANSWER SECTION:
yourdomain.com.  600  IN  A  1.2.3.4

　　The 600 here represents TTL (time to volume) seconds.

　　Step 2: Check if it's a local cache issue.

　　Often, the DNS resolution is already in effect, but your computer's cache hasn't been refreshed.

　　Clear the DNS cache in Windows.

ipconfig /flushdns

　　Clear DNS cache on macOS

sudo killall -HUP mDNSResponder

　　After cleaning, try accessing the site again.

　　Step 3: Check if the domain name points to the correct DNS server.

　　Sometimes you add a record to a DNS platform, but the domain name isn't using that DNS service.

　　Query the DNS server used by the domain name:

nslookup -type=ns yourdomain.com

　　Example output:

yourdomain.com  nameserver = ns1.exampledns.com
yourdomain.com  nameserver = ns2.exampledns.com

　　Confirm: Do these DNS servers belong to your current DNS service provider? Have you recently changed your DNS servers? If you changed your DNS servers, it may take 24-48 hours for the changes to propagate.

　　Step 4: Check if the DNS records are entered correctly.

　　Common errors include: incorrect IP address in the A record, incorrect CNAME record, incorrect host record, and multiple conflicting records.

　　Note: The same host record cannot contain both A and CNAME records simultaneously, and a CNAME record cannot directly point to an IP address.

　　Step 5: Check if the TTL is too high.

　　TTL represents the cache time. If the original TTL was set to 86400, it means a 24-hour cache. After modification, it may take a day to refresh.

　　Recommendation: Before modifying the DNS records, set the TTL to 300 seconds and wait for the old TTL to expire before modifying the records.

　　Step 6: Is the server actually listening?

　　Sometimes the DNS is already effective, but the server is not running.

　　Check the server port:

　　Linux execution:

netstat -tulnp | grep 80

　　or：

ss -tulnp | grep 80

　　Check if it exists:

tcp  LISTEN  0  128  0.0.0.0:80

　　If port 80 is not being listened to, it means the web service is not running.

　　Step 7: Check if the firewall is allowing access.

　　A blocked port on the server firewall will also cause inaccessibility.

　　Check firewall status (Linux):

firewall-cmd --list-all

　　Allow port 80:

firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --reload

　　Step 8: Check if CDN is enabled

　　If the domain name is connected to a CDN, the DNS resolution actually points to the CDN node, not the server IP. At this point, you need to log in to the CDN backend, check if the origin IP is correct, and refresh the CDN cache. Otherwise, you will encounter the situation of "DNS is effective but the website cannot be opened".

　　Step 9: Test DNS resolution across regions

　　The DNS cache refresh time varies in different regions.

　　You can use public DNS for testing:

nslookup yourdomain.com 8.8.8.8
nslookup yourdomain.com 1.1.1.1

　　If different DNS servers return different IP addresses, it means the propagation is not yet complete.

　　Step 10: Is the domain name status abnormal?

　　Check if the domain name has expired? Is it not verified with real-name authentication? Is it suspended from resolution? Is it locked?

　　You can use the whois query:

whois yourdomain.com

　　Check if the status is:

Status: ok

　　If the following occurs:

clientHold
serverHold

　　This indicates that the domain name has been suspended from resolution.

　　In summary, DNS resolution failure isn't necessarily a cause for alarm; the key is understanding the troubleshooting process. By following the logical steps of "local cache → DNS server → DNS records → server status," the problem can be located. For website owners, understanding DNS propagation mechanisms, TTL principles, and server listening status is more important than simply waiting. If you frequently migrate servers, deploy Hong Kong cloud servers, or conduct cross-border business, it's recommended to reduce the TTL before making any changes and prepare a comprehensive testing plan to avoid the risk of prolonged website downtime.