This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Domains aliased to a pool of IP addresses doesn't get resolved
- From: Florian Weimer <fweimer at redhat dot com>
- To: Yuri Kanivetsky <yuri dot kanivetsky at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 16 Oct 2015 15:08:20 +0200
- Subject: Re: Domains aliased to a pool of IP addresses doesn't get resolved
- Authentication-results: sourceware.org; auth=none
- References: <CAMhVC3YY6X+=_dhRbHkw+=m_exfD0yva1mLP78dq8wy47wT3tg at mail dot gmail dot com> <561B9C19 dot 2000906 at redhat dot com> <CAMhVC3bm7K7MXn-BsEPHq+SpVDyxrV5CJgbAVnfcC5nr7bYoqA at mail dot gmail dot com> <561F840B dot 2060802 at redhat dot com> <CAMhVC3ajOFhdA21F12mrLOgeJDtHx+DxzAixDF2OAEz6TSGz5g at mail dot gmail dot com> <5620194C dot 3090200 at redhat dot com> <CAMhVC3bKfeRmOSdKP3mz4Yu9NcyiLjwyz5ebWjibVka-UsY+3g at mail dot gmail dot com>
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