Redo DNS tests when exit policy changes from reject ; avoid when policy changes to reject

changed milestone to %Tor: unspecified

added component::core tor/tor easy milestone::Tor: unspecified priority::low resolution::fixed status::closed tor-relay type::defect version::tor post 0.1.2.x labels

Trac:
Keywords: N/A deleted, N/A added
Parent: N/A to N/A
Milestone: post 0.2.1.x to Tor: 0.2.2.x-final

Marking as "easy"; this isn't a bad project for somebody who wants to do a little more C.

Trac:
Description: > hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit traffic, and still do DNS tests. Isn't that supposed to be different? i've had a todo item for nick to not do dns tests if reject :. he didn't want to put it in, though. i think that you would need to remember whether you did them, and if not launch them, if exit policy changes from reject * to something else

Can't we just redo them every time exit policy changes from reject to something? fine by me. open a flyspray, due 0.2.2.x? (in theory, we should probably redo them when the IP changes. This could mean Laptop user in a new environment)

[Automatically added by flyspray2trac: Operating System: All]

to

hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit traffic, and still do DNS tests. Isn't that supposed to be different? i've had a todo item for nick to not do dns tests if reject :. he didn't want to put it in, though. i think that you would need to remember whether you did them, and if not launch them, if exit policy changes from reject * to something else Can't we just redo them every time exit policy changes from reject to something? fine by me. open a flyspray, due 0.2.2.x? (in theory, we should probably redo them when the IP changes. This could mean Laptop user in a new environment)

[Automatically added by flyspray2trac: Operating System: All]
Keywords: N/A deleted, easy added

DNS tests are cheap for relays.

If a relay becomes an exit, and it has never performed DNS testing, it can't test DNS quickly enough - it will inevitably upload a descriptor that may need revision very soon after. So disabling DNS testing for non-exits will definitely result in extra descriptor churn.

If you're not disabling DNS checking for non-exits there's not much benefit to checking it when they become exits - unless ISPs are changing their hijacking policies every day.

Tor already performs DNS checking again when your IP changes.

It's hard to see the defect here - any 'fix' is to the detriment of Tor's network load and a few DNS queries every 12-24 hours cannot be hurting non-exits.

Resolve as 'wontfix'?

I'm not sure what we'd gain by refraining from doing the DNS tests, other than meeting somebody's notion of packet parsimony. Based on what others think, we could either close this as "wontfix" or remove it from the 0.2.2.x-final milestone.

arma, thoughts?

I think the original motivation here was that some people said that some people running non-exit relays wanted to be able to do no DNS lookups at all. (Note that I'm not sure that anybody actually said "I don't want to have to do any DNS lookups"; I only remember people saying "probably some people don't want to have to do any DNS lookups.")

I am one of the somebodys that Nick talks about. I run some non-exit relays and don't want to be doing the dns spray, for no reason, every time they start up. Not a huge deal though.

(Do bridges test dns too? I think they do. They might like not harrassing their network admins with needless things that show up in the admin logs.)

The other reason is that every so often we get a user who shows up and is confused about what he sees on his network. Those users have been pretty infrequent lately though (that or I'm never on IRC anymore to find them :( ).

Triage: no need to let this block 0.2.2.x

Changed the title of the bug to better reflect the actual requested change.

If we do this, we should probably have some code to avoid publishing our server descriptor until DNS tests have had time to run for a little while. I think we should kick this whole business into 0.2.3.x; it seems a little error-prone, fussy, and time-consuming to test. (Moving to 0.2.3; please move back if I'm wrong.)

Trac:
Summary: Redo DNS tests to Redo DNS tests when exit policy changes from reject *; avoid when policy changes to reject *
Milestone: Tor: 0.2.2.x-final to Tor: 0.2.3.x-final
Version: 0.2.1.13-alpha to Tor: post 0.1.2.x
Component: Tor Client to Tor Relay

0.2.3.x sounds fine. We should also make sure that we're actually testing all dns servers we would use, and if only one of them is broken avoid using that and pick the others.

Trac:
Points: N/A to N/A

These tests regularly cause user confusion. Today another user turned up on #tor worried that they'd some how configured something wrong despite their reject : exit policy.

Even a log message at level notice might help.

Trac:
Username: murble
Pointsdone: N/A to N/A
Actualpoints: N/A to N/A
Actualpointsdone: N/A to N/A

I'm currently doing work to more clearly display exit vs nonexit connections and this threw me off for a while too. I'm modifying arm's ui a bit to avoid user confusion but it's still weird seeing Tor make persistent connections to the dns resolvers when exiting isn't allowed.

Ack, forgot about this ticket and got tripped up on it again. It doesn't add anything new, but here's a related item: https://trac.torproject.org/projects/tor/ticket/2787

Another related ticket: https://trac.torproject.org/projects/tor/ticket/2793

Trac:
Milestone: Tor: 0.2.3.x-final to Tor: unspecified

Trac:
Keywords: easy deleted, easy tor-relay added

Trac:
Component: Tor Relay to Tor

Trac:
Cc: Sebastian,arma,nickm to Sebastian, arma, nickm
Status: new to needs_review

Trac:
refusednsfornonexits.patch

Redo DNS tests when exit policy changes from reject ; avoid when policy changes to reject

Child items 0

Activity