OK, this is a weird one. Windows still relies on nslookup.exe to query name servers on the command line, although we all know that the command is depreciated and one should use host or dig. Nevertheless, on a default Windows installation one has to rely on the tools at hand.
The company Windows laptop I sometimes use is a Windows 7 64-bit machine and even though I mostly use a Mac, it is really nice.
Occassionally, I take the laptop home where it gets on my IPv6 network. As expected of a modern system it discovers the router and accepts the router advertisements to comply to IPv6 automagical configuration. It even follows RFC6106 for DNS configuration. So far so good...
Oddly enough when I return at work with no IPv6 on the LAN, something weird happens:
nslookup.exe still believes the IPv6 name server is there even though the machine was rebooted several times in the mean time. And as a net result nslookup.exe no longer works, yet name resolution still works.
As shown in the screenshots, both IPv4 and IPv6 are set for automagical configuration.
Google doesn't really help me on this one and what baffles me the most is that nslookup.exe obviously uses different criteria for its name server than the Operating System itself.
I thought that maybe the Teredo tunneling feature, which is switched on by default, could have been the cause. It has been disabled for practical testing purposes and as the screenshot below shows, once on the LAN there is no reason why the machine would configure the wrong DNS server for nslookup.exe.
I'd be interested if someone has ever experienced this behavior and knows a fix for it as it is obviously a bug.
By the way, it is advisable to switch off Teredo tunneling when you fiddle around with IPv6. You disable it through an elevated command prompt and type the following commands:
About this Blog
IT Technology, networking, Apple, iDevices, Android, IPv6, DNS.