Unexpected exception returned from cmdlet Resolve-DNSName

Question

When querying a root name server directly, in some instances, the Resolve-DNS cmdlet does not return to the console the responses it received, and instead returns an exception. A reproducible example is as follows:

Root name server used in this example: e.root-servers.net 192.203.230.10

Example query to ask for name servers which are authoritative for the root zone. This returns NS (and A) results as expected:

$ Resolve-DnsName -Server 192.203.230.10 -Type NS -NoRecursion -Name .

Name Type TTL Section NameHost

---

. NS 518400 Answer m.root-servers.net
. NS 518400 Answer b.root-servers.net
. NS 518400 Answer c.root-servers.net
. NS 518400 Answer d.root-servers.net
. NS 518400 Answer e.root-servers.net
. NS 518400 Answer f.root-servers.net
. NS 518400 Answer g.root-servers.net
. NS 518400 Answer h.root-servers.net
. NS 518400 Answer i.root-servers.net
. NS 518400 Answer a.root-servers.net
. NS 518400 Answer j.root-servers.net
. NS 518400 Answer k.root-servers.net
. NS 518400 Answer l.root-servers.net
etc...

Example query to ask for name servers which are authoritative for the top level 'com' zone. This returns an exception:

$ Resolve-DnsName -Server 192.203.230.10 -Type NS -NoRecursion -Name com.

Resolve-DnsName : com. : DNS query request is pending
-or-
Resolve-DnsName : com. : DNS server failure

There are two reasons why the exceptions above do not seem logical:

1. A packet trace of the query reveals that the root name server DOES respond with a list of auth name servers and glue records for the 'com' zone. These should be returned to the console application.
2. An identical query, when issued via NSLOOKUP returns the results as expected, as shown (truncated) here:

nslookup -norecurse -type=NS com. 192.203.230.10

Server: UnKnown
Address: 192.203.230.10

com nameserver = l.gtld-servers.net
com nameserver = b.gtld-servers.net
com nameserver = c.gtld-servers.net
com nameserver = d.gtld-servers.net
com nameserver = e.gtld-servers.net
com nameserver = f.gtld-servers.net
com nameserver = g.gtld-servers.net
com nameserver = a.gtld-servers.net
com nameserver = h.gtld-servers.net
com nameserver = i.gtld-servers.net
com nameserver = j.gtld-servers.net
com nameserver = k.gtld-servers.net
com nameserver = m.gtld-servers.net
etc...

There is no observable difference if the '-NoRecursion' parameter is included or not.

Can anyone explain this odd behaviour?

Thanks,
DaveC

Answer 1

Hello @DaveC

I will recommend to ensure that the DNS target IP is the correct one.

Try first > Resolve-DnsName -Type NS -NoRecursion -Name com.

This should return the next at the output:
Name : e gtld-servers net
QueryType : A
TTL : 613
Section : Additional
IP4Address : xxx xxx xxx xxx <---- we will use this IP for the command as:

Resolve-DnsName -Server xxx xxx xxx xxx -Type NS -NoRecursion -Name com.

This should reply the correct responders.

Hope this helps with your query,

------------

--If the reply is helpful, please Upvote and Accept as answer--

Answer 2

Hi @Limitless Technology

Thank you for your reply and suggestion. Yes I can confirm the cmdlet will return the auth servers for 'com' zone if the target of the query is one of the 'com' name servers.

However, in this case I'm trying to prove that the client device is able to target a ROOT name server and get a response to a query for the 'com' (or any top level domain) which contains a list of auth name servers for that top level zone. NSLOOKUP returns the data which arrives in the response packet. Resolve-DNSName returns an exception instead (response packet looks the same in both instances).

If I'm being honest, we are ultimately attempting to (as close as possible) mimic the behavior of a Microsoft DNS server which is running on the same device as the client utility. When the name server starts up and begins to build its cache, it must need to reach the root name servers (in the absence of any forwarding configured). I'm fairly certain that one (or both) of these client utilities (nslookup/resolve-dnsname) are limited in their ability to act as iterative resolvers, but also trying to understand the difference between them which could be causing this behavior.

Thanks,
DaveC

Answer 3

After a bit more testing, I think I can better summarize this issue as follows:

If Resolve-DNSName directly targets a name server which meets both of these conditions:

1. Does not offer recursion
2. Is not authoritative for the zone in the query

...then it will return an exception to the console, whereas NSLOOKUP will return the query response it receives (list of auth name servers).

Thanks,
DaveC

Answer 4

I have confirmed this behavior as well.
Packet traces show no difference in the query response between NSLookup and Resolve-DNSName. Not sure why the Resolve-DNSName cmdlet would display an error for non-authorative answers.

Answer 5

I can also confirm this behaviour, in both PowerShell Core and Windows PowerShell. Wireshark shows a correct response but its not displayed.

Looks like a bug in the cmdlet or underlying library.