<p><strong>Short answer:</strong> "DNS server not responding" means your device sent a name lookup to the DNS server it is configured to use and got no answer back in time. Your internet connection itself may be fine; it is the step that turns a name like example.com into an IP address that fails. You can confirm it in ten seconds: if <code>ping 1.1.1.1</code> gets replies but <code>ping example.com</code> fails, DNS is the problem. Then run <code>nslookup example.com 1.1.1.1</code>. If that answers while a plain <code>nslookup example.com</code> times out, the resolver you normally use (usually your router or your ISP) is at fault, and switching to a public resolver fixes it in about a minute. The rest of this guide is the full order of checks, with exact commands for Windows, macOS and Linux.</p>

<h2>What the error actually means</h2>
<p>Windows shows it in Network Diagnostics as "Your computer appears to be correctly configured, but the device or resource (DNS server) is not responding." Chrome and Edge usually report the same failure with a <code>DNS_PROBE</code> error code, and Safari says it "can't find the server." In every case the client asked a resolver to translate a name and nothing usable came back.</p>
<p>That is different from the errors in our <a href="/blog/common-dns-errors-and-fixes">common DNS errors guide</a>. NXDOMAIN means a server <em>did</em> answer and said the name does not exist. SERVFAIL means a server answered and said it could not resolve the name. "Not responding" means there was no answer at all, so the problem almost always sits between your device and its resolver, not in the website's own DNS records. If one site shows <a href="/blog/how-to-fix-dns-probe-finished-nxdomain">DNS_PROBE_FINISHED_NXDOMAIN</a> while everything else loads, that is a different fault with a different fix.</p>

<h2>Step 1: Confirm it really is DNS</h2>
<p>Open a terminal (Command Prompt or PowerShell on Windows, Terminal on macOS or Linux) and run two pings: one to an IP address, one to a name.</p>
<pre>ping 1.1.1.1
ping example.com</pre>
<table>
<thead><tr><th>Result</th><th>What it tells you</th><th>Next step</th></tr></thead>
<tbody>
<tr><td>Both fail</td><td>No network path at all (Wi-Fi, cable, router or ISP outage)</td><td>Fix the connection first; DNS settings will not help</td></tr>
<tr><td>IP replies, name fails</td><td>The connection works, name lookups do not</td><td>Continue with Step 2</td></tr>
<tr><td>Both work</td><td>DNS is working right now</td><td>The problem is one site or an intermittent resolver; test that exact name with nslookup</td></tr>
</tbody>
</table>
<p>Some networks block ping. If <code>ping 1.1.1.1</code> fails but other connections clearly work (a messaging app, a video call), treat it as "IP replies" and carry on.</p>

<h2>Step 2: Find out which DNS server you are actually using</h2>
<p>You cannot fix a resolver until you know which one your device is asking.</p>
<ul>
<li><strong>Windows:</strong> <code>ipconfig /all</code> and read the <em>DNS Servers</em> line for your active adapter, or in PowerShell <code>Get-DnsClientServerAddress -AddressFamily IPv4</code>.</li>
<li><strong>macOS:</strong> <code>scutil --dns | grep nameserver</code></li>
<li><strong>Linux with systemd-resolved:</strong> <code>resolvectl status</code>; on other systems <code>cat /etc/resolv.conf</code>.</li>
</ul>
<p>How to read the address: <code>192.168.1.1</code>, <code>192.168.0.1</code> or <code>10.0.0.1</code> is normally your router, which forwards every lookup to your ISP. <code>127.0.0.53</code> is the local systemd-resolved stub on Linux, so check <code>resolvectl status</code> for the real upstream. An address you do not recognise, such as a leftover VPN resolver or something you once typed in manually, is a strong clue in itself.</p>

<h2>Step 3: Ask a different DNS server directly</h2>
<p>This is the test that splits the problem in half. Run the same lookup three times: once against your normal resolver and twice against public ones.</p>
<pre>nslookup example.com
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8</pre>
<p>A resolver that does not answer looks like this on macOS and Linux (we pointed the lookup at an unused documentation address to reproduce it):</p>
<pre>$ dig +time=2 +tries=1 example.com @192.0.2.1
;; connection timed out; no servers could be reached</pre>
<p>On Windows the same failure prints <code>DNS request timed out</code> instead. A healthy answer from Cloudflare's resolver, run on 24 October 2026, looked like this:</p>
<pre>$ nslookup example.com 1.1.1.1
Server:    1.1.1.1
Address:   1.1.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 104.20.23.154</pre>
<ul>
<li><strong>Your default times out, the public servers answer:</strong> your configured resolver is the problem. Go to Step 4, then Step 5 if it comes back.</li>
<li><strong>All three time out:</strong> something on your device or network is blocking DNS traffic (port 53) itself. Skip to Step 6.</li>
</ul>
<p>In PowerShell the equivalent is <code>Resolve-DnsName -Name example.com -Server 1.1.1.1 -DnsOnly</code>. For more ways to point a lookup at a chosen server, see <a href="/blog/nslookup-specific-dns-server">how to query a specific DNS server with nslookup and dig</a>.</p>

