On Wed, Jun 9, 2021 at 10:49 PM Stephen R. van den Berg srb@cuci.nl 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.