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

[Raimo Niskanen]

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