0

My objective is to check that all my domain's name servers are working with the following sequence of commands within nslookup (responses omitted here):

set type=soa
example.com
set type=a+aaaa
example.com ns1.name_server.com
example.com ns2.name_server.com
example.com ns3.name_server.com
example.com ns4.name_server.com

Where the name servers ns1, ns2, ns3 and ns4 are all taken from the list provided in the SOA.

The problem is that in Windows only, some but not all of the name server-specific commands consistently return ** ns2.name_server.com can't find example.com: No response from server in the case of a Windows 10 Pro machine, and for Server 2008R2 it gives this:

DNS request timed out.
    timeout was 2 seconds.  [it times out 4 times like this]
** Request to ns2.name_server.com timed-out

When tested with online tools, a Mac, and a Linux VM (with host command) all name servers (ns1, ns2, ns3, ns4) instantly provide the correct A record. Therefore I believe all the DNS entries are correct and it is a Windows nslookup problem.

The workaround that I have found is to issue all the nslookup commands directly from the command prompt - not within nslookup's prompt. All these give the correct response:

c:>nslookup example.com ns1.name_server.com
c:>nslookup example.com ns2.name_server.com
c:>nslookup example.com ns3.name_server.com
c:>nslookup example.com ns4.name_server.com

The very weird thing is that the name servers that fail (within nslookup's prompt) are specific and repeatable per machine machine, so for example my Win10 succeeds for ns1, but fails for ns2, ns3, and ns4. Over on the 2008R2 machine only ns2 fails and ns1, ns3 and ns4 work.

The problem still happens within the prompt even without doing the initial switch to the SOA type and back, i.e. issuing the example.com ns1.name_server.com as the first command.

I suspected that the initial default server might be the problem, because nslookup hits it as you go into its command prompt. But I see the same behavior with the default of 8.8.8.8 or a low-end home router.

The only other clue I see is some inconsistency in how the specified name server is reported in terms of its IPv4 address and IPv6 address. Sometimes it is v4, sometimes both. But I have not been able to discern a consistent pattern.

Question: Am I using nslookup correctly? Is this a bug? Is there a IPv6 issue lurking here?

Example to try: Type these commands into an nslookup prompt on your Windows machine:

set type=soa
superuser.com   [check the current name servers and revise below accordingly if needed] 
set type=a+aaaa
superuser.com ns-1699.awsdns-20.co.uk
superuser.com ns-245.awsdns-30.com
superuser.com ns-cloud-d1.googledomains.com
superuser.com ns-cloud-d2.googledomains.com
2

I found the answer here from almost 3 years ago which states in part:

... nslookup is broken on Windows..

...The DNS server is dual stacked, meaning that it has both IPv4 and IPv6 addresses. When performing the lookup by specifying the default DNS server as a command line option, nslookup properly loops through the IP addresses starting with IPv6 and ending on IPv4. However when using nslookup interactively, nslookup only tries the first address which is returned by the resolver, which will always be the IPv6 address.

The fix for this is to specify the DNS servers by IP address when using nslookup interactively or use nslookup non-interactively by specifying the default DNS server on the command line.

Note this only affects nslookup on Windows, modern versions of Linux and OS X use a fixed version of nslookup.

So nslookup is broken, and it is an IPv6 issue.

|improve this answer|||||
  • Are you sure this is correct? The highest voted answer on the question you linked says the reason for this behavior is because a IPv6 transition technology fools NSLOOKUP into thinking it has IPv6 connectivity. – I say Reinstate Monica Jul 23 '18 at 2:33
  • I may be in over my head here, but Linux and OS X's host command work fine behind the same IPv4 NAT. So either nslookup is broken or Windows IPv6 transition is faulty in a way that nslookup does not handle. But in any case, the difference between single command results (i.e. the "workaround" in the OP) and interactive prompt results (i.e. timeout / no response) has to be categorized as a bug in nslookup. – Ian W Jul 24 '18 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.