<h2>Step 4: Restart the router and flush the local cache</h2>
<p>Most home routers run a small DNS forwarder. After long uptime, a firmware glitch or an ISP reconnect it can stop answering while the rest of the router keeps working, which is exactly the "IP works, names don't" pattern. Unplug the router for 30 seconds, plug it back in and wait until it has fully reconnected.</p>
<p>Then clear the cache on your device so it stops reusing failures it stored while DNS was broken:</p>
<ul>
<li><strong>Windows:</strong> <code>ipconfig /flushdns</code> (or <code>Clear-DnsClientCache</code> in PowerShell)</li>
<li><strong>macOS:</strong> <code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder</code></li>
<li><strong>Linux (systemd-resolved):</strong> <code>resolvectl flush-caches</code></li>
</ul>
<p>Be realistic about what flushing does: it cannot make a dead resolver answer. It only removes stale entries, which is why it helps after the resolver is back but not before.</p>

<h2>Step 5: Switch to a public DNS resolver</h2>
<p>If your ISP's resolver keeps failing, stop depending on it. These free public resolvers are run by large operators and answer from many locations:</p>
<table>
<thead><tr><th>Provider</th><th>IPv4</th><th>IPv6</th></tr></thead>
<tbody>
<tr><td>Cloudflare</td><td>1.1.1.1, 1.0.0.1</td><td>2606:4700:4700::1111, 2606:4700:4700::1001</td></tr>
<tr><td>Google Public DNS</td><td>8.8.8.8, 8.8.4.4</td><td>2001:4860:4860::8888, 2001:4860:4860::8844</td></tr>
<tr><td>Quad9</td><td>9.9.9.9, 149.112.112.112</td><td>listed on Quad9's own setup page</td></tr>
</tbody>
</table>
<p>Using one address from two different providers (for example 1.1.1.1 and 8.8.8.8) gives you a fallback if one provider has an incident. Our <a href="/blog/best-free-dns-providers-compared">free DNS providers comparison</a> covers the privacy and filtering differences.</p>
<h3>Windows</h3>
<p>In PowerShell as administrator, find your adapter name, then set the servers:</p>
<pre>Get-NetAdapter
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","8.8.8.8")</pre>
<p>To go back to the servers your router hands out, run <code>Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses</code>. The same change is available in Settings under Network &amp; internet, in the DNS server assignment section of your Wi-Fi or Ethernet connection.</p>
<h3>macOS</h3>
<p>Open System Settings, click Network, choose your connection, click Details and then DNS. Or from Terminal:</p>
<pre>networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
networksetup -setdnsservers Wi-Fi empty</pre>
<p>The second line undoes the change and returns to the router's servers.</p>
<h3>On the router</h3>
<p>Setting the DNS servers in the router's WAN or DHCP settings fixes every device on the network at once, including phones, TVs and consoles that have no easy DNS setting of their own.</p>
<p><strong>One caution for work laptops:</strong> company networks often resolve internal names (intranet sites, Active Directory, VPN-only hosts) only through the company's own DNS servers. Overriding them with a public resolver can break those names. On a managed device, report the problem to IT instead of changing DNS yourself.</p>

<h2>Step 6: When no DNS server answers at all</h2>
<p>If even 1.1.1.1 and 8.8.8.8 time out while <code>ping 1.1.1.1</code> works, DNS packets are being dropped on the way out. Check these in order:</p>
<ol>
<li><strong>VPN client.</strong> Many VPNs force their own resolver and can leave a dead DNS setting behind after a crash or an unclean disconnect. Disconnect, quit the client completely and test again.</li>
<li><strong>Security software.</strong> Antivirus suites with "web protection" or DNS filtering sometimes intercept lookups. Pause that feature briefly to test, then turn it back on.</li>
<li><strong>Captive portal.</strong> Hotel, airport and office guest Wi-Fi often blocks DNS until you accept the login page. Open any plain http address in a browser to trigger the sign-in screen.</li>
<li><strong>A broken IPv6 resolver.</strong> If the router advertises an IPv6 DNS server that does not work, some lookups stall. Check the IPv6 entries from Step 2; our <a href="/blog/ipv6-dns-configuration-guide">IPv6 DNS configuration guide</a> explains how they are assigned.</li>
<li><strong>Windows network stack.</strong> In an administrator Command Prompt run <code>ipconfig /release</code>, <code>ipconfig /renew</code>, then <code>netsh winsock reset</code> and <code>netsh int ip reset</code>, and restart the PC.</li>
</ol>
<p>The opposite pattern also exists: nslookup works but one browser fails. That usually means the browser's own secure DNS setting points at a provider your network blocks. Our <a href="/blog/dns-over-https-explained">DNS over HTTPS explainer</a> shows where that setting lives.</p>

