Red Hat Bugzilla – Bug 123583
getnameinfo does not use /etc/hosts for lookup of V4MAPPED addresses
Last modified: 2007-11-30 17:07:01 EST
Reported by Jeff Trawick. I'll attach a modified version of Jeff's gni_mapped.c test program which does a getnameinfo lookup of 10.20.30.40, first using a sockaddr_in, then using the same address as a v4-mapped IPv6 address in a sockaddr_in6. For the first case, getnameinfo does use /etc/hosts; for the second, it does not. $ make gni_mapped $ grep 10.20.30.40 /etc/hosts 10.20.30.40 www.example.com $ ./gni_mapped look up via IPv4: 0/www.example.com look up via IPv6: -2/not found
Created attachment 100333 [details] repro case for getnameinfo bug
This behavior is by design. getnameinfo will return the IPv6 address if /etc/resolv.conf has an "options" line containing "inet6". I.e., add options inet6 to that file and try again. What we probably should do is to add this option to resolv.conf whenever /etc/sysconfig/network contains NETWORKING_IPV6=yes So this bug should probably be handled as a system-config-network bug. I'll reassign.
Well, that might work if every gethostbyname user would cope with 16-byte IPv4-mapped IPv6 addresses in the hostent, but they don't, they expect 4-byte IPv4 addresses. So the gethostbyname world breaks. Why can't getnameinfo() just DTRT here? On FC2: $ grep options /etc/resolv.conf options inet6 $ ping www.redhat.com PING www.redhat.com (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 time=0.038 ms64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.073 ms --- www.redhat.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.038/0.055/0.073/0.019 ms, pipe 2 $ grep options /etc/resolv.conf $ ping www.redhat.com PING www.redhat.com (209.132.177.50) 56(84) bytes of data. --- www.redhat.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms
> Well, that might work if every gethostbyname user would cope with > 16-byte IPv4-mapped IPv6 addresses in the hostent, but they don't, > they expect 4-byte IPv4 addresses. So the gethostbyname world breaks. No, why should it? gethostbyname never returns IPv6 addresses. gethostbyname2 does it only if af == AF_INET6. Likewise for gethostbyaddr. No program gets addresses in an unexpected format. > Why can't getnameinfo() just DTRT here? This is the intended behavior.
Empirically, that's exactly what it does, have you tried it? Also matches what resolv.conf(5) says: inet6 sets RES_USE_INET6 in _res.options. This has the effect of trying a AAAA query before an A query inside the gethostbyname function, and of mapping IPv4 responses in IPv6 ââtunnelled formââ if no AAAA records are found but an A record set exists. > > Why can't getnameinfo() just DTRT here? > This is the intended behavior. Why, what's the rationale for specifically ignoring /etc/hosts in this case?
and what about bug #124376 in this context?
(in case it wasn't clear; getnameinfo does work correctly for IPv4-mapped IPv6 addresses when it really uses DNS; this bug is just that it fails to use /etc/hosts)
I have checked in a change which will, for this case, indeed cause the correct result to be returned. Still, adding the inet6 option is still a good idea. > and what about bug #124376 in this context? Doesn't have much to do with it. If the getaddrinfo() function is used correctly, it will look up IPv6 addresses only if any interface has an IPv6 address configured. Since loading the ipv6 kernel modules automatically assigns link-local addresses to all interface this means IPv6 lookup happens every time when the ipv6 module is loaded. To prevent it the module must be stopped from being loaded.
The patch is in glibc-2.3.2-95.28 which ought to appear in U4 beta.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-586.html