Docker Desktop 2.1.0.1 fixes large DNS responses on Mac

A name that resolves on the Mac host can still fail inside its containers when the intervening DNS proxy mishandles a large response. Docker Desktop Community 2.1.0.1, released August 8, addresses that specific development-environment problem. Its release notes list support for large DNS record lists, resolver stability corrections, and truncation of UDP DNS responses exceeding 512 bytes.

The same update bundles Docker Engine 19.03.1, Compose 1.24.1 and Kubernetes 1.14.3. Those version changes describe the local software stack, but the DNS fix is an especially useful part of the release to understand. It concerns whether the development environment preserves network behavior between a host lookup and the corresponding container lookup.

I value Docker for making environments shippable between machines. Desktop still has to connect those environments to a host operating system and its network. A defect in that connection can make an otherwise repeatable application image behave differently without any source or dependency change.

Large replies exposed the proxy behavior

The linked Docker for Mac issue 2160 dates to October 2017. Its author expected records resolvable on the host to remain resolvable in containers. The report describes unreliable results for hundreds of address records and worse behavior when CNAME indirection preceded the same large record set.

The reporter's packet observations are useful because they separate a resolver's response from delivery to the container. According to the report, the proxy fell back to TCP upstream but delivered a UDP packet downstream. Large replies approached the intervening network's packet-size limit, and only some reached the container. The author identified missing truncation and TCP fallback handling as the suspected cause.

These are observations from the issue, not measurements of every Desktop installation. They nevertheless identify a concrete failure condition. A small lookup can succeed through the same environment while a larger one fails. That makes a successful lookup of an unrelated short record a poor test of whether the reported bug is present.

An October 2018 follow-up supplies a test service with a small record set and another containing 420 records. Its author reports successful direct lookups on Linux and macOS while Docker for Mac times out or returns incomplete data. This gives the issue a reproducible comparison across the host and container path, rather than only an application symptom.

Truncation is part of successful resolution

The initial report explicitly asks for oversized UDP responses to be truncated with the truncation flag set so clients know to retry over TCP. That is a different result from silently losing the response or returning an apparently complete subset. A client needs a protocol-level indication that its current transport has not delivered the whole answer.

The August release notes describe truncating UDP DNS responses above 512 bytes. They also list support for large resource-record lists separately. Together those entries address the path by which a large answer can reach a client that must handle a limited UDP reply. The notes do not justify inventing a new universal size limit for all DNS uses, but they do identify the behavior changed in this product.

A partial answer is particularly difficult to interpret when it appears successful. A timeout makes failure visible. Incomplete data without the proper indication can make the caller reason about a different set of addresses than the authoritative response contains. The issue's comparison between direct and proxied lookups is therefore important even when a command returns something.

This is why a Desktop networking fix belongs in an account of application reproducibility. The image can hold the same resolver program and application binaries on each run. If the proxy outside that filesystem changes the response they receive, the application inputs are still different.

The update changes a bundled environment

Desktop 2.1.0.1 also lists LinuxKit v0.7, Linux kernel 4.9.184 and QEMU 4.0.0 among its upgrades. Its component list makes clear that the Desktop release number describes more than a Docker client binary. The host-facing application supplies an environment in which the Engine and its supporting services run.

The notes include another DNS change. Desktop stops sending queries for docker-desktop.<domain> every ten seconds and relies on the host's DNS search order instead of trying to reproduce it inside the virtual machine. That is a separate correction to how host naming configuration participates in the local environment.

For my preferred small service images, these details remain outside the application's final filesystem. That makes their documentation useful. A host network change and an image rebuild act on different parts of the lookup path, even when both appear to affect the same application request.

The August bundle brings a newer Engine and local Kubernetes version, but its large-response fix has a narrower operational meaning. It restores the container lookup path's ability to handle answers that already work on the host. The linked report explains why small successful DNS queries did not demonstrate that this path worked for a larger record set.