<h2>If only your own domain fails</h2>
<p>If you run a website and visitors report DNS errors for your domain while every other site works for them, the issue is not their resolver. It is your domain's authoritative nameservers, and resolvers will usually return SERVFAIL rather than a timeout. Check which nameservers the domain is delegated to and whether each one answers:</p>
<pre>dig NS yourdomain.com +short
dig @ns1.yourdnshost.com yourdomain.com A +norecurse</pre>
<p>A nameserver that times out here, a delegation to servers that no longer host the zone, or an expired domain are the usual causes. You can run the same checks in the browser with our <a href="/nameserver-lookup">nameserver lookup</a> and <a href="/dns-lookup">DNS lookup</a> tools, and <a href="/blog/how-to-check-domain-nameservers">how to check what nameservers a domain is using</a> walks through reading the results.</p>

<h2>Quick checklist</h2>
<ol>
<li>Ping an IP and a name to confirm the fault is DNS.</li>
<li>Note which DNS server your device uses.</li>
<li>Run nslookup against your default resolver, 1.1.1.1 and 8.8.8.8.</li>
<li>Restart the router and flush the local DNS cache.</li>
<li>If the default resolver keeps failing, switch to two public resolvers from different providers.</li>
<li>If nothing answers, check the VPN, security software, captive portal, IPv6 DNS and the Windows network stack.</li>
</ol>

<h2>FAQ</h2>
<h3>Is it safe to use 1.1.1.1 or 8.8.8.8 instead of my ISP's DNS?</h3>
<p>For most home users, yes. Both are free, widely used resolvers with published privacy policies. The main exception is a work or school network that needs its own DNS servers for internal names.</p>
<h3>Why does only one device get the error?</h3>
<p>Because that device has its own DNS setting: a manual entry, a VPN, security software or a stale cache. Compare its Step 2 output with a device that works.</p>
<h3>Will flushing DNS fix "DNS server not responding"?</h3>
<p>Only if the resolver is already answering again and your device is holding on to an old failure. If the resolver itself is down, change the resolver instead.</p>

<h2>Sources</h2>
<ul>
<li><a href="https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig" rel="noopener" target="_blank">Microsoft Learn: ipconfig</a></li>
<li><a href="https://learn.microsoft.com/en-us/powershell/module/dnsclient/set-dnsclientserveraddress" rel="noopener" target="_blank">Microsoft Learn: Set-DnsClientServerAddress</a> and <a href="https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache" rel="noopener" target="_blank">Clear-DnsClientCache</a></li>
<li><a href="https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac" rel="noopener" target="_blank">Apple Support: Change DNS settings on Mac</a></li>
<li><a href="https://developers.cloudflare.com/1.1.1.1/setup/windows/" rel="noopener" target="_blank">Cloudflare: set up 1.1.1.1 on Windows</a></li>
<li><a href="https://developers.google.com/speed/public-dns/docs/using" rel="noopener" target="_blank">Google Public DNS: get started</a></li>
</ul>

DNS server not responding? Confirm it is DNS with two pings, test 1.1.1.1 and 8.8.8.8 with nslookup, then fix the resolver on Windows, macOS, Linux or your router.

DNS Server Not Responding: What It Means and How to Fix It

<p><strong>Short answer:</strong> ask a validating resolver and look at the flags. <code>dig +dnssec example.com A @1.1.1.1</code> prints a <code>flags:</code> line; if it contains <strong>ad</strong> (authenticated data), the answer passed DNSSEC validation all the way from the root. Then run <code>dig DS example.com @8.8.8.8</code>. A DS record in the parent zone is what turns a signed zone into a validating one. No DS means resolvers treat the domain as unsigned, however many signatures the zone itself publishes.</p>
<p>This guide walks through the four checks that tell you which of the three states a domain is in (secure, unsigned or broken), using real output from queries we ran on 23 October 2026. If you want the theory first, start with <a href="/blog/dns-security-dnssec-explained">DNSSEC explained</a> and come back for the commands.</p>

