0

There are various references (such as DNS can't resolve hostname; nslookup can or https://web.archive.org/web/20160525082756/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html or https://web.archive.org/web/20121113214415/http://cbfive.com/blog/post/PING-vs-NSLookup.aspx) that state the following or something similar, but don't give suggestions for alternatives to use:

The reason ping can't resolve the hostname but nslookup can is because nslookup a low-level tool that bypasses the Windows DNS client. It uses whatever DNS server you tell it to (the first one by default), and does the query on the fly.

My question is, how can I manually test the DNS Client to check an SRV record? Is there a way to see the DNS information it tries to use? I can't put Wireshark on every servers in every environment, so I am looking for another way to troubleshoot. I presume the answer is "no", otherwise why would we use nslookup (flawed as it is). Obviously I can't use ping for an SRV record.

Edited with updated findings: The UDP queries are too long, so DNS response with the truncate flag gets sent to the client, so a TCP query needs to be made. The next packet after the TCP DNS query is (from TargetDNS to client): "TCP segment of a reassembled PDU" (which looks like it contains response info), and then is different depending on the scenario:

  • Nslookup query - with the nslookup query there is actually a DNS response packet with the information
  • ApplicationX (which I believe uses Windows DNS Client) - Windows DNS client query, there is no DNS response packet (i.e. like the other TCP packet has been lost)
    • There is nothing in the DNS cache (ipconfig /displaydns) or on the Client DNS server cache for the SRV record (not even a negative).

It proves, unsurprisingly, the DNS client and nslookup get different results but exactly what are they doing differently (discounting hosts, lmhosts, appending DNS search suffixes, etc)? They are using the same DNS servers (as evidenced by Wireshark). How can I narrow down where the fault lies?

Improve this question
1
  • At some point someone should ask if only one application exhibits this behavior, it may be the application.
    – Greg Askew
    May 20, 2022 at 12:54

1 Answer 1

Reset to default
2

Your understanding is correct that nslookup acts as a DNS client in itself, separately from whatever the OS does on behalf of typical applications.

The Powershell cmdlet Resolve-DnsName, on the other hand, uses the underlying Windows DNS client. Thereby this is a tool that can be used to trigger the normal OS behavior for DNS lookups (or other sources, despite the name!), separately from your application.

Eg something like that as an example of a SRV lookup:

Resolve-DnsName -Type SRV _sip._tcp.example.com

Sidenote:
The behavior of nslookup and the like (generally dig is the tool of choice in this category) useful for investigating DNS behavior, specifically because the local environment does not affect the results, but at the same time it makes these tools unsuitable for investigating the behavior of the local OS environment.

Improve this answer
1
  • First of all, apologies for the lateness in response, and thanks for that. I don't have access to resolve-dnsname in this case unfortunately. Can you suggest something else? I suppose the whole question may need re-framing, I would like to know a practical way to test DNS client, but also, what are the differences between nslookup and what the DNS client does. I get that there will be difference in appending DNS search suffixes, and DNS client could use hosts and lmhosts or they could be looking at different servers, but what else could explain why nslookup works, but DNS client doesn't
    – Badger
    May 20, 2022 at 10:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .