Support > About cybersecurity > Tips for troubleshooting DNS resolution errors after website migration
Tips for troubleshooting DNS resolution errors after website migration
Time : 2025-10-20 16:17:35
Edit : Jtti

  Migrating servers is almost inevitable during website maintenance and upgrades. Whether due to insufficient server performance, bandwidth limitations, or to improve access speed and enhance security, moving a website from one server to another is a common practice. However, many webmasters encounter a frustrating issue after completing a migration: their website becomes inaccessible, or some users experience "DNS resolution error" or "unable to find server" messages. While these issues may seem complex, they are often related to DNS resolution anomalies. Mastering systematic troubleshooting techniques is crucial to quickly restore normal access.

  To understand the root cause of DNS errors after migration, it's important to understand the role of DNS in the overall website access process. The Domain Name System (DNS) is like the internet's address book, translating user-entered domain names (such as example.com) into server IP addresses. When a website migrates, the new server typically has a different IP address, necessitating an update to the DNS records to redirect the domain name to the new server. Improper DNS configuration, synchronization, or caching can easily lead to resolution errors or access anomalies.

  The causes of DNS resolution errors after a website migration can be broadly categorized into three types:

  The first is incorrect DNS record configuration. For example, when modifying records on the domain name management platform, the A record may contain the old IP address, omit a subdomain, or accidentally delete key fields like CNAME or MX. This error is the most direct and can prevent the domain name from being correctly resolved.

  The second type of error is a failure to update the DNS cache. Whether it's the user's local system, browser, router, or ISP's DNS server, they all temporarily store the domain name-IP mapping to speed up access. If the cache still points to the old IP address after the server is replaced, access errors will occur. Especially if the old server is offline or unresponsive, the user will see messages such as "DNS_PROBE_FINISHED_NXDOMAIN" or "Server not found."

  The third type of error is DNS propagation delay. Global DNS servers are distributed in different regions, and it takes time for them to synchronize with the latest resolution information. This process can take from a few hours to 24 hours, depending on the TTL value set. The longer the TTL value, the longer the cache will take effect, and the slower the update.

  Now that we understand the cause, let's look at specific troubleshooting strategies.

  Step 1: Verify that the domain name resolution configuration is correct.

  Log in to the domain management console and verify that the A record points to the new server's public IP. If your website uses a CDN or proxy service, confirm that the origin server records are also updated. For websites with multiple domains or subdomains, ensure that all associated records (such as www, api, img, etc.) are correctly configured. If your website uses an SSL certificate, also confirm that the domain bound to the certificate and the DNS resolution point to the same domain.

  Step 2: Use a command-line tool to verify the DNS resolution results.

  In Windows, you can execute the following command from the command prompt:

nslookup example.com

  The "Address" returned by the command is the resolved IP address. If an incorrect IP is displayed or the resolution fails, it means that the DNS configuration has not yet taken effect or there is an abnormality. If the return result is normal but the access is still unavailable, you can further test:

ping example.com

  If the ping timeout occurs but the DNS server is working, it means the DNS server may not be responding. Conversely, if the message "Host not found" appears, the problem lies at the DNS level.

  Step 3: Clear the local DNS cache.

  Sometimes, the problem lies with the client cache. Windows users can run:

ipconfig /flushdns

  Mac users can enter:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

  After the cleanup is complete, restart your browser and access the website again. If the problem disappears, your local cache is the culprit.

  Step 4: Check global DNS propagation.

  Visit websites such as dnschecker.org or whatsmydns.net and enter your domain name to view the resolution status of DNS nodes around the world. If some nodes display the old IP address while others are updated, DNS synchronization is still in progress. Simply wait for the TTL to expire. If all nodes are resolving correctly but some users still can't access the website, check their local DNS or carrier network.

  Step 5: Check DNS server settings.

  Some websites are hosted with third-party DNS service providers. These platforms often provide multiple resolution nodes. Misconfiguration or abnormal service status can also cause resolution failures. You can try temporarily switching your DNS to a public DNS server as a test. If the website returns to normal after the switch, it indicates a problem with the original DNS server.

  Step 6: Confirm that the CDN and DNS origin server are synchronized.

  If your website uses a CDN, be sure to update the CDN origin server IP after migrating servers. Otherwise, users will still be accessing the old node, or even a deactivated server. Check that the origin server configuration in the CDN console is consistent with the new server. Clear the CDN cache to ensure that the content and resolution are synchronized.

  Step 7: Verify firewall and port status.

  Sometimes, DNS resolution may be normal, but access still fails. This may be because the server port is not open. You can use the telnet command to check:

telnet example.com 80

  or

telnet example.com 443

  If the connection fails, it means the firewall is blocking access or the web service (such as Nginx or Apache) is not started. Ensuring that the new server's firewall policy allows external HTTP/HTTPS access is a must-do post-migration check.

  After completing these troubleshooting steps, most DNS resolution issues can be identified and resolved. For website administrators, in addition to post-migration troubleshooting, it's even more important to take preventative measures before the migration. Before the migration, lower the TTL value of DNS records, for example, from 3600 seconds to 300 seconds, to speed up the DNS changes. After the migration, keep the old server online for a short period of time to avoid issues when users continue to access the old IP address. Also, prepare monitoring tools such as Pingdom and UptimeRobot to monitor the new server's availability and latency.

  Also, pay attention to the stability of the DNS service provider. Some low-cost DNS platforms are prone to timeouts or record anomalies under high concurrency conditions, resulting in unstable resolution. For commercial websites, choosing a reliable, authoritative DNS hosting service can effectively reduce risks.

  DNS resolution errors after a website migration may sound complicated, but as long as you understand the DNS mechanism and master the correct troubleshooting methods, you can quickly locate and resolve the problem. From configuration checks to cache refreshes, every step is traceable. Website administrators should not be afraid of DNS issues, but should fully prepare before the migration and conduct systematic verification after the migration. Mastering these troubleshooting techniques will not only ensure a smooth transition for the website, but also help you calmly deal with various network resolution problems in future operations and maintenance.

Relevant contents

What are the measures to deal with segment sweep attacks? What else can be done besides technical protection? Debian system Oracle database performance monitoring tool explanation What are the core requirements for renting a novel website server? In-depth analysis and practical response to IP sweep attacks in data centers DNS security protection strategy: How should enterprises deal with hidden pollution attacks? How to recover after DNS pollution? A self-help tutorial for small and medium-sized enterprise sites Single Domain SSL Certificate vs. Wildcard SSL Certificate Selection Strategies and Practical Guide Nginx log cleaning invalid data identification and classification system Analysis of network equipment required for connecting to Japanese servers Analysis and protection of cookie theft and MFA bypass attack techniques
Go back

24/7/365 support.We work when you work

Support