<h2>Signed is not the same as validating</h2>
<p>A domain owner can switch on DNSSEC at their DNS host and see signatures appear in the zone, yet nothing changes for visitors. Validation needs an unbroken chain: the root vouches for the TLD, the TLD vouches for your domain through a <strong>DS record</strong>, and the DS must match a key (DNSKEY) in your zone. The DS record is added at your registrar, not at your DNS host, and that hand-off is where most setups stall.</p>
<p>A recent example shows how common this is. Pakistan's <code>.pk</code> zone became DNSSEC-signed in early October 2026, and a scan of 158,561 <code>.pk</code> domains on 11 October found just one that validated end to end. Another 1,230 had signed their own zones but had no DS record in the parent, so validating resolvers treated them as unsigned (CircleID, 20 October 2026). We checked the TLD side ourselves: <code>dig DS pk @1.1.1.1</code> now returns key tag 34973 with the <code>ad</code> flag set.</p>

<h2>Check 1: ask a validating resolver for the ad flag</h2>
<p>Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9) all validate DNSSEC. Query one of them directly, so you are not relying on whatever resolver your router uses (our guide to <a href="/blog/nslookup-specific-dns-server">querying a specific DNS server</a> covers the syntax):</p>
<pre><code>dig +dnssec +multi cloudflare.com A @1.1.1.1</code></pre>
<p>Trimmed output from 23 October 2026:</p>
<pre><code>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 43914
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232

;; ANSWER SECTION:
cloudflare.com.  300 IN A 104.16.132.229
cloudflare.com.  300 IN A 104.16.133.229
cloudflare.com.  300 IN RRSIG A 13 2 300 (
                 20261024110238 20261022090238 34505 cloudflare.com.
                 D1e+XWcyXJxVe/OEi63SN47ac40/uoXre9t76UJMzGgO ... )</code></pre>
<p>Three things to read:</p>
<ul>
<li><strong>ad in the flags line:</strong> the resolver validated the answer. This is the single most useful signal.</li>
<li><strong>do in the EDNS line:</strong> the <code>+dnssec</code> option asked for DNSSEC records, so the RRSIG signature is included in the answer.</li>
<li><strong>The RRSIG line:</strong> algorithm 13 (ECDSA P-256 with SHA-256), then the expiry and inception timestamps (here 24 October 11:02 UTC and 22 October 09:02 UTC), then key tag 34505, the key that made the signature.</li>
</ul>
<p>Run the same query for <code>google.com</code> and the flags line reads <code>qr rd ra</code> with no <code>ad</code>. That is not an error. google.com simply does not use DNSSEC, and the answer resolves normally.</p>

<h2>Check 2: is there a DS record in the parent zone?</h2>
<pre><code>dig DS cloudflare.com @8.8.8.8 +noall +answer
cloudflare.com.  15878 IN DS 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9</code></pre>
<p>The four fields after <code>DS</code> are the key tag (2371), the algorithm (13), the digest type (2 = SHA-256) and the digest of the key. For an unsigned domain you get <code>status: NOERROR</code> with <code>ANSWER: 0</code> and only the TLD's SOA record in the authority section. That is what <code>dig DS google.com @8.8.8.8</code> returned for us.</p>
<p>The 15878 is the remaining cache time at Google's resolver. Ask the TLD server itself (<code>dig DS cloudflare.com @a.gtld-servers.net +norec</code>) and you see the full TTL, 86400 seconds, for a .com DS record. Remember that number: a wrong DS can stay in caches for a whole day.</p>

