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
Cc: | micah added |
---|
comment:2 follow-up: 3 Changed 3 years ago by
comment:3 Changed 3 years ago by
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
For chutney, see also
if (!get_options()->ServerDNSDetectHijacking) return;
comment:5 Changed 2 years ago by
But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)
comment:6 Changed 2 years ago by
Keywords: | reliability self-test added |
---|---|
Type: | defect → enhancement |
comment:8 Changed 14 months ago by
Parent ID: | #21900 |
---|
comment:9 follow-up: 10 Changed 5 months ago by
relays with Exit flag are still useful as Exits for IP destination traffic.
comment:10 Changed 5 months ago by
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
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.
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.