Re: [tor-bugs] #28458 [Core Tor/sbws]: Stop resolving domains locally and stop using non-exits as 2nd hop

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28458: Stop resolving domains locally and stop using non-exits as 2nd hop
---------------------------+------------------------------
 Reporter:  juga           |          Owner:  juga
     Type:  defect         |         Status:  needs_review
 Priority:  Medium         |      Milestone:
Component:  Core Tor/sbws  |        Version:  sbws: 1.0.0
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+------------------------------

Comment (by teor):

 Replying to [comment:2 pastly]:
 > > sbws is trying to resolve the domain locally, which fails in many
 cases.
 >
 > Really? That seems like a problem. Is the system's resolver having
 issues? Should sbws cache good results it gets back?

 If the system resolver can't answer DNS queries, then the operator should
 install a caching / recursive local resolver. See #28461.

 sbws *could* cache results, but a proper DNS resolver is going to be
 better at DNS than any sbws code we can write.

 > >  Even if it does not fail, the IP obtained won't be the same IP to
 which the exit will make the HTTP request.
 >
 > This **could** be the case, but isn't necessarily the case. For simple
 destinations (simple like a single webserver as opposed to complex like a
 CDN) it's most likely **not** the case that the IPs will be different.

 Even if the IP address is different, the content should be the same: only
 the latency would vary.

 > So if we are trying to measure an exit and DNS fails, we treat the exit
 as a non-exit and find an exit to help measure it. This may not be ideal,
 but it works.

 What happens if sbws gets END_REASON_EXITPOLICY from the exit?
 (END_REASON_EXITPOLICY is the response when an exit's policy won't allow
 the IP address that the exit resolved.)

 This can happen because:
 * the exit has just changed its policy, and sbws has an old version
 * the exit resolves a different IP address from sbws

 I think we should measure the relay as a non-exit in this case.

 What happens if the exit can't connect because the connection is refused,
 or times out?

 This can happen because:
 * the exit is busy
 * the exit is censored
 * the remote site is down

 I think we should measure the relay as a non-exit in this case.

 We could cover all these cases by choosing to measure exits as non-exit
 relays at random. About half the time would work.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28458#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs