Re: [tor-bugs] #18580 [Core Tor/Tor]: exit relay fails with 'unbound' DNS resolver when lots of requests time-out

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

#18580: exit relay fails with 'unbound' DNS resolver when lots of requests time-out
--------------------------+------------------------------
 Reporter:  Dhalgren      |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.7.6
 Severity:  Major         |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------

Comment (by Dhalgren):

 After coming to understand the issue and tune for it, I created an alarm
 that triggers whenever the output from 'unbound-control dump_requestlist'
 command exceeds 200 entries (400 actually, as two DNS worker threads are
 configured and the command shows only thread 0).  This has been hit twice
 now and today I managed to look at it while the event was still in
 progress.

 This time instead of GoDaddy, the DNS enumeration target was a major
 Australian DNS provider and they, like GoDaddy, blocked DNS etc. traffic
 from the exit node.

 The tuning appears to work as the node continued to be usable with good
 performance when "setconf ExitNodes=<fp>" is applied for testing on a
 client.  I observe a 15% or so drop-off in traffic per the ISP utilization
 graph at the time of the alarm, with full recovery occurrng in about one
 hour.  Hard to say whether the drop-off was the result of a performance
 impact from the DNS abuse or whether it's because the attacker gave up
 using the node just after I started looking--dump_requestlist began
 shrinking rapidly then.

 In any case the node did vastly better than at the time of the original
 attack before the eventdns tuning was applied.  At that time the relay was
 effectively taken down for two days.  That attacker left their abuse-
 program running and didn't notice that GoDaddy had put and end to the
 scan.

 A look at the utilization graph for the earlier alarm incident showed no
 performance impact, but that one occurred during off-peak hours when
 utilization runs significantly lower.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18580#comment:20>
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