Exits should resolve IPv6 addresses, regardless of IPv6Exit
That way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6Exit
Activity
changed milestone to %Tor: unspecified
Right. Specifically, it's this code:
if (get_options()->IPv6Exit)The underlying bug is that exit relays are returning REASON_RESOLVEFAILED for resolve attempts to addresses like ipv6.google.com, which causes clients to get no hints about which exits might be able to reach that address successfully. If the exit relay would do the AAAA resolve, then it could usefully respond with REASON_EXITPOLICY, and include the v6 address in the end cell, and then clients could try again on a circuit that has explicit v6 exit support.
-
I think we shouldn't worry about whether exits meant to allow v6 lookups -- if you're an exit relay and you're willing to do v4 resolves, then I think it's a legit assumption that you're willing to do v6 resolves too.
One question that makes me pause though: are there dns resolvers out there that quietly drop AAAA resolve requests, which would cause surprising timeouts on exits while they wait for both resolve responses?
-
(I thought briefly about whether we should only launch the v6 resolve attempt if the stream that triggers our resolve would be interested in a v6 answer. But since this cached resolve answer is meant to be used for multiple streams, meaning potentially multiple clients, and we probably don't want to introduce a side channel about what sort of request showed up last time for this address, that seems like a poor idea.)
-
Replying to arma:
Is the fix just to remove the two "if IPv6Exit" checks from launch_resolve()?
In that case we'd want to remove the "if IPv6Exit" from set_exitconn_info_from_resolve() too, so we're willing to return the answers we've got.
And also do something about the
bcell.flags &= ~BEGIN_FLAG_IPV6_PREFERRED;line in connection_exit_begin_conn().
See my branch bug21311-v2 on github. It requires #21310 (moved) to work.
Trac:
Actualpoints: N/A to 0.1
Milestone: Tor: unspecified to Tor: 0.3.1.x-finalTrac:
Summary: launch_resolve() should always resolve AAAA records, regardless of IPv6Exit to Exits should resolve IPv6 addresses, regardless of IPv6Exit
Description: That way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.to
That way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6Exit
-
Patch looks good! But it needs #21310 (moved) to get resolved before it can be the right patch.
Have you tested it?
-
Note that we're changing behavior from before, where before we would only consider launching the v6 resolve if creating the v4 resolve succeeded. Now we're launching the v6 resolve even if something went wrong while setting up the v4 resolve.
This choice is fine with me, but whoever made the original choice (was that Nick?) should see it and consider it too.
Replying to arma:
Patch looks good! But it needs #21310 (moved) to get resolved before it can be the right patch.
Have you tested it?
That was my plan over the weekend, but it didn't end up happening. I think it needs a tor network with 1 IPv6 exit and 7 IPv4 exits to match the current proportions in the public network. We should get a 100% success rate for ipv6.google.com with this patch, and ~12.5% - ~37.5% without it. (Clients on the public network should have a success rate of 3 * 12.5%, but they actually have a success rate around ~10%. I wonder if there are a lot of non-functional IPv6 exits out there?)
Putting in needs_information until it's been tested.
Trac:
Status: needs_review to needs_informationTrac:
Parent: N/A to #17811 (moved)
