Domains aliased to a pool of IP addresses doesn't get resolved

[Florian Weimer]

On 10/16/2015 11:12 AM, Yuri Kanivetsky wrote:
>> This looks reasonable.  Does name resolution with getaddrinfo still fail?
>>
>> Can you run your test program under “strace -s 5000” and post the output?
> 
> Yeah, it fails, but after a number of gpg runs:

>     recvfrom(3,
> "\215\220\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1\300\f\0\5\0\1\0\0\32\360\0\26\4pool\16sks-keyservers\300\27\300,\0\34\0\1\0\0\0<\0\20*\1\4\370\1b4B\0\0\0\0\0\0\0@\300,\0\34\0\1\0\0\0<\0\20*\1\4\370\r\26\30I\0\0\0\0\0\0\0\2\300,\0\34\0\1\0\0\0<\0\20
> \1\0078\0\0\6\0\2\26>\377\376\2\0B\300,\0\34\0\1\0\0\0<\0\20 \1\30h
> \3\0\0\0\0\0\0\0\0\0\22\300,\0\34\0\1\0\0\0<\0\20
> \1A\320\0\10\347w\0\0\0\0\0\0\0\1\300,\0\34\0\1\0\0\0<\0\20&\4\250\200\10\0\0\20\0\0\0\0\2'\340\1\300,\0\34\0\1\0\0\0<\0\20&\6\225\0\2\1\0\1\0\0\0\0\0\0\1A\300,\0\34\0\1\0\0\0<\0\20*\0\271\300\0\16\0\0\0\0\0\0\0\0\0\4\300,\0\34\0\1\0\0\0<\0\20*\1\4\370\1QBB\5<\0\0\0\0\31\221\300,\0\34\0\1\0\0\0<\0\20*\1\4\370\1aB\203\20\0\0\0\0\0\2\3\3001\0\2\0\1\0\0\0\1\0\7\4ns12\3001\3001\0\2\0\1\0\0\0\1\0\6\3ns9\3001\3001\0\2\0\1\0\0\0\1\0\6\3ns2\3001\3001\0\2\0\1\0\0\0\1\0\6\3ns6\3001\3001\0\2\0\1\0\0\0\1\0\r\3ns1\6kfwebs\300\27\3001\0\2\0\1\0\0\0\1\0\7\4ns13\3001\3001\0\2\0\1\0\0\0\1\0\6\3ns2\301\263\3001\0\2\0\1\0\0\0\1\0\7\4ns10\3001",
> 1546, 0, {sa_family=AF_INET, sin_port=htons(53),

This response to the AAAA query has TC=1, instructing the client to try
again over TCP.

> sin_addr=inet_addr("10.0.2.3")}, [16]) = 500
>     close(3)                                = 0
>     socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
>     connect(3, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("10.0.2.3")}, 16) = -1 ECONNREFUSED (Connection
> refused)

But the resolver refuses the TCP connection.  This is a resolver bug,
not a glibc bug, and even if we address the issue below, name resolution
would still fail.

>     close(3)                                = 0
>     socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
>     connect(3, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("10.0.2.3")}, 16) = 0
>     poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
>     sendmmsg(3, {{{msg_name(0)=NULL,
> msg_iov(1)=[{"I\302\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\5Dlink\0\0\1\0\1",
> 38}], msg_controllen=0, msg_flags=0}, 38}, {{msg_name(0)=NULL,
> msg_iov(1)=[{"\205\374\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\5Dlink\0\0\34\0\1",
> 38}], msg_controllen=0, msg_flags=0}, 38}}, 2, MSG_NOSIGNAL) = 2

I think it is incorrect to retry on a network failure with a different
domain name, which is what seems to be happening here.  If there is a
network failure, the network failure should be reported.  Otherwise, we
could get different name resolution results if there is a (brief)
network outage.

I will try to reproduce this locally and file a bug if necessary.

Florian