Important announcement for our DNS over HTTPS service users:
We will stop supporting HTTP/1.1 DoH requests soon and support HTTP/2 DoH requests only.
Expect this to happen as soon as dnsdist version 1.9.3 reaches FreeBSD package repos.
We see unusually high DNS timeout rates on our tor exit relays since 2024-03-31 and we confirmed this is not a local issue by comparing graphs with a fellow large scale tor exit relay operator.
make sure to have a look at tor_relay_exit_dns_error_total{reason="tor_timeout"}
If you are wondering why our tor relays run an old tor version from March 2023:
According to the Tor Project's debian repo maintainer the build pipeline produces segfaults and the upstream source fails to build.
We do not know when this situation will be resolved.
Are there any legitimate reasons why default tor clients would directly connect to non-guard exit relays? We are collecting such corner cases. If there are no known reasons we might have an easier time dealing with the ongoing CPU load on our tor exit relays.
according to the snowflake proxy IP lists by https://t.co/8zNyHcIcjT
the second largest snowflake proxy population is inside Iran? Is @torproject also distributing them to users?
DE: 259k snowflake proxy IPs
IR: 212k
US: 45k
...
CN: 3k
Our DNS provider @desec_io got DDoSed again..
they significantly improved their communications.
We are pledging 100โฌ towards their AXFR support so we can add redundancy.
Please consider supporting them as well if you use their services.
https://t.co/KgliemubXi
Unusually high new outbound connection rates at our tor exits forced us to shutdown two tor instances due to CPU load. High outbound connection rates are actually hard to defend if it isn't a single destination IP because current tor doesn't provide any mitigating options.
deSEC does not support AXFR yet, so the idea to add a second DNS provider will not be implemented just yet.
In the meantime we increased our TTL values (from 1 to 12h) to have caches for a longer time period when under attack.
The root cause for the partial outage (especially europe) was a DDoS attack against our DNS provider @desec_io.
We will try to add a secondary DNS provider to increase redundancy.
Our monitoring notified us about DNS issues with our domains starting at 2023-01-22 09:54 UTC.
Looks like there is an issue at our DNS provider
@desec_io
but we can not email them currently because their domain appears also affected.
Our tor exits should not be affected.
Our monitoring notified us about DNS issues with our domains starting at 2023-01-22 09:54 UTC.
Looks like there is an issue at our DNS provider
@desec_io
but we can not email them currently because their domain appears also affected.
Our tor exits should not be affected.
Thank you @powerdns for your generous bug bounty reward (2300โฌ) for reporting a weakness in PowerDNS Recursor 4.8.0 CVE-2023-22617
https://t.co/RxAThHYxTS
we are making some progress in dealing with the CPU load on our tor exit relays, but we are well aware that under the current circumstances this is a loosing battle.
Anyway, our server hasn't seen such a low system load for a while... since 23:00 we are testing some new defenses
We have a better understanding on the Tor exit CPU load issue now: when load increases the rate of incoming OR connections also increases significantly while the number of total open incoming OR connections decreases. This is especially bad on systems with multiple tor processes
We had an outage of our encrypted DNS resolver service today between 2022-10-14 01:16:51 and 08:22:42 UTC.
We will follow up with a short post-mortem write up and how we will prevent this particular root cause in the future.
your recursive resolver supports opportunistic DNS over TLS to authoritative nameservers.
If you use our DoT/DoH resolvers you are covered.
https://t.co/3qWw1FuEPe
Thanks to https://t.co/3nBgGYVPFk - our authoritative DNS service provider - you can now query our domains without producing any plaintext DNS traffic on the internet, if your client uses an encrypted DNS protocol and...