[erlang-bugs] possibly incorrect search order in inet:gethostbyname_tm/4

[Raimo Niskanen]

I have done some research on my own...

These are the ones that succeed (and other numbers
within the ranges, of course):

Linux, FreeBSD, Solaris:
		AF_INET
"127.0.0.1"	->	127.0.0.1
"192.168.1	->	192.168.0.1
"10.1"		->	10.0.0.1
"17"		->	0.0.0.17
"192.168.65535"	->	192.168.255.255
"10.16777215"	->	10.255.255.255
"4294967295"	->	255.255.255.255
		AF_INET6
"127.0.0.1"	->	::ffff:127.0.0.1
"192.168.1	->	::ffff:192.168.0.1
"10.1"		->	::ffff:10.0.0.1
"17"		->	::ffff:0.0.0.17
"192.168.65535"	->	::ffff:192.168.255.255
"10.16777215"	->	::ffff:10.255.255.255
"4294967295"	->	::ffff:255.255.255.255
"::127.0.0.1"	->	::127.0.0.1
"::"		->	::

FreeBSD (addendum):
		AF_INET
"127.0.0.1."	->	127.0.0.1

OpenBSD:
		AF_INET
"127.0.0.1"	->	127.0.0.1
"127.0.0.1."	->	127.0.0.1
		AF_INET6
"::127.0.0.1"	->	::127.0.0.1
"::"		->	::

For IPv6 addresses there seems to be consensus: if it
parses as an IPv6 address according to the specifications
I recall, that IPv6 address is returned, except that OpenBSD
does not accept an IPv4 string when requesting an IPv6
address while the others do.

For IPv4 addresses Linux, FreeBSD and Solaris regards
many numeric strings as IPv4 addresses while OpenBSD
requires a 4-field dotted decimal. Both BSDs accept
a trailing dot for 4-field dotted decimal, while
Linux and Solaris regard a trailing dot as proof
that the string is an absolute hostname.

Conclusions:

The least common denominator (and the most common case)
would be to regard 4-field dotted decimal [0..255]
with no trailing dot as an IPv4 string.

The most widespread behaviour would be the Linux, Solaris
and FreeBSD (except for trailing dot) behaviour. And since
OpenBSD is not the origin of Erlang/OTP and has little
importance in the community, it would probably be
the most sensible behaviour.

The current inet_parse:ipv4_address/1 needs to be
augumented to handle the "192.168.65535",
"10.16777215" and "4294967295" IPv4 strings.

I'll toss the suggestion around internally and see if and when
we can make such a change into the Linux/Solaris behaviour...

/ Raimo



On Mon, Jan 18, 2010 at 04:07:24PM +0100, Raimo Niskanen wrote:
> On Mon, Jan 18, 2010 at 10:57:53AM +0800, Chaos Wang wrote:
> > Hi all,
> > 
> > inet:gethostbyname_tm/4 always try any specified DNS resolution methods 
> > first, and check whether the given domain name is a IPv4/v6 address when 
> > all previous tries failed. So even a string containing valid IP address 
> > is specified as domain name to be resolved, it still needs to traverse 
> > all the resolution methods before finding out it's already an IP address 
> > at last.
> > 
> > This would cause serious problems if 'dns' resolution method is 
> > specified in some corporation internal networks, in which all unknown 
> > domain names (including those treated-as-domain IPv4/v6 address string) 
> > will be resolved into the same portal server address. Only 'native' 
> > resolution method can be used in such an environment, because libc DNS 
> > resolving API will check whether the domain name is an IP address at first.
> > 
> > For example, in my working network, the resolving results when specified 
> > {lookup,[native]} in kernel inetrc are as following:
> > 
> >    > inet:getaddr("www.google.com", inet).    % real domain name, 
> > resolvable at DNS server
> >    {ok,{64,233,189,99}}
> >    > inet:getaddr("10.0.0.2", inet).          % treated-as-domain IP 
> > address, not resolvable at DNS server
> >    {ok,{10,0,0,2}}
> > 
> > But when specified {lookup,[dns]} in kernel inetrc, the results became:
> > 
> >    > inet:getaddr("www.google.com", inet).    % real domain name, 
> > resolvable at DNS server
> >    {ok,{64,233,189,99}}
> >    > inet:getaddr("10.0.0.2", inet).          % treated-as-domain IP 
> > address, resolved to portal server address by DNS server
> >    {ok,{115,124,17,136}}   % Oops...
> > 
> > IMHO the search order in inet:gethostbyname_tm/4 should be changed to: 
> > checking whether the domain name is already a IP address firstly, then 
> > try all specified domain resolution methods.
> > 
> > Thanks!
> 
> Hi!
> 
> You make a good case for changing the resolving order. I am almost
> on your side, there is just one little detail...:
> 
> Historically, portal server fake IP addresses has not been an issue
> for inet_res (the DNS resolver). Instead, it has had to balance between
> the RFCs and what actually is done in product networks.
> 
> It is not impossible for inet_res to be in an environment where
> the default domain is foo.bar and a lookup for "17" is supposed
> to return the IP address for the host 17.foo.bar. Now "17" is
> not a DNS label according to RFC 1035 section 2.3.1 but that
> is only a "Preferred name syntax".
> 
> Today it is more unlikely. But the question still is; 
> when can you safely assume the lookup string at hand is
> an IP address and not a host name.
> 
> The existing function inet_parse:ipv4_address is probably
> too forgiving since it translates "17" -> {0,0,0,17},
> "17.18" -> {17,0,0,18}, "17.18.19" -> {17,18,0,19}
> and "17.18.19.20" -> {17,18,19,20}, all from ancient
> praxis or even standards.
> 
> IPv6 addresses are more clear cut since any IPv6 address must contain
> at least two colons and that is very unlikely for a host name.
> 
> Can you strengthen your case by finding out more what it takes for
> libc DNS to be convinced the lookup string is an IPv4 address? 
> 
> > 
> > chaoslawful
> > 
> > 
> > ________________________________________________________________
> > erlang-bugs mailing list. See http://www.erlang.org/faq.html
> > erlang-bugs (at) erlang.org
> 
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB