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

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 (moved), where a broken DNS config really does stop all Exit traffic.

changed milestone to %Tor: unspecified

added component::core tor/tor dns milestone::Tor: unspecified points::1 priority::medium reliability self-test severity::normal status::new tor-exit type::enhancement labels

Trac:
Cc: N/A to micah

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.

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 (moved)) 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.

For chutney, see also

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

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

#21394 (moved)

Trac:
Type: defect to enhancement
Keywords: N/A deleted, reliability self-test added

Chutney now has a workaround for this in #21903 (moved).

Trac:
Parent: #21900 (moved) to N/A

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

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.

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.

changed time estimate to 8h

moved to tpo/core/tor#21989