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

Raimo Niskanen <>
Mon Jan 18 16:07:24 CET 2010

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("", 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("", 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!


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}, 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

More information about the erlang-bugs mailing list