Hi Mike,

On 2020-05-16 10:57, Mike Przybylski wrote:
> Hi, Aurelien,
> Thank you for looking into this.  I really appreciate it.
> > Which nameserver do you use?
> Google DNS ( and )
> > As the answer is probably large, it might
> > be interesting to check if it supports TCP connections as a fallback.
> > Alternative you might want to enable edns0 if it's not already done.
> I will definitely look into that.
> > Could you try with other nameservers, there are many public DNS servers
> > available to test.
> I’m sorry that I didn’t think of that.  Everything works fine with OpenDNS ( 
> and ).
> > Finally would it be possible to get a tcpdump trace of the issue? That
> > would likely help to understand the issue.
> Please see the attached pcap file.

Thanks a lot for the pcap file. I got a look at it, and there is indeed
something fishy:
- asks for A download.docker.com (query 0xd009)
- asks for AAAA download.docker.com (query 0x710a)
- answers query 0xd009
- answers query 0x710a but marks it as truncated as it it too

Up to there all looks normal. As expected the AAAA query 0x710a is
retried using TCP:
- asks for AAAA download.docker.com (query 0x710a)
- answers to query *0xd009* with the *A* records. This is
  totally unexpected.

The glibc resolvers therefore retries with the second name server:
- asks for AAAA download.docker.com (query 0x710a)
- answers to query *0xd009* with the *A* records, the same way
  as This is again totally unexpected.

As both TCP queries failed, glibc concludes there is a server error.

I have no idea what could explain that, it seems there is something
between the Google DNS servers and you host mangling the answers. I
noticed that the IP of your host is Could it be a QEMU or
Virtualbox VM running with the user mode network stack?


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Reply via email to