Why does MacOSX try to resolve zero padded IP addresses as host names?

Question

This one caused a friend some headache when setting up a switched internet connection which had zero padded IP addresses in the configuration paper like so:

192.168.019.254

No matter how he tried to configure the Mac network stack, it just didn't work. But the GUI also didn't complain about errors.

I later found out that pinging these zero padded addresses in a terminal showed "unable to resolve" while pinging the same address without padded zeros (192.168.19.254 vs. 192.168.019.254) showed "unable to reach" which brought much light into this mysterium. Removing the useless zeros made everything work.

Is this a bug or a feature? I never experienced such strange behaviour before - no matter if I use the GUI or CLI to configure or test IP stuff.

Answer 1

Translation from a string to an address is usually performed by the POSIX function getaddrinfo(). This function first checks for a numeric IP address using inet_addr(), and if that fails it will then attempt to resolve the string as a domain name. inet_addr() interprets numbers with a leading 0 as octal, so for example 010 would become 8, and 019 would be an error (and would therefore be resolved as a domain name). The same behavior occurs on Linux and Solaris as well.

From getaddrinfo():

If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid.

From inet_addr():

All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise, the number is interpreted as decimal).

Note the address 192.168.8.254 in parentheses:

$ ping 192.168.010.254
PING 192.168.010.254 (192.168.8.254): 56 data bytes
Request timeout for icmp_seq 0