possibly incorrect search order in inet:gethostbyname_tm/4

Chaos Wang chaoslawful@REDACTED
Mon Jan 18 03:57:53 CET 2010


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!

chaoslawful



More information about the erlang-bugs mailing list