{"id":2365,"date":"2025-11-23T18:01:17","date_gmt":"2025-11-23T15:01:17","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/website-not-resolving-fix-dns_probe_finished_nxdomain-and-common-dns-errors-step%e2%80%91by%e2%80%91step\/"},"modified":"2025-11-23T18:01:17","modified_gmt":"2025-11-23T15:01:17","slug":"website-not-resolving-fix-dns_probe_finished_nxdomain-and-common-dns-errors-step%e2%80%91by%e2%80%91step","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/website-not-resolving-fix-dns_probe_finished_nxdomain-and-common-dns-errors-step%e2%80%91by%e2%80%91step\/","title":{"rendered":"Website Not Resolving? Fix DNS_PROBE_FINISHED_NXDOMAIN and Common DNS Errors Step\u2011by\u2011Step"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Seeing <strong>DNS_PROBE_FINISHED_NXDOMAIN<\/strong> or another DNS error when you try to open a website can be confusing and frustrating. The site loads fine for some people, fails for others, or disappears just after you change hosting or move a domain. As a hosting team at dchost.com, we run into these situations every week during migrations, DNS clean\u2011ups, and security reviews. The good news: most DNS problems follow a few predictable patterns, and you can usually pinpoint the cause in a structured way.<\/p>\n<p>This guide walks you through a practical, step\u2011by\u2011step checklist to fix DNS_PROBE_FINISHED_NXDOMAIN and other common DNS errors. We will start with quick checks on your own device and network, then move gradually towards your domain, nameservers, and DNS zone records. Along the way, we will explain key DNS concepts in simple terms and share the same debugging flow we use when helping our own hosting customers. Keep this page open, follow the steps in order, and you will either fix the issue yourself or at least know exactly what to ask your provider to change.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_DNS_PROBE_FINISHED_NXDOMAIN_Actually_Means\"><span class=\"toc_number toc_depth_1\">1<\/span> What DNS_PROBE_FINISHED_NXDOMAIN Actually Means<\/a><\/li><li><a href=\"#Step_1_Quick_Checks_Before_You_Touch_DNS\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1: Quick Checks Before You Touch DNS<\/a><ul><li><a href=\"#1_Check_for_typos_and_the_exact_hostname\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. Check for typos and the exact hostname<\/a><\/li><li><a href=\"#2_Confirm_whether_the_problem_is_just_on_your_side\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. Confirm whether the problem is just on your side<\/a><\/li><li><a href=\"#3_Clear_browser_cache_and_local_DNS_cache\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. Clear browser cache and local DNS cache<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Check_Your_Local_Network_Router_and_DNS_Resolver\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2: Check Your Local Network, Router and DNS Resolver<\/a><ul><li><a href=\"#1_Restart_your_modemrouter\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. Restart your modem\/router<\/a><\/li><li><a href=\"#2_Try_a_different_DNS_resolver_on_your_device\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. Try a different DNS resolver on your device<\/a><\/li><li><a href=\"#3_Check_VPN_firewall_and_hosts_file\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. Check VPN, firewall, and hosts file<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Verify_domain_registration_and_Nameservers\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3: Verify domain registration and Nameservers<\/a><ul><li><a href=\"#1_Make_sure_the_domain_is_registered_and_not_expired\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Make sure the domain is registered and not expired<\/a><\/li><li><a href=\"#2_Confirm_nameservers_are_set_correctly\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Confirm nameservers are set correctly<\/a><\/li><li><a href=\"#3_Understand_propagation_and_TTL\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Understand propagation and TTL<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Inspect_and_Fix_Your_DNS_Zone_Records\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4: Inspect and Fix Your DNS Zone Records<\/a><ul><li><a href=\"#1_Make_sure_the_main_AAAAA_record_exists\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Make sure the main A\/AAAA record exists<\/a><\/li><li><a href=\"#2_Watch_out_for_CNAME_loops_and_apex_CNAME_issues\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Watch out for CNAME loops and apex CNAME issues<\/a><\/li><li><a href=\"#3_Check_for_DNSSEC_misconfiguration\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Check for DNSSEC misconfiguration<\/a><\/li><li><a href=\"#4_Make_sure_your_DNS_zone_exists_on_all_nameservers\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 4. Make sure your DNS zone exists on all nameservers<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_Understanding_Other_Common_DNS_Errors\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5: Understanding Other Common DNS Errors<\/a><ul><li><a href=\"#1_SERVFAIL\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. SERVFAIL<\/a><\/li><li><a href=\"#2_REFUSED\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. REFUSED<\/a><\/li><li><a href=\"#3_Query_timed_out\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Query timed out<\/a><\/li><li><a href=\"#4_DNS_PROBE_FINISHED_BAD_CONFIG_and_similar_browser_errors\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. DNS_PROBE_FINISHED_BAD_CONFIG and similar browser errors<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_Preventing_Future_DNS_Headaches\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6: Preventing Future DNS Headaches<\/a><ul><li><a href=\"#1_Use_clear_DNS_documentation_and_a_single_source_of_truth\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Use clear DNS documentation and a single source of truth<\/a><\/li><li><a href=\"#2_Plan_DNS_changes_with_smart_TTLs\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Plan DNS changes with smart TTLs<\/a><\/li><li><a href=\"#3_Choose_a_robust_DNS_setup_aligned_with_your_hosting\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Choose a robust DNS setup aligned with your hosting<\/a><\/li><li><a href=\"#4_Protect_your_domain_and_DNS_against_hijacking\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Protect your domain and DNS against hijacking<\/a><\/li><\/ul><\/li><li><a href=\"#When_to_Ask_for_Help_And_What_to_Send\"><span class=\"toc_number toc_depth_1\">8<\/span> When to Ask for Help (And What to Send)<\/a><\/li><li><a href=\"#Wrapping_Up_DNS_Errors_Dont_Have_to_Be_Mysterious\"><span class=\"toc_number toc_depth_1\">9<\/span> Wrapping Up: DNS Errors Don\u2019t Have to Be Mysterious<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_DNS_PROBE_FINISHED_NXDOMAIN_Actually_Means\">What DNS_PROBE_FINISHED_NXDOMAIN Actually Means<\/span><\/h2>\n<p>Before trying to fix the error, it helps to understand what it is telling you. Browsers and operating systems use DNS (Domain Name System) to convert a domain name like <strong>example.com<\/strong> into an IP address such as <strong>203.0.113.10<\/strong>. When something goes wrong in that lookup, you see errors like:<\/p>\n<ul>\n<li><strong>DNS_PROBE_FINISHED_NXDOMAIN<\/strong> (Chrome, Edge)<\/li>\n<li><strong>ERR_NAME_NOT_RESOLVED<\/strong> (Chrome)<\/li>\n<li><strong>DNS address could not be found<\/strong> (various browsers)<\/li>\n<\/ul>\n<p><strong>NXDOMAIN<\/strong> literally means \u201cNon\u2011existent domain\u201d. In plain language, the DNS resolver you are using tried to find DNS records for your domain and concluded that the domain does not exist in DNS. That can happen for several reasons:<\/p>\n<ul>\n<li>Your domain name is misspelled.<\/li>\n<li>The domain has expired or is not registered anywhere.<\/li>\n<li>Your nameservers are wrong or not reachable.<\/li>\n<li>Your DNS zone has no A\/AAAA record for the hostname you are trying to open.<\/li>\n<li>There is a DNSSEC or glue record misconfiguration.<\/li>\n<\/ul>\n<p>The same domain can work for one person and fail for another because DNS answers are cached at multiple levels (your browser, operating system, router, ISP, and public resolvers). So the first step is to check whether the problem is local to you or global.<\/p>\n<h2><span id=\"Step_1_Quick_Checks_Before_You_Touch_DNS\">Step 1: Quick Checks Before You Touch DNS<\/span><\/h2>\n<h3><span id=\"1_Check_for_typos_and_the_exact_hostname\">1. Check for typos and the exact hostname<\/span><\/h3>\n<p>It sounds trivial, but we regularly see tickets where the entire problem is a typo or the wrong hostname. Double\u2011check:<\/p>\n<ul>\n<li>Spelling of the domain (for example, <strong>mydoman.com<\/strong> vs <strong>mydomain.com<\/strong>).<\/li>\n<li>Whether you are using <strong>www.example.com<\/strong> or just <strong>example.com<\/strong>.<\/li>\n<li>Whether you added an extra subdomain like <strong>app.example.com<\/strong> that never had DNS records.<\/li>\n<\/ul>\n<p>If only <strong>www.example.com<\/strong> works but <strong>example.com<\/strong> does not (or vice versa), this is almost always a DNS record issue that we will cover later.<\/p>\n<h3><span id=\"2_Confirm_whether_the_problem_is_just_on_your_side\">2. Confirm whether the problem is just on your side<\/span><\/h3>\n<p>To avoid unnecessary DNS changes, first verify if others can reach the domain:<\/p>\n<ul>\n<li>Try on a different device using a different network (for example, mobile data instead of office Wi\u2011Fi).<\/li>\n<li>Use a public DNS lookup tool from multiple locations to see if the domain resolves.<\/li>\n<\/ul>\n<p>If the site loads from another network but not from your current one, the problem is probably local DNS caching, your router, or a corporate\/ISP DNS issue. If nobody can resolve it from anywhere, it is almost certainly a domain, nameserver, or DNS zone configuration problem.<\/p>\n<h3><span id=\"3_Clear_browser_cache_and_local_DNS_cache\">3. Clear browser cache and local DNS cache<\/span><\/h3>\n<p>Modern browsers and operating systems keep their own DNS cache. A stale or corrupted entry there can cause DNS_PROBE_FINISHED_NXDOMAIN even after you fix the real problem at the DNS level.<\/p>\n<p>Steps you can try:<\/p>\n<ul>\n<li><strong>Close and reopen the browser<\/strong>, then try again in a private\/incognito window.<\/li>\n<li>Try another browser (Chrome vs Firefox vs Edge) to see if the error persists.<\/li>\n<\/ul>\n<p>Then clear your OS DNS cache:<\/p>\n<ul>\n<li><strong>Windows<\/strong>: Open Command Prompt as Administrator and run:<br \/><code>ipconfig \/flushdns<\/code><\/li>\n<li><strong>macOS<\/strong> (recent versions): Open Terminal and run:<br \/><code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder<\/code><\/li>\n<li><strong>Linux<\/strong> (systemd\u2011resolved):<br \/><code>sudo systemd-resolve --flush-caches<\/code><\/li>\n<\/ul>\n<p>If flushing the DNS cache fixes the issue for you while others never had a problem, you were dealing with a local caching glitch, not a DNS zone problem.<\/p>\n<h2><span id=\"Step_2_Check_Your_Local_Network_Router_and_DNS_Resolver\">Step 2: Check Your Local Network, Router and DNS Resolver<\/span><\/h2>\n<h3><span id=\"1_Restart_your_modemrouter\">1. Restart your modem\/router<\/span><\/h3>\n<p>Consumer routers often run their own small DNS forwarder and cache. If it misbehaves, you can see DNS_PROBE_FINISHED_NXDOMAIN even if the external DNS is fine. A simple restart often fixes this:<\/p>\n<ul>\n<li>Power off the modem\/router.<\/li>\n<li>Wait 20\u201330 seconds.<\/li>\n<li>Power it on and wait until the connection is stable, then test the site again.<\/li>\n<\/ul>\n<h3><span id=\"2_Try_a_different_DNS_resolver_on_your_device\">2. Try a different DNS resolver on your device<\/span><\/h3>\n<p>If your ISP\u2019s DNS resolver is slow, overloaded, or misconfigured, it may respond with NXDOMAIN or timeouts for domains that resolve perfectly elsewhere. You can temporarily change your DNS resolver to a known public resolver on your device:<\/p>\n<ul>\n<li>On your computer or phone, set the DNS servers manually to a reliable public service such as <strong>1.1.1.1 \/ 1.0.0.1<\/strong> (operated by Cloudflare) or <strong>9.9.9.9<\/strong> (Quad9).<\/li>\n<li>Reconnect to the network and try your website again.<\/li>\n<\/ul>\n<p>If the problem disappears when using another resolver, the issue is probably with your ISP\u2019s DNS or a corporate DNS policy, not with your domain configuration.<\/p>\n<h3><span id=\"3_Check_VPN_firewall_and_hosts_file\">3. Check VPN, firewall, and hosts file<\/span><\/h3>\n<p>In office environments and on developer machines, we often find local overrides that cause NXDOMAIN or send traffic to the wrong server:<\/p>\n<ul>\n<li><strong>VPN<\/strong>: Disconnect from VPN and test again. Some VPNs route DNS through the corporate resolver, which may not know public domains or may block certain zones.<\/li>\n<li><strong>Firewall\/endpoint security<\/strong>: Security software can block certain DNS queries or domains. Temporarily disable it (if safe and permitted) or whitelist the domain.<\/li>\n<li><strong>hosts file override<\/strong>: Check your system\u2019s <code>hosts<\/code> file for manual entries for your domain. On Windows it is at <code>C:WindowsSystem32driversetchosts<\/code>, on Linux\/macOS at <code>\/etc\/hosts<\/code>. A wrong IP there overrides DNS.<\/li>\n<\/ul>\n<p>If none of this helps, it is time to move on to domain, nameserver, and DNS zone checks.<\/p>\n<h2><span id=\"Step_3_Verify_domain_registration_and_Nameservers\">Step 3: Verify <a href=\"https:\/\/www.dchost.com\/domain\/register\">domain registration<\/a> and Nameservers<\/span><\/h2>\n<h3><span id=\"1_Make_sure_the_domain_is_registered_and_not_expired\">1. Make sure the domain is registered and not expired<\/span><\/h3>\n<p>It sounds obvious, but an expired domain is the root cause behind many DNS_PROBE_FINISHED_NXDOMAIN cases we see. When a domain expires, its DNS often stops working before the domain is fully deleted, which leads to intermittent resolution failures.<\/p>\n<p>Use a WHOIS lookup to check:<\/p>\n<ul>\n<li>Whether the domain is actually registered.<\/li>\n<li>Its expiry date and current status (OK, clientHold, redemption, etc.).<\/li>\n<\/ul>\n<p>If you want a deeper understanding of what happens after expiry, you can read our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-yasam-dongusu-ve-dusen-domain-yakalama-rehberi\/\">about the domain lifecycle, grace periods and expired domain backorders<\/a>. In short: if the domain is expired or in redemption, renew it with your registrar first. DNS troubleshooting will not help until the domain is active again.<\/p>\n<h3><span id=\"2_Confirm_nameservers_are_set_correctly\">2. Confirm nameservers are set correctly<\/span><\/h3>\n<p>Every domain must point to one or more <strong>nameservers<\/strong>, which hold the DNS records. If the nameserver information is missing, wrong, or inconsistent, resolvers may return NXDOMAIN or SERVFAIL.<\/p>\n<p>Check via WHOIS and a DNS lookup:<\/p>\n<ul>\n<li>Which nameservers are configured at the registry level (for example, <strong>ns1.yourhost.com<\/strong>, <strong>ns2.yourhost.com<\/strong>).<\/li>\n<li>Whether those nameservers are actually reachable and authoritative for your domain.<\/li>\n<\/ul>\n<p>Common mistakes that lead to DNS_PROBE_FINISHED_NXDOMAIN:<\/p>\n<ul>\n<li>You changed the nameservers but the new DNS provider does not yet have a zone for your domain.<\/li>\n<li>You mistyped the nameserver hostname at the registrar.<\/li>\n<li>You use private nameservers on your own domain (like <strong>ns1.example.com<\/strong>) but did not set up glue records.<\/li>\n<\/ul>\n<p>If you plan to use your own branded nameservers, our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/ozel-ad-sunucusu-ve-glue-record-nasil-kurulur-kendi-dnsine-adim-adim-yolculuk\/\">to private nameservers and glue records<\/a> explains how to register them correctly at the registrar and point them to your DNS server\u2019s IP addresses.<\/p>\n<h3><span id=\"3_Understand_propagation_and_TTL\">3. Understand propagation and TTL<\/span><\/h3>\n<p>After changing nameservers or DNS records, caches across the internet need time to refresh. This delay is controlled by the <strong>TTL (Time To Live)<\/strong> value on your records. During that period, some users may still see the old DNS answers or even NXDOMAIN while others get the new ones.<\/p>\n<p>For critical migrations, we recommend planning TTLs ahead of time, lowering them before the move, and then raising them again afterwards. For a deeper, migration\u2011oriented explanation, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero\u2011downtime DNS changes<\/a>.<\/p>\n<h2><span id=\"Step_4_Inspect_and_Fix_Your_DNS_Zone_Records\">Step 4: Inspect and Fix Your DNS Zone Records<\/span><\/h2>\n<p>If your domain is registered, active, and pointing to the correct nameservers, the next layer to inspect is the DNS zone itself. This is where most practical NXDOMAIN issues live.<\/p>\n<h3><span id=\"1_Make_sure_the_main_AAAAA_record_exists\">1. Make sure the main A\/AAAA record exists<\/span><\/h3>\n<p>For a basic website, you normally need at least:<\/p>\n<ul>\n<li>An <strong>A record<\/strong> for <strong>example.com<\/strong> pointing to your server\u2019s IPv4 address.<\/li>\n<li>Optionally an <strong>AAAA record<\/strong> for the IPv6 address, if your server supports IPv6.<\/li>\n<li>Either an A\/AAAA record for <strong>www.example.com<\/strong> or a CNAME that points <strong>www<\/strong> to <strong>example.com<\/strong>.<\/li>\n<\/ul>\n<p>If you only have a record for <strong>www.example.com<\/strong> but not for the root domain, trying to open <strong>https:\/\/example.com<\/strong> may lead to NXDOMAIN on some resolvers. The reverse is also common: <strong>example.com<\/strong> works, but <strong>www.example.com<\/strong> returns NXDOMAIN because there is no record for <strong>www<\/strong>.<\/p>\n<p>If you want a friendly and complete overview of record types (A, AAAA, CNAME, MX, TXT, etc.), you can read our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">\u201cDNS records explained like a friend\u201d<\/a>. It also covers small mistakes that frequently cause lookup failures.<\/p>\n<h3><span id=\"2_Watch_out_for_CNAME_loops_and_apex_CNAME_issues\">2. Watch out for CNAME loops and apex CNAME issues<\/span><\/h3>\n<p>A <strong>CNAME record<\/strong> says \u201cthis name is an alias of that name, ask there for the real IP\u201d. Two common problems:<\/p>\n<ul>\n<li><strong>CNAME loop<\/strong>: <strong>www.example.com<\/strong> CNAME \u2192 <strong>app.example.com<\/strong>, and <strong>app.example.com<\/strong> CNAME \u2192 <strong>www.example.com<\/strong>. Resolvers cannot find a final A\/AAAA record and may end up returning an error.<\/li>\n<li><strong>CNAME at the zone apex<\/strong>: Many traditional DNS setups do not allow a CNAME for the bare domain <strong>example.com<\/strong> because it must also hold NS and SOA records. Some providers emulate this with ALIAS\/ANAME or CNAME flattening.<\/li>\n<\/ul>\n<p>If you want to understand why putting a CNAME at the root of your domain can be tricky, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/bir-domain-bir-kahve-ve-kokte-cname-dilegi\/\">CNAME at the apex and ALIAS\/ANAME records<\/a> explains the scenarios and safer alternatives.<\/p>\n<h3><span id=\"3_Check_for_DNSSEC_misconfiguration\">3. Check for DNSSEC misconfiguration<\/span><\/h3>\n<p><strong>DNSSEC<\/strong> adds a layer of cryptographic validation to DNS, making it harder for attackers to spoof responses. However, if keys or DS records are misconfigured, resolvers may start responding with <strong>SERVFAIL<\/strong> or appear as NXDOMAIN to end users, even though the zone itself looks correct.<\/p>\n<p>If you recently enabled or changed DNSSEC:<\/p>\n<ul>\n<li>Verify that the DS record at your registrar matches the DNSSEC keys on your authoritative DNS servers.<\/li>\n<li>Regenerate and replace DS records carefully when rotating keys.<\/li>\n<li>Temporarily disable DNSSEC if you suspect a broken setup and need a quick fix.<\/li>\n<\/ul>\n<p>For background on how DNSSEC works and how it protects your domain, see our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-web-sitenizi-nasil-daha-guvenli-hale-getirir\/\">on what DNSSEC is and how it makes your website more secure<\/a>.<\/p>\n<h3><span id=\"4_Make_sure_your_DNS_zone_exists_on_all_nameservers\">4. Make sure your DNS zone exists on all nameservers<\/span><\/h3>\n<p>If you are using multiple authoritative nameservers (which you should for redundancy), all of them must have a consistent copy of the zone. NXDOMAIN or SERVFAIL can appear when:<\/p>\n<ul>\n<li>One nameserver has the zone but another does not.<\/li>\n<li>Zone transfers (AXFR\/IXFR) between primary and secondary are not working.<\/li>\n<li>You changed the zone on one DNS panel but forgot about the other provider.<\/li>\n<\/ul>\n<p>Some organizations mix hosting\u2011provider DNS with a third\u2011party DNS service. If you are in that situation, it is worth reading our piece on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/\">Cloudflare DNS vs hosting DNS and how to choose a nameserver strategy<\/a>. The key idea: pick one place as the true source of DNS records and keep others in sync methodically.<\/p>\n<h2><span id=\"Step_5_Understanding_Other_Common_DNS_Errors\">Step 5: Understanding Other Common DNS Errors<\/span><\/h2>\n<p>While DNS_PROBE_FINISHED_NXDOMAIN is very common in browsers, you may also encounter other DNS errors when testing your domain with diagnostic tools. Understanding the difference helps you troubleshoot faster.<\/p>\n<h3><span id=\"1_SERVFAIL\">1. SERVFAIL<\/span><\/h3>\n<p><strong>SERVFAIL<\/strong> means the resolver tried to get an answer but ran into a problem on the way \u2014 for example, it could not reach an authoritative nameserver, DNSSEC validation failed, or there was an internal error in the resolver. Typical causes include:<\/p>\n<ul>\n<li>Unreachable or misconfigured authoritative nameservers.<\/li>\n<li>Broken DNSSEC signatures or mismatched DS records.<\/li>\n<li>Too many chained CNAMEs or indirection loops.<\/li>\n<\/ul>\n<p>If you see SERVFAIL in public tools while NXDOMAIN appears in the browser, focus on nameserver reachability, DNSSEC, and potential CNAME loops.<\/p>\n<h3><span id=\"2_REFUSED\">2. REFUSED<\/span><\/h3>\n<p><strong>REFUSED<\/strong> tells you that the DNS server was reached but refused to answer, typically due to configuration or access policy:<\/p>\n<ul>\n<li>The DNS server is configured as \u201crecursion only\u201d and will not serve authoritative data to the public.<\/li>\n<li>Queries from your IP or network are blocked.<\/li>\n<li>A firewall or DNS firewall product is actively filtering.<\/li>\n<\/ul>\n<p>If the authoritative server is under your control, check its ACLs and query\u2011policy configuration. If it is managed by your DNS or hosting provider, open a ticket with them including the exact error output.<\/p>\n<h3><span id=\"3_Query_timed_out\">3. Query timed out<\/span><\/h3>\n<p>A <strong>timeout<\/strong> means the resolver sent a query but did not receive a response within the expected time window. This is usually a connectivity problem, not a data problem:<\/p>\n<ul>\n<li>Firewall blocking UDP\/TCP on port 53.<\/li>\n<li>Nameserver down, overloaded, or rate\u2011limiting.<\/li>\n<li>Anycast or load\u2011balancing issues in front of the DNS servers.<\/li>\n<\/ul>\n<p>In such cases, check if your nameserver IPs respond to ping and DNS queries from multiple locations. At dchost.com, we use redundant DNS infrastructure and monitor latency so that our customers\u2019 zones respond consistently across regions.<\/p>\n<h3><span id=\"4_DNS_PROBE_FINISHED_BAD_CONFIG_and_similar_browser_errors\">4. DNS_PROBE_FINISHED_BAD_CONFIG and similar browser errors<\/span><\/h3>\n<p>Browsers may also show messages like <strong>DNS_PROBE_FINISHED_BAD_CONFIG<\/strong>. While the naming differs between browsers, these often indicate:<\/p>\n<ul>\n<li>Local resolver misconfiguration (for example, invalid DNS server IP in your network settings).<\/li>\n<li>Broken or inconsistent entries in your OS resolver cache.<\/li>\n<li>Router DNS issues or captive portals on public Wi\u2011Fi.<\/li>\n<\/ul>\n<p>The steps from earlier \u2014 flushing DNS cache, changing resolver, and restarting your router \u2014 are usually effective in resolving these.<\/p>\n<h2><span id=\"Step_6_Preventing_Future_DNS_Headaches\">Step 6: Preventing Future DNS Headaches<\/span><\/h2>\n<p>Once your site is resolving again, it is worth spending a bit of time to make sure you do not repeat the same painful DNS incident during your next migration or domain change.<\/p>\n<h3><span id=\"1_Use_clear_DNS_documentation_and_a_single_source_of_truth\">1. Use clear DNS documentation and a single source of truth<\/span><\/h3>\n<p>DNS problems often arise when different people edit records in different control panels without a shared plan. We strongly recommend:<\/p>\n<ul>\n<li>Keeping a simple internal document that lists your domains, nameservers, and critical records (A\/AAAA, MX, TXT for SPF\/DKIM\/DMARC, etc.).<\/li>\n<li>Choosing one DNS provider as the \u201csource of truth\u201d and avoiding ad\u2011hoc edits on secondary systems.<\/li>\n<li>Reviewing DNS whenever you move hosting, email, or CDNs to avoid leftover or conflicting records.<\/li>\n<\/ul>\n<h3><span id=\"2_Plan_DNS_changes_with_smart_TTLs\">2. Plan DNS changes with smart TTLs<\/span><\/h3>\n<p>If you are preparing a migration \u2014 for example moving from one hosting environment to another \u2014 DNS is a key part of your cut\u2011over plan. Lower TTLs ahead of time so changes propagate quickly, then increase them again to reduce load and improve caching afterwards. Our detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero\u2011downtime migrations<\/a> shows how we approach this in real projects.<\/p>\n<h3><span id=\"3_Choose_a_robust_DNS_setup_aligned_with_your_hosting\">3. Choose a robust DNS setup aligned with your hosting<\/span><\/h3>\n<p>Whether you run a single business site or a multi\u2011tenant SaaS, DNS should match your hosting architecture. Some setups rely on your hosting provider\u2019s DNS, others use a specialized DNS platform, and some use a hybrid. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/\">Cloudflare DNS vs hosting DNS and nameserver strategy<\/a> discusses trade\u2011offs like latency, advanced features, and operational simplicity.<\/p>\n<p>At dchost.com we provide DNS management integrated with our shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s and colocation services, so you can keep domains, DNS and servers under one roof and reduce the chance of configuration drift.<\/p>\n<h3><span id=\"4_Protect_your_domain_and_DNS_against_hijacking\">4. Protect your domain and DNS against hijacking<\/span><\/h3>\n<p>DNS errors are sometimes a symptom of security issues rather than simple misconfigurations. Protect your domain by:<\/p>\n<ul>\n<li>Enabling registrar lock and two\u2011factor authentication on your domain account.<\/li>\n<li>Restricting who can edit DNS and using role\u2011based access.<\/li>\n<li>Considering DNSSEC once you are comfortable managing DNS, to prevent spoofing.<\/li>\n<\/ul>\n<p>For a broader view on keeping your domains safe, check our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/\">domain security best practices including registrar lock, DNSSEC and 2FA<\/a>.<\/p>\n<h2><span id=\"When_to_Ask_for_Help_And_What_to_Send\">When to Ask for Help (And What to Send)<\/span><\/h2>\n<p>Sometimes you can follow all the steps above and still feel stuck, especially with complex DNS setups, multi\u2011provider email, or aggressive security policies. At that point, contacting support is the right move \u2014 but the quality of information you send matters a lot.<\/p>\n<p>Prepare the following details before opening a ticket with your DNS or hosting provider (including us at dchost.com):<\/p>\n<ul>\n<li>The exact domain and subdomain that is failing.<\/li>\n<li>A screenshot or copy of the browser error (DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED, etc.).<\/li>\n<li>Results from at least one external DNS lookup tool for that hostname.<\/li>\n<li>A note on recent changes: new hosting, nameserver change, new SSL, DNSSEC enablement, or email provider switch.<\/li>\n<li>Whether the issue appears on multiple devices and networks.<\/li>\n<\/ul>\n<p>With this information, support teams can quickly trace the problem to the correct layer \u2014 local cache, domain, nameserver, DNS zone, or network \u2014 and propose a precise fix instead of guessing.<\/p>\n<h2><span id=\"Wrapping_Up_DNS_Errors_Dont_Have_to_Be_Mysterious\">Wrapping Up: DNS Errors Don\u2019t Have to Be Mysterious<\/span><\/h2>\n<p>DNS_PROBE_FINISHED_NXDOMAIN and related DNS errors look intimidating on the surface, but they almost always come down to a handful of root causes: a missing or expired domain, wrong nameservers, missing A\/AAAA\/CNAME records, or caching issues between your browser and the authoritative DNS server. By working layer by layer \u2014 starting with typos and local DNS cache, then moving through router, resolver, domain registration, nameservers and finally the DNS zone \u2014 you can methodically narrow down where the problem lives.<\/p>\n<p>As the dchost.com team, we follow the same structured playbook when we migrate websites, consolidate domains, or clean up legacy DNS after years of quick fixes. If you prefer not to wrestle with NS, A, AAAA, CNAME and DNSSEC on your own, you can host your sites, VPS, dedicated servers or colocated hardware with us and lean on our experience when you need it. Combine this article with our deep dives on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">DNS record types and common pitfalls<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero\u2011downtime DNS changes<\/a>, and you will be well\u2011equipped to keep your websites resolving reliably \u2014 without waiting for the next DNS error to surprise you.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Seeing DNS_PROBE_FINISHED_NXDOMAIN or another DNS error when you try to open a website can be confusing and frustrating. The site loads fine for some people, fails for others, or disappears just after you change hosting or move a domain. As a hosting team at dchost.com, we run into these situations every week during migrations, DNS [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2366,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2365"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2365\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2366"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}