[tor-relays] General overload -> DNS timeouts

Tue Nov 9 11:25:31 UTC 2021

Hello all, 

I would have to agree on this it appears that the DNS failure timeout is
too low. I have more then enough bandwidth to host tor exit nodes, and
my own unbound full recursive relay and yet i still get the timeout
message 1-1.5%. Sometimes even weird amounts such as 40-50%. 

I have been working with a few people on this issue and nothing we have
tried has fixed this. The other thing is that all other servers i run
have no issue with DNS timeouts. It appears to only be a TOR issue. I
would even say that some DNS queries that TOR makes are to taken down
sites, fake sites or non-existent domains.

Thanks,
John C.
+1 (216) XXX-XXXX 

On 2021-11-08 06:25 PM, Anders Trier Olesen wrote:

> Hi Ibex 
> 
> There's some discussion about this issue on #tor-relays. First of all, I actually don't think there's any problem with your Exit node. IMO 1.5% is expected and the current threshold is just too low (or the timeout too low). 
> 
> We're hosting some fairly high capacity exit nodes (around 100mbit/s each), generating about 100 DNS queries/sec in total. We're also seeing around 1.5% failed DNS queries. 
> 
> Here's what I think is going on: 
> For some queries (1.5%?), the authoritative DNS servers for the requested domain are not responding. Recursive DNS resolvers are by default more patient than the Tor software. Eventually the recursive resolver will return a 'SERVFAIL' to Tor, but by then, Tor has already given up, and counts it as a timeout. 
> 
> One example of a domain that is currently (2021-11-08T23:40+01:00) failing to resolve because of its authoritative DNS servers being down is mzfgbh.com [2]. Try running `dig +trace +additional mzfgbh.com [2]` (for some reason, dig ignores the 'additional' section of one of the answers. Essentially the problem is that this query (and a few others) times out: `dig mzfgbh.com [2] @1.1.1.20 [3]`). 
> 
> On a related note, when this metric was introduced, we were seeing around 5-6% failed queries. The recursive DNS resolver we were using was hosted on the same IP as a guard node. Apparently many authoritative DNS servers block traffic from all Tor relays! 
> 
> The most extreme example of this I found, is that the authoritative DNS servers for the entire .by ccTLD (Belarus) are blocking DNS requests from guard and exit nodes. This resulted in all <domain>.by queries timing out! 
> 
> By moving our recursive DNS resolver to an IP not used by any Tor relays, the DNS timeouts fraction reported by Tor dropped from 5-6% to 1.5%. 
> 
> The Tor relay guide should recommend running your recursive resolver (unbound) on a different IP than your exit: https://community.torproject.org/relay/setup/exit/ 
> 
> - Anders Trier Olesen 
> 
> On Sat, Nov 6, 2021 at 5:53 PM Intrepid Ibex via tor-relays <tor-relays at lists.torproject.org> wrote: 
> 
>> Hi everybody, 
>> 
>> I am new to tor (as server operator) and try to support the network by operating an exit node.  
>> 
>> Machine is running Ubuntu 20.04 - Tor 0.4.6.8.  
>> 
>> nyx is giving me a notive every 10 minutes or so: [NOTICE] General overload -> DNS timeouts (6) fraction 1.4742% is above threshold of 1.0000% 
>> 
>> DNS on this machine however works perfectly. I told my tor browser to use my specific exit node, everything works fine. 
>> 
>> Node is running since 4 days now. Load is as expected. 
>> 
>> Thanks in advance for any help! 
>> 
>> Ibex 
>> 
>> -- 
>> Sent using MsgSafe.io [1]'s Free Plan 
>> Private, encrypted, online communication 
>> For everyone. www.msgsafe.io [1] _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Links:
------
[1]
https:/www.msgsafe.io/?utm_source=msgsafe&utm_medium=email&utm_campaign=freemailsignature
[2] http://mzfgbh.com
[3] http://1.1.1.20
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20211109/6416b20a/attachment.htm>