2

The domain name consists of numbers only, example 300010100. If I try pinging the name only without FQDN, it responds back with a very odd IP address, 0.154.29.62 and giving transmit failed errors. If I add .local to the end of the name, 300010100.local, then it pings fine. My issue is I have a client that is trying to install MS Management Reporter 2012 and because it tries to use the name only instead of the FQDN and because the name only is unresovable, we cannot get the software to install. How can I get the number only to be able to ping correctly?

Benjamin Del Carpio
  • 21
  • 3
  • 2
    "_The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less._" – Ron Maupin Feb 02 '17 at 18:17
  • Yep, I found this link here stating just that about this situation - http://serverfault.com/questions/545561/validity-of-a-fqdn-with-a-hostname-consisting-entirely-of-numbers I am hoping there is a workaround or alias or something I can do in DNS to make this work? Any help is appreciated. Thanks. – Benjamin Del Carpio Feb 02 '17 at 18:39
  • @BenjaminDelCarpio I don't think this can be worked around. Integers have been treated as the integer representation of an ip address by various resolvers since at least back in the win9x days. It's not just a windows thing either, the resolver on Linux handles integers the same way. – DerfK Feb 02 '17 at 20:43
  • @DerfK Just figured one out...the trick of appending a `.` to force an entity to be interpreted as a FQDN seems to also force IP addresses to be interpreted as names. – Andrew B Feb 02 '17 at 21:00

1 Answers1

3

The issue is most likely that the number is being interpreted as the decimal equivalent of a dotted IP address. The easiest way to confirm is to open up the nslookup client and repeat your tests there. This is one of the reasons why purely numeric DNS labels are a bad idea; resolver libraries accept an input of IP addresses and DNS entities, and will tend to err in favor of passing IP address representations through unmodified. Only DNS focused tools such as nslookup and dig which bypass the resolver library and assume that the input should be interpreted as a name will be exempt from this.

Workaround: Use the fully qualified name. (300010100.contoso.com instead of 300010100) This forces the resolver to interpret the input as a DNS entity and avoids the undesired translation to IP address. If you find yourself in a bizarre scenario where 300010100 is the FQDN and there is no domain component, append a dot to the end. (300010100.) The terminating dot tells the resolver that this is a fully qualified name, and forces the integer to be interpreted as a name.

(Of note, my Windows 7 workstation translates 300010100 to 17.225.202.116 using the ping command, and I need a value of 10100030 to replicate your result of 0.154.29.62. Obfuscation in your question perhaps?)

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • Heh you figured out the actual domain name. It is 10100030 and adding the . at the end did not help. It ends up not resolving to anything. The installer will not let us define the true domain name and will just use the netbios name because that's supposed to work... If I can't do anything on the DNS side to try to make it work, I don't see how else to do it. I tried editing hosts file but did nothing, same result. – Benjamin Del Carpio Feb 02 '17 at 22:11
  • I think you might be using the wrong term. NetBIOS is considered deprecated by Microsoft, and I find it unlikely that a product in the 2012 line would ignore DNS in favor of it. If you've tried appending the DNS suffix associated with your AD forest to no avail, that sounds like a UI limitation, and I'm afraid that I'm stumped. :( – Andrew B Feb 02 '17 at 22:32
  • I wish I had a copy of the logs right now but it's definitely ignoring the .local portion and trying to use only netbios name which fails. – Benjamin Del Carpio Feb 02 '17 at 22:35
  • I think it's more likely that the application only accepts short names, does not allow FQDNs to be keyed, and barfs because the short name in this case gets interpreted as an IP address. An easy way to confirm this would be to try keying in a non-numeric name that does not exist, and seeing if a corresponding DNS lookup shows up in a packet capture. – Andrew B Feb 02 '17 at 22:39
  • For NetBIOS names you should be using the LMHOSTS file. Try adding your entry to the LMHOSTS file and see if that resolves the issue. – joeqwerty Feb 03 '17 at 03:25
  • I tried adding this to LMHOSTS (192.168.233.1 ipremisesvr #PRE #DOM:10100030) and its still trying to convert to a network address. – Benjamin Del Carpio Feb 03 '17 at 21:13