Comment 74 for bug 417757

When I test this command :
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com AAAA; done
The response is instantaneous. But when I do this lookup :
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.speakeasy.net AAAA; done
This is very slow, and the delay is there.
Notice that I have no IPv6 connectivity, and that the IPv6 stack is activated, as the default.
This is the delay that we are talking about. And I think this is a misbehaviour from the involved authoritative DNS servers :
http://www.ietf.org/rfc/rfc4074.txt
The explanation is that the DNs server should return an error when there is no AAA record. But in this case it returns nothing. It doesn't follow the RFC. So the resolver wait for the answer, and then time out.
I think that the fact of changing one DNS server to another resolved the problem is due to the fact that the newly configured DNS servers does cache the "no response" state", or something like that. Just a thought. Don't know enough sfuss about it.

One solution is to wait for the involved DNS to update and support AAA records. But it may happen in years.
Another solution is : Disable AAA address resolution when there is no IPv6 routable address configured on any interface, or when Network manager has his IPv6 parameters set to "ignore" (which is the default in Karmic, and is a new feature that is not present in Jaunty ). The getaddrinfo() function is the one that should not ask for AAAA records when there is no IPv6 connectivity.
It seems that the Red hat team has already encountered this problem :
http://kbase.redhat.com/faq/docs/DOC-17904

The wrapper library seems to be a solution for that. What do you think of all this ?