Re: [RFC PATCH] getaddrinfo: Force name resolution for AI_CANONNAME [BZ# 24182]

[Heitor Alves de Siqueira <halves at canonical dot com>]

* Florian Weimer:

> This is not correct because it sends queries for names such as 192.0.2.1
to the DNS root servers.

Right, that can be avoided by setting the AI_NUMERICHOST flag, but it is a
problem if we just set the AI_CANONNAME flag (and then getaddrinfo() wouldn't
know if we meant the nodename to be an IPv4 address).
An alternative solution is to check if the nodename contains any '.' characters
(e.g. using strchr) after it was identified by inet_aton_exact(). In that
case, we could set ai_family to AF_UNSPEC and try name resolution since the
nodename could be either an IPv4 adress in 32-bit format or a numeric hostname.
Do you think that would be a better approach, Florian?

> I'm sorry, but I still don't see how the general idea is useful.  Which
applications benefit if getaddrinfo returns in ai_canonname which will most
likely resolve to a completely different set of addresses?

Most applications that go through glibc for network connections would benefit
from this. As an example, with the current behaviour we can't ssh to a machine
called '12345' in our LAN even if we explicitly add its IP address to
/etc/hosts:
$ head -n2 /etc/hosts
127.0.0.1 localhost
10.188.133.187 12345.lan 12345

$ ssh 12345
ssh: connect to host 12345 port 22: Invalid argument

If we change getaddrinfo() to handle digits-only hostnames, then we can
correctly reach the host:
$ ssh 12345
user@12345: Permission denied (publickey).

We could connect to these hosts using the FQDN according to the hosts
file or DNS,
but I think it's reasonable to expect the numeric host to resolve if it's set
in the /etc/hosts file or equivalent. Changing getaddrinfo() so that it resolves
numeric hostnames helps with this scenario not only for ssh, but also for other
glibc-dependent programs.

Thanks!
Heitor