0

I'm pretty sure this is down to the DNS configuration for the domain that has houses the 192.168.0.0 PTR records (which belongs to a company we bought). Is this clear enough to someone that they can explain what was done incorrectly?

The problem presents itself on Windows as IP addresses that are in our network being transformed to IP addresses outside of our network.

On *NIX like systems including OSX:

$ host 192.168.0.1
1.0.168.192.in-addr.arpa is an alias for 1.128-27.0.168.192.in-addr.arpa.
1.128-27.0.168.192.in-addr.arpa domain name pointer foo.bar.

The IP address 192.168.0.1 is a load balancer for foo.bar

$ host foo.bar
foo.bar is an alias for foo.baz.
foo.baz has address 10.0.0.1

foo.baz is a monitoring and analytics service we subscribe to that forwards to 192.168.0.1

That configuration seems kinda' screwy, it's what we inherited.

Here's where it gets more confusing, in Windows when we resolve the load balancer IP and get this:

PS C:\> [System.Net.Dns]::GetHostEntry("192.168.0.1")

HostName                                Aliases                                 AddressList
--------                                -------                                 -----------
foo.baz                                 {}                                      {10.0.0.1}

What is Windows doing to seemingly make extra lookups, and why?

3
  • Have you considered running a network capture (e.g. Wireshark) to spot the differences? Apr 3, 2017 at 23:42
  • Not sure I follow. The reverse DNS lookups for 192.168.0.1 are resolving to different names depending on where you run them from. This suggests that the devices the lookups are being run on point at different sources of authority for that information. Unless your company has invested some effort in ensuring that there is a single "source of truth" for reverse DNS lookups on private IPs, this is business as usual. Update the PTR record on the DNS server providing the answer you like less.
    – Andrew B
    Apr 4, 2017 at 1:00
  • I captured the Powershell request/response with Wireshark. The PTR lookup resolves to a CNAME (which according to RFC 1912 is bad), then GetHostEntry() resolves that alias, so it's generating two lookups from one call. Apr 4, 2017 at 14:25

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.