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