Re: Glibc reordering of IPv6 and IPv4
* Ken Raeburn | 2010-05-17 10:11:53 [-0400]:
>This isn't an ordering issue; standard gethostbyname() simply doesn't return
>IPv6 addresses.
ACK, this is intend behavior as stated in RFC 2133
>Are they turning on "options inet6" in resolv.conf (or hard-coding the
>equivalent in libc)? From what I read in the man page for resolv.conf, it
>sounds like that returns only IPv6-format addresses (mapping IPv4 addresses
>to IPv6 in the process), instead of the standard IPv4 addresses, which I
>think would break every gethostbyname() application that doesn't know about
>this extension and explicitly check for it. (Really, I can't figure out what
>"options inet6" is good for. If you're going to hack your application to
>know about these extensions, you might as well just use getaddrinfo. Even if
>you do hack some of your applications to expect IPv6 addresses from
>gethostbyname, the config file option affects *every* such application.)
If "options inet6" is set, the environment variable RES_OPTIONS is set to
inet6 or res_init() is called and _res.options is XORed with RES_USE_INET6,
then gethostbyname("example.com") is redirected to gethostbyname2("example.com", AF_INET6).
The idea was that a legacy application changes the program code and it is up
to several lines of code, a environment variable or even a resolver option to
switch to IPv6. Consider this mechanism as a early design error.
HGN
I will answer to the other question in a couple of minutes because it is not
that simple as is sounds. ;-)
Reply to: