[ Continuing the discussion on the list instead of the bug report ] On 2020-05-18 20:22, Florian Weimer wrote: > * Mike Przybylski: > > > Since you’ve pointed out pretty clearly from the pcap that Google > > and VirtualBox are having some bizarre interaction, I think we can > > close this as “not a bug.” I apologize for taking up your time with > > it. > > It's the DNS implementation in Virtualbox that's broken, particularly > in the area of TCP support. Upstream glibc occasionally receives bug > reports about it, too.
Thanks for the confirmation. We have seen many cases of broken TCP fallback in the Debian BTS too, sometimes for good reasons, sometimes because the resolver is just adding additional records where it should not. That makes me wonder if enabling EDNS(0) by default would actually fix more issues than it creates. It seems to be compatible with RFC 6891 which describe the fallback with a "MAY": | 6.2.2. Fallback | | If a requestor detects that the remote end does not support EDNS(0), | it MAY issue queries without an OPT record. It MAY cache this | knowledge for a brief time in order to avoid fallback delays in the | future. However, if DNSSEC or any future option using EDNS is | required, no fallback should be performed, as these options are only | signaled through EDNS. If an implementation detects that some | servers for the zone support EDNS(0) while others would force the use | of TCP to fetch all data, preference MAY be given to servers that | support EDNS(0). Implementers SHOULD analyse this choice and the | impact on both endpoints. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net