Red bulbs aside

Analysis of DNS persistent error on Tor exit nodes



Starting to develop a tor exit scanner, some exit errors were detected while testing the robustness of the scanner. Then these errors were manually confirmed as DNS error on the exit node level.

Applications using Tor should not perform DNS resolutions themselves, otherwise DNS resolvers would learn to which servers connections are being made [1][2]. It is therefore important that exit nodes provide reliable DNS resolution.

In this context, studying the rate and persistence of such errors on exit nodes sounds interesting. This small opportunistic analysis was lauched.


The scanner has been written to use Onionoo to get a daily up-to-date list of the running exit nodes, to establish a circuit for testing each exit with Stem (the Python controller library for Tor) and to test it with URL and IP requests. The default target was assuming that it should be reachable with any exit node. The test has been completed for all the exits on a daily basis during five days.


Daily test failure

Results shows a daily average of 3,50% errors that seems quite high at first sight. It represents 0.7875% of the total exit probability. If we dig a little bit, we found that errors are very temporary and are rarely repeated on the next day. So it can be a temporary network problem or a scanner artefact (false positive). Studing the error repetition give more information.

Evaluation of persistent DNS test failure

More than 75% of the relays presenting an error on one day will answer correctly on the next days. This rate keep increasing on the next days but relays with error on day 5 will mainly stay in error after that. This represents an exit probability of 0.18%.

Examining the relays with a 5-days error duration leads to listing :


The 10 relays have been reported to As the affected exit probability is low and errors are frequently temporary, we suggest that such a scanner will be executed only with a weekly analysis. There is no need to run it more frequently. Then relays that will appeared in two consecutives analysis will be reported. Bad relays will be excluded from the next analysis.

Further work

Useful links and further readings

Special thanks

to Guinness who have taken time to read this before publication and share their opinion and advices !

Comment ?

Should you have any comment on this page, get in touch !

Back to index
Static Website made thanks to ssg