I'm trying to debug a problem in which my Windows host resolver will not
resolve a particular DNS name (FQDN).
I notice that if I call the Windows nslookup command as follows,
nslookup x.y.z.cloud
(x.y.z.cloud is a stand-in for the actual name), the request times out twice with no reported results.
However, if I call
nslookup -v x.y.z.cloud
or
nslookup -v -debug x.y.z.cloud
it does not report failure, but instead returns the correct non-authoritative
result for x.y.z.cloud from the local DNS server (& much additional information in the -debug case).
However, ping, or browsers, or (as far as I can tell), anything using the normal Windows resolver does not see the result for x.y.z.cloud. ('ipconfig /flushdns' does not help.)
There's nothing in c:\Windows\System32\drivers\etc\hosts about x.y.z.cloud either.
So, clutching at straws, what is the effect of the '-v' flag to nslookup
which makes it (apparently) more successful at retrieving the response? I tried
it originally thinking it might be 'verbose', but the output is not really verbose without -debug also, and it appears to have other effects.
BTW, Is there documentation anywhere for all the flags of 'nslookup' including '-v', '-debug', etc.?
Any ideas on what might be going wrong with the normal name resolution are also welcome ;^)
NOTES: I've found out some more. It looks like zscaler is running on the Windows host and may well be interfering with the DNS requests. I mentioned in a comment that 'x.y.z.cloud' is not a name in our company's domain. However, it resolves (according to our local DNS server) to an IP address within the company network. From logs, zscalar appears to be classifying 'x.y.z.cloud' as an external 'isTunnel2Domain' and may be tunnelling the request somewhere un-useful. When 'nslookup -v x.y.z.cloud.' is used, it runs over TCP (thanks Dave!) and zscalar may not intercept it the same way.