Opened 9 years ago

Closed 6 years ago

#2575 closed defect (wontfix)

No DNS means no exiting

Reported by: atagar Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If an exit is unable or unwilling to relay DNS requests then it's reverted to being a non-exiting relay [1].

Is this a good idea? There's a tradeoff where on one hand we want to keep lookups and connections on the same circuit (limiting the spread of potentially sensitive information and due to possible colluding for correlation), but on the other this is throwing away potentially useful exits.

This might be a non-issue for numerous reasons...

  1. If the risks of the former out weigh the benefits of the later.
  2. If this almost never occurs (since this is done on the client side there's no way to tell).
  3. We need to direct the failed DNS requests somewhere and exits that, say, disallow HTTP might be doing so for reasons that make handling DNS requests for webpages bad for them. For this one I'd suggest that we direct these requests to exits that explicitly allow port 53.

I'm moving the discussion here from irc since it didn't get any traction and I'd like to make sure that we aren't needlessly hurting the network with this behavior. Cheers! -Damian

[1] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/router.c#l1867

From #tor-dev:
09:07 < atagar> Ahhh, evidently any exit relays DNS (reguardless of if they've allowed port 53), hence why it was ignoring the ExitPolicyRejectPrivate check. New couple questions in case anyone knows the answer offhand.

09:07 < atagar> Is anyone with any sort of accept before a reject-all in their exit policy considered to be an exit?

09:07 < atagar> Is this a good idea? Ie, are there cases where someone would want to be an exit but not provide DNS resolution? At present we drop relays that block tor from doing DNS resolution to be middle-hops (which could be hurting the network).

09:10 < atagar> here's the no-dns-makes-us-a-middle-hop code: https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/router.c#l1867

09:14 < shahn> The issue is that Tor connects to a hostname usually

09:15 < shahn> so if the exit node doesn't support DNS, then you can't use them for that without additional delays

09:17 < atagar> I understand why keeping lookups and connections on the same circuit is important, but is demoting these relays to be non-exits better than falling back to doing lookups via another circuit?

09:19 < shahn> (unless the resolution is already cached)

09:19 < atagar> of course

09:20 < shahn> sorry bigtime lag

Child Tickets

Change History (11)

comment:1 in reply to:  description Changed 9 years ago by rransom

Replying to atagar:

  1. We need to direct the failed DNS requests somewhere and exits that, say, disallow HTTP might be doing so for reasons that make handling DNS requests for webpages bad for them. For this one I'd suggest that we direct these requests to exits that explicitly allow port 53.

Why should we tie support for DNS requests to support for TCP connections to arbitrary hosts on port 53?

comment:2 Changed 9 years ago by atagar

Why should we tie support for DNS requests to support for TCP connections to arbitrary hosts on port 53?

I had been thinking that by accepting port 53 the relay operator's already agreeing to host DNS queries, but on second thought any relay that allows connections to the destination we're trying to reach would be perfectly fine.

comment:3 in reply to:  2 Changed 9 years ago by rransom

Replying to atagar:

Why should we tie support for DNS requests to support for TCP connections to arbitrary hosts on port 53?

I had been thinking that by accepting port 53 the relay operator's already agreeing to host DNS queries, but on second thought any relay that allows connections to the destination we're trying to reach would be perfectly fine.

How does a client know whether a relay allows connections to the destination it is trying to reach before the client has resolved the destination's hostname? How does the relay know whether it allows connections to a destination before deciding whether to allow a DNS request for the destination's hostname?

What we need are new relay flags: BadDNS and (possibly) DNSExit. BadDNS could someday replace BadExit for exits that are only bad because their DNS resolvers cannot be trusted, and DNSExit could be used to indicate that a non-exit relay allows DNS queries.

We would also need a new request-flags relay descriptor line, which a relay could use to ask the directory authorities to set or unset certain flags on it in the consensus. In this case, an exit relay whose DNS self-tests detect malicious behaviour could put request-flags +BadDNS in its descriptor (instead of replacing its exit policy with reject *:*). This descriptor line would have other uses as well; for example, a relay whose operator intends to shut it down in the next week could put request-flags -Stable -Guard in its descriptor.

Both of these changes require proposals, and BadDNS and DNSExit require some thought regarding backward compatibility (e.g. when to turn off adding BadExit along with BadDNS, and how to turn on client support for DNSExit).

comment:4 Changed 9 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 9 years ago by ioerror

This sounds like a good proposal. I'd be interested in working on it - is anyone else interesting in co-authoring a proposal with me?

comment:6 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:7 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:8 Changed 8 years ago by nickm

Now that we've merged proposal 205, an exit without working DNS would be pretty useless. (Except perhaps in an enclave situation, but we still don't have a correct design for that.)

Any future work here would need to figure out how to make such exits useful with our current notions of circuit isolation and our current off-by-default client-side DNS caches.

comment:9 Changed 8 years ago by nickm

Status: newneeds_information

comment:10 Changed 6 years ago by arma

Should we close this ticket, now that exits have to be able to do DNS resolves because clients don't cache dns answers anymore?

comment:11 Changed 6 years ago by nickm

Resolution: wontfix
Status: needs_informationclosed

Seems fine.

Note: See TracTickets for help on using tickets.