TS-1422, TS-1307: HosDB / DNS changes

["Alan M. Carroll" <am...@network-geographics.com>]

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.

Re: TS-1422, TS-1307: HosDB / DNS changes

["Alan M. Carroll" <am...@network-geographics.com>]

Monday, December 10, 2012, 11:33:36 PM, you wrote:

> hmm, change in the interface, do you have tested the SplitDNS?

The interface change at the top level is minimal. I did test SplitDNS but I'll run some more tests today.

Re: TS-1422, TS-1307: HosDB / DNS changes

["ming.zym@gmail.com" <mi...@gmail.com>]

hmm, change in the interface, do you have tested the SplitDNS?


在 2012-12-10一的 11:12 -0600，Alan M. Carroll写道：
> 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.
>