Although we try to keep fixes separate, the fix for these two bugs ended up
being too intertwined to readily separate.
The primary change of interest is to split the HostDB in to separate IPv4,
IPv6, and SRV sections. The SRV records were already split in an ad hoc way,
this change formalizes and generalizes that. I split the IPv4 and IPv6 sections
so that ATS can handle servers that have both address families. Currently ATS
simply uses which ever address family it gets first for a specific server. This
is fine for hosts that have only one family addresses but I expect that during
the transition many servers will have both and ATS should handle that better
than simply locking in a random family. This is particularly important for
transparent proxying because this will lock in a specific address family (that
used by the client) and prevent cross family connections through ATS.
As a sort of side effect the way server address resolution is handled is
completely different. As far as I could tell, the previous method (the
prefer_ipv6 configuration option) was not actually used so I don't consider
it much of a loss. The new system is described in the TS-1307 write up and can
be configured globally and per HTTP proxy port. The one significant change from
that is that server side transparent ports are forced to use the equivalent of
client;only for server IP address resolution because no other preference
ordering can be implemented.
Hopefully, unless you are doing something tricky with DNS / HostDB this change
should just work better. You may be able to improve HostDB performance a little
bit if you are dealing with servers that have only one address family by using
DNS negative caching - rather than timing out on an IPv4 DNS attempt and then
failing over to IPv6, the negative IPv4 result can be cached and immediately
skipped.
I also hope that the code is actually simpler and easier to understand, I did
quite a bit of what I consider cleanup and did not use any templates.
I have a design and tenative implementation for (some) parallelization of IPv4
and IPv6 queries but it was a bridge too far for this commit. I plan to work on
that in the future.
