At 300 A records, maybe every other response packet never arrives.

At a CNAME to the same 300 A records, several attempts are necessary until one succeeds; about half the time the number of retries is exhausted and the lookup fails.

Looking up a CNAME to a CNAME to 300 A records works basically never.

A records in a single response work basically never.

This was even worse (none of the above cases worked at all) in 17.06, with 17.09 some of them work some of the time.

In the stage where things get wonky, these packets are just under 1500 bytes, varying slightly in each response (presumably due to reordering of the records compression).

That means theyre edging up on the 1500 byte MTU of the ethernet devices between the host and the VM, as well as the VM and the container.

Based on the smaller records I assume that there is some spread of the response length, but only those responses that actually fall under the magic 1514 bytes make it through.

When a client outside of Docker tries to resolve that name, it gets a reply that the response is truncated so it switches to a TCP connection and queries again the server.

When using Docker and user mode networking, the initial request from a client (in a container) is replied over UDP with 30 answers so 2 random entries are truncated.

Stale issues will be closed after an additional 30d of inactivity.

Only on docker-for-mac (tested on 18.06.1-ce-mac73 ) the issues describe above appear.

I believe the error is in the DNS forwarder inside so Ive created a candidate fix and a unit test for it.

So I think the TCP fallback issue is fixed but there appears to be a separate issue about the total number of records returned.

Udp Docker For Mac