On Wed, Jun 9, 2021 at 10:49 PM Stephen R. van den Berg <[email protected]> wrote: > > I'd say, the way forward should be changing the connecting functions to > iterate through the IP addresses and find the first that actually connects. > > >Needn't revert completely. If it's decided that the preference should > >continue to be A, then it's just a matter of reversing the order of > >returned values - a simple matter of switching two numbers. > > That would be an acceptable workaround until the connection code is fixed, > I think.
Maybe I am the one missing something here, but even if "the connection code" were to learn to try to establish connections to all IPv4+IPv6 addresses resolved for a hostname, it could not do that on top of Protocols.DNS.async_host_to_ip, as that returns a single result. Changing it to result in something other than a single result will break every single user of Protocols.DNS.async_host_to_ip. As Protocols.DNS.async_host_to_ip is thus constrained to providing a single response, changing it to respond with an IPv6 IP preferred at this stage of IPv6 deployment is breaking more than it fixes. I would assume there are still much more IPv4-only than IPv6 hosts in the world, and the amount of IPv6-only hosts will be severely limited - at least some 6to4 translation should normally be available. Responding with IPv6 addresses first, esp. without applying any heuristics whatsoever to determine if a system might be IPv6-enabled, can thus only be seen as a severe regression. Responding with an IPv6-address if no IPv4-address can be resolved might not be a regression, but is neither terribly consistent or elegant, so it might be best to not do that either. All in all, I think the solution - beyond restoring useful and expected behaviour of Protocols.DNS.async_host_to_ip - would be to introduce a more suitable API - if necessary - and to start using that instead.
