Opened 8 years ago

Closed 4 years ago

#965 closed defect (fixed)

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

Reported by: Sebastian Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: post 0.1.2.x
Severity: Keywords: easy tor-relay
Cc: Sebastian, arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

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?
<armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn't
want to put it in, though.
<armadev> 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?

<armadev> 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]

Child Tickets

Attachments (1)

refusednsfornonexits.patch (640 bytes) - added by mttp 4 years ago.
replacing a previous version of this patch that had a syntax err

Download all attachments as: .zip

Change History (19)

comment:1 Changed 7 years ago by nickm

Milestone: post 0.2.1.xTor: 0.2.2.x-final

comment:2 Changed 7 years ago by nickm

Description: modified (diff)
Keywords: easy added

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

comment:3 Changed 7 years ago by mwenge

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'?

comment:4 Changed 7 years ago by nickm

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?

comment:5 Changed 7 years ago by nickm

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.")

comment:6 Changed 7 years ago by arma

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

comment:7 Changed 7 years ago by arma

Triage: no need to let this block 0.2.2.x

comment:8 Changed 7 years ago by nickm

Component: Tor ClientTor Relay
Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final
Summary: Redo DNS testsRedo DNS tests when exit policy changes from reject *; avoid when policy changes to reject *
Version: 0.2.1.13-alphaTor: post 0.1.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.)

comment:9 Changed 7 years ago by Sebastian

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.

comment:10 Changed 7 years ago by murble

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.

comment:11 Changed 7 years ago by atagar

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.

comment:12 Changed 6 years ago by atagar

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

comment:14 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:15 Changed 5 years ago by nickm

Keywords: tor-relay added

comment:16 Changed 5 years ago by nickm

Component: Tor RelayTor

comment:17 Changed 4 years ago by mttp

Cc: Sebastian,arma,nickmSebastian, arma, nickm
Status: newneeds_review

Changed 4 years ago by mttp

Attachment: refusednsfornonexits.patch added

replacing a previous version of this patch that had a syntax err

comment:18 Changed 4 years ago by nickm

Resolution: Nonefixed
Status: needs_reviewclosed

Thanks! I tweaked this a little, wrote a changes file, and checked it into master as 1753975ece98f4054ec65683862db120a3b8f261

Note: See TracTickets for help on using tickets.