Join Log in
Score:0
Badger avatar Server

DNS client vs Nslookup - doing a manual test of the DNS client for SRV records

ru flag
Badger

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?

56
0 + 0
cn flag
Greg Askew
At some point someone should ask if only one application exhibits this behavior, it may be the application.
0
Reply
Score:2
avatar Server
cn flag
Håkan Lindqvist

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.

0 + 0
Badger avatar
ru flag
Badger
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
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.