<h2>Check 3: does the zone's DNSKEY match the DS?</h2>
<pre><code>dig DNSKEY cloudflare.com @1.1.1.1 +noall +answer +multi
cloudflare.com. 644 IN DNSKEY 256 3 13 ( ... ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 34505
cloudflare.com. 644 IN DNSKEY 257 3 13 ( ... ) ; KSK; alg = ECDSAP256SHA256 ; key id = 2371</code></pre>
<p>Flag <strong>257</strong> marks the key-signing key (KSK) and <strong>256</strong> the zone-signing key (ZSK). The chain holds because the KSK's key id, 2371, equals the key tag in the DS record, and both use algorithm 13. The ZSK's id, 34505, matches the key tag in the RRSIG from check 1. If the DS key tag matches no DNSKEY in the zone, validating resolvers reject the domain.</p>

<h2>Check 4: ask the authoritative nameserver</h2>
<p>Find the nameservers (<a href="/blog/how-to-check-domain-nameservers">how to check a domain's nameservers</a>), then query one without recursion:</p>
<pre><code>dig cloudflare.com A @ns3.cloudflare.com +dnssec +norec
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1</code></pre>
<p>Here you want <strong>aa</strong> (authoritative answer) plus an RRSIG next to each record set. You will not see <code>ad</code>: authoritative servers serve signatures but do not validate them. If the RRSIG is missing here, the zone is not being signed. If it is present but the expiry timestamp is in the past, the signer has stopped refreshing it, and validating resolvers will start failing the domain.</p>


<h2>What the results mean</h2>
<table>
<thead><tr><th>What you see</th><th>State</th><th>Effect on visitors</th></tr></thead>
<tbody>
<tr><td>ad flag; DS key tag matches the KSK</td><td>Secure</td><td>Resolves; protected against spoofed answers</td></tr>
<tr><td>No DS, no DNSKEY</td><td>Unsigned (insecure)</td><td>Resolves normally, without DNSSEC protection</td></tr>
<tr><td>DNSKEY and RRSIG in the zone, no DS in the parent</td><td>Signed but not validating</td><td>Resolves normally, but validators treat it as unsigned</td></tr>
<tr><td>DS present, but no matching key or expired signatures</td><td>Bogus</td><td>SERVFAIL on every validating resolver</td></tr>
</tbody>
</table>
<p>The third row is the half-finished setup from the <code>.pk</code> scan: the fix is to add the DS record at the registrar. The fourth row is the dangerous one, because the domain goes dark for every user whose resolver validates.</p>

<h2>Is DNSSEC behind a SERVFAIL? Use +cd</h2>
<p><code>dnssec-failed.org</code> is a test domain that is broken on purpose. Here is what a validating resolver says about it:</p>
<pre><code>dig dnssec-failed.org A @1.1.1.1
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: SERVFAIL, id: 59644
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; OPT=15: 00 09 ... ("..no SEP matching the DS found for dnssec-failed.org.")</code></pre>
<p>Now add <code>+cd</code> (checking disabled), which tells the resolver to skip validation:</p>
<pre><code>dig +cd dnssec-failed.org A @1.1.1.1
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 6398
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
dnssec-failed.org.  300  IN  A  96.99.227.255</code></pre>
<p>SERVFAIL normally, an answer with <code>+cd</code>: that combination means DNSSEC validation is the cause, not a dead nameserver. The <code>OPT=15</code> line is an Extended DNS Error (RFC 8914). The first bytes, <code>00 09</code>, are info-code 9, "DNSKEY Missing", and the text explains it: no key in the zone matches the DS. The older dig bundled with macOS prints the raw bytes, while newer BIND releases decode the code for you. Other DNSSEC codes you may meet are 6 (DNSSEC Bogus), 7 (Signature Expired) and 10 (RRSIGs Missing). For SERVFAILs that are not DNSSEC-related, see <a href="/blog/common-dns-errors-and-fixes">common DNS errors and fixes</a>.</p>
<p>The same test works the other way round. If <code>dnssec-failed.org</code> resolves through your normal resolver, that resolver is not validating DNSSEC at all.</p>

<h2>Windows, delv and browser tools</h2>
<ul>
<li><strong>Windows PowerShell:</strong> <code>Resolve-DnsName cloudflare.com -Type A -Server 1.1.1.1 -DnssecOk</code> sets the DNSSEC OK bit, so RRSIG records are listed with the answer. <code>-DnssecCd</code> sets checking-disabled, the same test as <code>dig +cd</code>.</li>
<li><strong>delv:</strong> on Linux systems with a current BIND 9 package, <code>delv @1.1.1.1 example.com A</code> validates the chain itself and prints <code>; fully validated</code> or <code>; unsigned answer</code>. The old copy bundled with macOS stopped with "no crypto support" when we tried it, so stick with dig there.</li>
<li><strong>Online:</strong> DNSViz (dnsviz.net) draws the whole chain from the root and marks the broken link. Verisign Labs' DNSSEC Debugger gives a plain pass/fail list. Our <a href="/dns-lookup">DNS lookup tool</a> is handy for quick record checks next to them.</li>
</ul>

<h2>Before you change DNS provider or registrar</h2>
<p>Most bogus domains are self-inflicted during a move. If you change the domain's nameservers to a new DNS host while the old DS record stays at the registrar, validating resolvers look for a key the new host does not have. Either remove the DS at the registrar first and wait out its TTL (a day for .com) before switching, or turn on DNSSEC at the new host and publish its DS in the same change. Our <a href="/blog/how-to-change-nameservers-step-by-step">nameserver change guide</a> and <a href="/blog/domain-transfer-checklist">domain transfer checklist</a> show where this fits in the order of steps. Once the change is made, cached DS records explain why some networks fail before others, the same timing covered in <a href="/blog/dns-propagation-explained">DNS propagation explained</a>.</p>

<h2>FAQ</h2>
<h3>Does nslookup show whether DNSSEC is working?</h3>
<p>No. nslookup does not display the DNS header flags, so you cannot see <code>ad</code>. Use dig, delv or Resolve-DnsName instead.</p>
<h3>Is an unsigned domain a problem?</h3>
<p>It still works everywhere. It just lacks protection against forged answers. A broken setup is worse than no DNSSEC, so finish the DS step properly or leave DNSSEC off.</p>
<h3>Why does the ad flag disappear when I query my router?</h3>
<p>Many home routers and some ISP resolvers forward queries without validating, or strip the flag. Test against 1.1.1.1, 8.8.8.8 or 9.9.9.9 to see the real state of the domain.</p>

<p><em>Sources: RFC 4033–4035 (DNSSEC records and validation); RFC 8914 (Extended DNS Errors); Microsoft Learn, "Resolve-DnsName" (DnssecOk and DnssecCd parameters); BIND 9 documentation for dig and delv; CircleID, "Pakistan's .PK Is Now DNSSEC-Signed, but Only One Domain Validates" (20 October 2026). Example output from live queries run 23 October 2026 on macOS with DiG 9.10.6. Keys, signatures and TTLs change over time, so your output will differ.</em></p>

Check DNSSEC with dig: look for the ad flag, find the DS record, match it to the DNSKEY, and use dig +cd to prove whether DNSSEC is behind a SERVFAIL.

How to Check if a Domain Is DNSSEC-Signed (and Actually Validating)

<p><strong>Short answer:</strong> put the server after the name. <code>nslookup example.com 8.8.8.8</code> asks Google Public DNS instead of the resolver your computer normally uses, and <code>nslookup -type=mx example.com 1.1.1.1</code> does the same for a specific record type. With dig the server comes first, after an @ sign: <code>dig @1.1.1.1 example.com MX</code>. In Windows PowerShell the equivalent is <code>Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1</code>. The rest of this guide covers which server to ask for which question, how to query a domain's own authoritative nameserver, and how to read what comes back.</p>

<h2>Why query a specific DNS server at all?</h2>
<p>By default nslookup and dig ask whatever resolver your operating system is configured with: usually your router, your ISP, a company DNS server or a VPN's resolver. That resolver caches each answer for as long as the record's TTL allows. So right after you change a record, your default resolver may still hand out the old value, and a plain lookup tells you about that cache rather than about your DNS zone.</p>
<p>Sending the query to a server you choose answers three different questions:</p>
<ul>
<li><strong>Is my local resolver the problem?</strong> Compare your default resolver with a public one. If 8.8.8.8 returns the new value and your router does not, the change is live and you are looking at a stale cache.</li>
<li><strong>What does the source of truth say?</strong> Ask the domain's authoritative nameserver. Its answer is what every resolver will see once the old cached copies expire.</li>
<li><strong>What do people on other networks see?</strong> Public resolvers fill their caches at different moments, which is most of what people mean by <a href="/blog/dns-propagation-explained">DNS propagation</a>.</li>
</ul>

<h2>nslookup: the server goes last</h2>
<p>nslookup ships with Windows, macOS and most Linux distributions. In one-line (non-interactive) mode the pattern is <code>nslookup [options] name [server]</code>:</p>
<pre><code>nslookup example.com 8.8.8.8
nslookup -type=mx example.com 1.1.1.1
nslookup -type=ns example.com 9.9.9.9
nslookup -type=txt example.com 8.8.4.4</code></pre>
<p>This is the first command as we ran it on 22 October 2026:</p>
<pre><code>Server:    8.8.8.8
Address:   8.8.8.8#53

Non-authoritative answer:
Name:      example.com
Address:   172.66.147.243
Name:      example.com
Address:   104.20.23.154</code></pre>
<p>The <strong>Server</strong> line confirms who answered. If it shows your router's address instead of the one you typed, the server argument was not picked up, and the usual cause is putting the server before the name. Windows prints the resolver's hostname above its address and shows <em>UnKnown</em> when that resolver has no <a href="/blog/reverse-dns-lookup-uses">reverse DNS</a> name. That is cosmetic; the lookup still worked.</p>
<p><strong>Non-authoritative answer</strong> means the reply came from a recursive resolver (from its cache or from a lookup it made on your behalf), not from a nameserver that hosts the zone. For public resolvers that is normal, not an error.</p>

<h3>Interactive mode: switch servers mid-session</h3>
<p>Run <code>nslookup</code> on its own to get a <code>&gt;</code> prompt. <code>server 1.1.1.1</code> changes the server for every query that follows, and <code>set type=</code> changes the record type:</p>
<pre><code>nslookup
&gt; server 1.1.1.1
&gt; set type=ns
&gt; example.com
&gt; set type=a
&gt; www.example.com
&gt; exit</code></pre>
<p>Microsoft's reference also lists <code>lserver</code>. It makes the same switch but looks up the new server's name using your original default server, which helps when the server you switch to cannot resolve names for you, such as an authoritative-only nameserver.</p>

<h3>nslookup options worth knowing</h3>
<table>
<thead><tr><th>Option</th><th>What it does</th></tr></thead>
<tbody>
<tr><td><code>-type=mx</code> (or <code>-query=mx</code>)</td><td>Record type to ask for: a, aaaa, mx, ns, txt, cname, soa, ptr</td></tr>
<tr><td><code>-port=5353</code></td><td>Query a server listening on a non-standard port</td></tr>
<tr><td><code>-timeout=10</code></td><td>Seconds to wait for a reply before retrying</td></tr>
<tr><td><code>-vc</code></td><td>Use TCP instead of UDP, useful when a firewall drops large UDP replies</td></tr>
<tr><td><code>-debug</code></td><td>Print the full response, including each record's TTL</td></tr>
</tbody>
</table>

<h2>dig: the server goes first, after @</h2>
<p>dig is the tool most DNS engineers reach for, because it prints the whole DNS response, flags and TTLs included. It is preinstalled on macOS. On Debian and Ubuntu it comes in the <code>dnsutils</code> package (<code>bind9-dnsutils</code> on newer releases), and on Fedora and RHEL in <code>bind-utils</code>. The pattern is <code>dig @server name type</code>:</p>
<pre><code>dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com MX +short
dig @9.9.9.9 example.com TXT
dig @2606:4700:4700::1111 example.com AAAA</code></pre>
<p><code>+short</code> prints only the values. Leave it off when you need the detail. The header shows the status (NOERROR, NXDOMAIN, SERVFAIL) and the footer names the server that replied and how long it took:</p>
<pre><code>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; Query time: 17 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)</code></pre>
<p>The flags tell you what kind of server answered. <code>ra</code> (recursion available) marks a resolver, <code>aa</code> (authoritative answer) marks a server that hosts the zone, and <code>ad</code> means the resolver validated the answer with <a href="/blog/dns-security-dnssec-explained">DNSSEC</a>.</p>

<h2>Ask the authoritative nameserver directly</h2>
<p>This check settles most "did my change work?" questions, because it skips every cache. It takes two steps: find the domain's nameservers, then query one of them.</p>
<pre><code>dig example.com NS +short
elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.

dig @elliott.ns.cloudflare.com example.com A +norecurse</code></pre>
<p>In our test the reply carried the <code>aa</code> flag and a TTL of 300 seconds on each A record. That TTL is the longest a resolver should keep serving the old value after a change. The nslookup version is <code>nslookup -type=ns example.com</code> followed by <code>nslookup example.com elliott.ns.cloudflare.com</code>, and the answer is no longer labelled non-authoritative.</p>
<p>If the nameserver replies <strong>REFUSED</strong> or hands you a referral instead of an answer, you asked a server that does not host that zone, so re-check the NS list. When you are moving to a new DNS host, query the new provider's nameservers directly <em>before</em> you switch, so you know the zone is complete. Our <a href="/nameserver-lookup">nameserver lookup</a> shows which nameservers a domain delegates to right now, and <a href="/blog/how-to-check-domain-nameservers">this guide</a> explains the registry side of that check.</p>

<h2>Which server to pick</h2>
<table>
<thead><tr><th>Server</th><th>Address</th><th>Use it to</th></tr></thead>
<tbody>
<tr><td>Google Public DNS</td><td>8.8.8.8, 8.8.4.4</td><td>Compare with a large public cache</td></tr>
<tr><td>Cloudflare</td><td>1.1.1.1, 1.0.0.1</td><td>Get a second, independent cache</td></tr>
<tr><td>Quad9</td><td>9.9.9.9</td><td>Get a third opinion; it also blocks known malicious domains, so a block there is not proof of a DNS fault</td></tr>
<tr><td>The domain's own nameserver</td><td>From the NS lookup</td><td>See the current value with no cache involved</td></tr>
<tr><td>Your router or company DNS</td><td>Shown by a plain <code>nslookup</code></td><td>See exactly what your own devices receive</td></tr>
</tbody>
</table>

<h2>Windows PowerShell: Resolve-DnsName</h2>
<p>On Windows, Resolve-DnsName returns objects you can filter and pipe, which suits scripts and repeated checks:</p>
<pre><code>Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1
Resolve-DnsName -Name example.com -Type A -Server elliott.ns.cloudflare.com -DnsOnly</code></pre>
<p><code>-Server</code> takes one or more DNS servers. <code>-DnsOnly</code> stops Windows from also trying LLMNR or NetBIOS, <code>-NoHostsFile</code> ignores the local hosts file, and <code>-CacheOnly</code> shows only what the Windows DNS client cache already holds, a quick way to see whether your PC is still keeping an old answer.</p>

<h2>When the query fails</h2>
<ul>
<li><strong>Timed out, or "no servers could be reached":</strong> many office, hotel and some mobile networks block outbound DNS on port 53 to anything except their own resolver. Try another network, or use our <a href="/dns-lookup">online DNS lookup</a>, which queries from outside your network.</li>
<li><strong>REFUSED:</strong> the server will not answer recursive questions from you, or it is an authoritative server that does not host that zone.</li>
<li><strong>NXDOMAIN:</strong> that server says the name does not exist. If only one resolver says so, it may be holding a cached negative answer, which lasts as long as the zone's SOA negative-caching TTL (RFC 2308). Browser errors caused by this are covered in <a href="/blog/how-to-fix-dns-probe-finished-nxdomain">our NXDOMAIN fix guide</a>.</li>
<li><strong>SERVFAIL:</strong> the resolver could not get a usable answer, often because of a DNSSEC validation failure or unreachable nameservers. Run the query again with <code>dig +cd</code> (checking disabled); if an answer appears, DNSSEC is the likely cause. More fixes are in <a href="/blog/common-dns-errors-and-fixes">common DNS errors</a>.</li>
<li><strong>Different answers from different public resolvers:</strong> usually caching after a recent change, so wait for the old TTL to run out. Some domains also answer differently by location on purpose, which is how <a href="/blog/how-cdn-and-dns-work-together">CDNs use DNS</a>.</li>
</ul>

<h2>FAQ</h2>
<h3>Does the order of arguments matter in nslookup?</h3>
<p>Yes. Options come first, then the name, then the server: <code>nslookup -type=txt example.com 8.8.8.8</code>. Swap them and nslookup does a reverse lookup of the IP address while trying to use the domain name as the DNS server, which usually ends in a timeout.</p>
<h3>Can I give a server name instead of an IP address?</h3>
<p>Yes. <code>nslookup example.com dns.google</code> and <code>dig @one.one.one.one example.com</code> both work. The tool first resolves the server's name through your default resolver, so an IP address is more reliable when your default resolver is the thing you suspect.</p>
<h3>dig shows the new IP, so why does my browser still load the old site?</h3>
<p>Your operating system and browser keep their own short caches. Flush the OS cache with <code>ipconfig /flushdns</code> on Windows or <code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder</code> on macOS, then restart the browser.</p>

<p><em>Sources: Microsoft Learn, "nslookup" command reference and its server and lserver subcommands; Microsoft Learn, "Resolve-DnsName" (DnsClient module); BIND 9 manual pages (dig); RFC 1034 and RFC 1035 (DNS concepts and message format); RFC 2308 (negative caching). Example output from live queries run 22 October 2026 on macOS with DiG 9.10.6 and the system nslookup. Results for example.com, the domain reserved for documentation, will change over time.</em></p>

Use nslookup example.com 8.8.8.8 or dig @1.1.1.1 to query a specific DNS server, ask the authoritative nameserver, and read REFUSED, NXDOMAIN and SERVFAIL.

Free DNS & Network Tools

All Tools

Nameserver Lookup

DNS Lookup

WHOIS Lookup

IP Lookup

SSL Checker

HTTP Headers

Speed Test

Domain Availability

Blacklist Checker

Email Validator

Latest Posts

DNS Server Not Responding: What It Means and How to Fix It

How to Check if a Domain Is DNSSEC-Signed (and Actually Validating)

How to Query a Specific DNS Server With nslookup (and dig)