Score:-1

Resolve-DnsName resolves hostname of IP, but nslookup fails

nl flag

There are some IP address that nslookup can't resolve (both on Windows and Linux).

Problem:

I can find the IP of the hostname, but reverse lookup fails.

PS C:\> nslookup.exe somehost2
Server:  corpdns.mydomain.com
Address:  10.248.2.1

Name:    somehost2.corp.mydomain.com
Address:  10.185.140.22

# Reverse lookup of the same IP fails:

PS C:\> nslookup.exe 10.185.140.22
Server:  corpdns.mydomain.com
Address:  10.248.2.1

*** corpdns.mydomain.com can't find 10.185.140.22: Non-existent domain

However,Resolve-DnsName PowerShell command return the hostname for the reverse lookup.

PS C:\> Resolve-DnsName 10.185.140.22

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
22.140.185.10.in-addr.arpa.    PTR    1200  Question   somehost2

There are two unusual things I observe here:

  1. It comes from the Question section
  2. It returns the hostname without the DNS domain.

With other IP addresses (that nslookup can resolve), we see it comes from the Answer section and with a DNS domain.

PS C:\> Resolve-DnsName 10.210.0.127

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
127.0.210.10.in-addr.arpa      PTR    1200  Answer     somehost1.corp.mydomain.com

By the way, ping with the /a flag also succeeds resolving the name on Windows:

PS C:\> ping /a 10.185.140.22

Pinging somehost2 [10.185.140.22] with 32 bytes of data:
Reply from 10.185.140.22: bytes=32 time=6ms TTL=127
Reply from 10.185.140.22: bytes=32 time=12ms TTL=127

But I cannot find an equivalent flag for ping in Linux.

My question:

What are Resolve-DnsName and ping doing differently than nslookup?

My main problem is when I try to resolve the IP in Linux. I've tried several nslookup and dig command to no avail. Is there an equivalent to Resolve-DnsName in Linux?

Clarification:

Most of the IP addresses can be resolved by nslookup as well, the problem is only with a specific subset of hosts in our environment.

Update: nslookup in debug mode

PS C:\> nslookup.exe -d 10.185.140.22
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        1.2.248.10.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  1.2.248.10.in-addr.arpa
        name = corpdns.mydomain.com
        ttl = 1200 (20 mins)

------------
Server:  corpdns.mydomain.com
Address:  10.248.2.1

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        22.140.185.10.in-addr.arpa, type = PTR, class = IN
    AUTHORITY RECORDS:
    ->  185.10.in-addr.arpa
        ttl = 900 (15 mins)
        primary name server = gdns602.corp.mydomain.com
        responsible mail addr = hostmaster.mydomain.com
        serial  = 35869652
        refresh = 300 (5 mins)
        retry   = 900 (15 mins)
        expire  = 604800 (7 days)
        default TTL = 900 (15 mins)

------------
*** corpdns.mydomain.com can't find 10.185.140.22: Non-existent domain

Update #2

Resolve-DnsName fails for those systems when using different flags such as: -DnsOnly, -NoHostsFile, -LlmnrNetbiosOnly (but does work for the other IP address that nslookup can resolve).

PS C:\> Resolve-DnsName 10.185.140.22 -DnsOnly
Resolve-DnsName : 22.140.185.10.in-addr.arpa : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName 10.185.140.22 -DnsOnly
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (22.140.185.10.in-addr.arpa:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName



PS C:\> Resolve-DnsName 10.185.140.22 -NoHostsFile
Resolve-DnsName : 22.140.185.10.in-addr.arpa : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName 10.185.140.22 -NoHostsFile
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (22.140.185.10.in-addr.arpa:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName



PS C:\> Resolve-DnsName 10.185.140.22 -LlmnrNetbiosOnly
Resolve-DnsName : 22.140.185.10.in-addr.arpa : DNS record does not exist
At line:1 char:1
+ Resolve-DnsName 10.185.140.22 -LlmnrNetbiosOnly
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (22.140.185.10.in-addr.arpa:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : RECORD_DOES_NOT_EXIST,Microsoft.DnsClient.Commands.ResolveDnsName
user1686 avatar
fr flag
Can you show the results of `nslookup -d 10.185.140.22` on Windows, or the `dig` output, or a packet capture of the received DNS response?
aviro avatar
nl flag
@user1686 I've updated my question with the debug information as requested, thanks.
user1686 avatar
fr flag
Do you get any different results from `Resolve-DnsName -DnsOnly -NoHosts` (and from `-LlmnrNetbiosOnly`, etc)?
aviro avatar
nl flag
@user1686 updated my question again.
Score:0
nl flag

After examining wireshark, I saw that indeed those IPs weren't available in DNS:

Standard query response 0xb20a No such name PTR 22.140.185.10.in-addr.arpa

But the answer came from NBSTAT query in NBNS (NetBIOS Name Service) protocol.

The reason is that those hosts don't have static IP - they get their dynamic IP through DHCP, so they weren't registered in the DNS Name Servers.

I was able to get the expect answer in Linux using the nmblookup command:

$ nmblookup -A 10.185.140.22
Looking up status of 10.185.140.22
        SOMEHOST2       <00> -         M <ACTIVE> 
        XXX             <00> - <GROUP> M <ACTIVE> 
        SOMEHOST2       <20> -         M <ACTIVE> 
cn flag
`they get their dynamic IP through DHCP, so they weren't registered in the DNS Name Servers.` Static address assignment is not linked to the presence or absence of a DNS record. There's hundreds of millions of endpoints that register DNS records and get an IP address from DHCP. Also, if the problem is "nslookup isn't resolving a name", the solution is to create a DNS record.
aviro avatar
nl flag
@GregAskew Those are employees laptops that are not connected all the time. Their IP addresses might change every time they connect to the network. The DNS servers can resolve the hostnames, but cannot reverse resolve their IP address. I'm not familiar enough with DNS, so I don't know why DNS can resolve only the IPs of the hostnames but not the other way around. I don't know if it's a good question to open in this site, but if you can explain it it would be nice.
cn flag
Internally, a reverse DNS record has almost no value. If you want to create one, fine. In nearly all cases it doesn't do anything, unless you want to create something fragile that could break unexpectedly. So it isn't something that is causing a problem that would have a solution, or information that would be generally useful. I would argue that in large environments where there could be a lot of churn, a reverse lookup zone may actually have negative value, due to replicating those records that aren't used, and creating unnecessary chatter.
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.