The "rotate" option in resolv.conf breaks IPv6 lookups for hostnames that have CNAMEs

[Tore Anderson]

When /etc/resolv.conf contains "options rotate", and I try to look up a hostname that first points to a CNAME, which then points to another hostname with both an A and an AAAA record, the AAAA record isn't returned. Instead I get an IPv4-mapped IPv6 address containing the A record.

Note that my server does not have any IPv4 addresses assigned to it (except for 127.0.0.1/8 on the loopback interface).

My resolv.conf contains the following:

> options rotate
> # Google Public DNS
> nameserver 2001:4860:4860::8888
> nameserver 2001:4860:4860::8844

An example of the bug being reproduced:

> $ host no.archive.ubuntu.com
> no.archive.ubuntu.com is an alias for mirror.trivini.no.
> mirror.trivini.no has address 129.241.93.37
> mirror.trivini.no has IPv6 address 2001:700:300:1800::b
> $ getent ahosts no.archive.ubuntu.com
> ::ffff:129.241.93.37 STREAM no.archive.ubuntu.com
> ::ffff:129.241.93.37 DGRAM
> ::ffff:129.241.93.37 RAW

However, if there are no CNAMEs involved, it works as expected:

> $ getent ahosts mirror.trivini.no
> 2001:700:300:1800::b STREAM mirror.trivini.no
> 2001:700:300:1800::b DGRAM
> 2001:700:300:1800::b RAW

Also, if the hostname pointed to by the CNAME does not have an A record, it also works as expected:

> $ host v6only-cname.fud.no
> v6only-cname.fud.no is an alias for v6only.fud.no.
> v6only.fud.no has IPv6 address 2001:db8::1
> $ getent ahosts v6only-cname.fud.no
> 2001:db8::1 STREAM v6only-cname.fud.no
> 2001:db8::1 DGRAM
> 2001:db8::1 RAW

If I remove or comment out "options rotate" from resolv.conf, it works as expected:

> $ getent ahosts no.archive.ubuntu.com
> 2001:700:300:1800::b STREAM trivini.no
> 2001:700:300:1800::b DGRAM
> 2001:700:300:1800::b RAW

The server in question is running Ubuntu 12.04 Precise (developement branch), libc6 package version 2.13-24ubuntu2. Architecture is x86_64. I also tried to reproduce the bug on a Fedora 16 machine using glibc package version 2.14.90-14, but could not. I therefore assume that the bug is either caused by a Ubuntu-specific patch, or that it has been recently fixed upstream.

I am able to provide SSH access to the server in question, if that is helpful (via an IPv4-to-IPv6 translator if necessary).

Tore