On a Debian Jessie system with `tor` installed from `jessie-backports` (currently 0.2.7.6-1~bpo8+1), if I: * enable Tor's sandboxing, and * empty `/etc/resolv.conf`, and * restart Tor to make it bootstrap again, then I can see Tor doing nothing for exactly 10 seconds even before reporting `Bootstrapped 0%`. In the debug log I see: ``` Mar 14 19:30:20.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Mar 14 19:30:20.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Mar 14 19:30:20.000 [info] crypto_global_init(): NOT using OpenSSL engine support. Mar 14 19:30:20.000 [info] evaluate_evp_for_aes(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it. Mar 14 19:30:20.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded. Mar 14 19:30:30.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed. Mar 14 19:30:30.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded. Mar 14 19:30:30.000 [notice] Bootstrapped 0%: Starting ``` As you can see there is an exact 10 second delay for the second call of `sandbox_getaddrinfo()`. Either using a "normal" system DNS resolver, or disabling Tor's sandboxing removes this delay. I say "normal" system DNS resolver, because using Tor's `DNSPort` doesn't work, as expected, but actually it makes the situation worse by increasing the delay to 20 seconds for some reason. I imagine this is quite a common use case for the `DNSPort` option. For the record, this Tor bootstrap delay affects every boot of Tails (probably since we enabled Tor's sandboxing in Tails 1.2, 1½ years ago) and we have [our own ticket](https://labs.riseup.net/code/issues/10238) but it tracks other unrelated Tor bootstrapping issues as well.