Opened 3 years ago

Last modified 5 months ago

#21989 new enhancement

Should we tell Exits to reject all traffic if DNS fails?

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: dns, tor-exit, reliability self-test
Cc: micah Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor:

Description

Tor Exits with broken DNS still allow Exit traffic.

But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)

Perhaps we should make Exits refuse traffic until their DNS is working?
(Unless a non-default option is set?)

This would also fix #21900, where a broken DNS config really does stop all Exit traffic.

Child Tickets

Change History (11)

comment:1 Changed 3 years ago by micah

Cc: micah added

comment:2 Changed 3 years ago by arma

I think we think we already have exits refuse to be exits if their dns isn't working.

See check_dns_honesty_callback() and the dns_launch_correctness_checks() that it calls.

It looks like it could be improved.

comment:3 in reply to:  2 Changed 3 years ago by teor

Replying to arma:

I think we think we already have exits refuse to be exits if their dns isn't working.

See check_dns_honesty_callback() and the dns_launch_correctness_checks() that it calls.

Well, maybe we try, but it doesn't work consistently right now.

In fact, chutney's upcoming offline mode (#21903) will rely on the fact that exits without DNS still allow exiting to IP addresses.

It looks like it could be improved.

If we fix this, we need to make sure AllowBrokenDNSConfig actually works. Or we need to add an option that maintains the current behaviour, because chutney relies on it.

comment:4 Changed 3 years ago by arma

For chutney, see also

  if (!get_options()->ServerDNSDetectHijacking)
    return;

comment:5 Changed 2 years ago by cypherpunks

But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)

#21394

comment:6 Changed 2 years ago by nickm

Keywords: reliability self-test added
Type: defectenhancement

comment:7 Changed 2 years ago by teor

Chutney now has a workaround for this in #21903.

comment:8 Changed 14 months ago by nickm

Parent ID: #21900

comment:9 Changed 5 months ago by cypherpunks

relays with Exit flag are still useful as Exits for IP destination traffic.

comment:10 in reply to:  9 Changed 5 months ago by micah

Replying to cypherpunks:

relays with Exit flag are still useful as Exits for IP destination traffic.

That is undeniable, however what is at issue is how useful is that for the network, when the other pieces do not work.

Consider a relay with an Exit flag that only resolves DNS, but doesn't pass traffic. That doesn't seem particularly useful to the network, but it does resolve DNS queries.

I don't think anyone is thinking, "What I'd like is a anonymity network that will only pass IP traffic, and not resolve DNS in any meaningful way"

I think the network is only useful if it works for people who want to have functioning DNS resolution, but also those who are fine not having it, but not one at the expense of the other.

comment:11 Changed 5 months ago by cypherpunks

If i pass traffic to a

 SocksPort     IPv4Traffic IPv6Traffic OnionTraffic NoDNSRequest

user can expect still use this relay? they are still providing rare exit bandwidth. make use of it as far as possible?

client needs somehow know, the exit cant resolve dns. so that it does not choose to attach a stream with hostname to it. just like it checks exitpolicy to see if it would with usually Support connection target address:port

it would be nice to mark this exit as BadDNS or something. to let client know, not to choose it while using hostname targets. but in any other case.

Note: See TracTickets for help on using tickets.