Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I'm not saying this is a canary, but I think it should be treated as such.
  • Hi - I'm with Quad9 (CTO). I'm going to try to put together a single post replying to some of these topics.

    First: We welcome the Mullvad users who will be shifted onto our systems, and we appreciate that Mullvad contacted us instead of doing this unilaterally. Since we have no signup process, they could have just moved users across but we very much appreciate their cooperation and communication, both with us and with the users of the service - this is exactly how an ideal transfer should go, at least from our perspective.

    I'll try to make some short summaries of some of the points here, and a reply on each.

    "You should just run your own DNS server - it's easy." - Yes, we agree that for a small company or home running your own recursive resolver is a reasonable solution. You probably won't get the threat mitigation depth of service that Quad9 offers, but you may not want that. Privacy also suffers a bit, since it's still the same IP address (your home "public" address) sending queries to authoritative servers, probably unencrypted. A good middle compromise is to run PiHole or AdGuard software, and forward your queries to Quad9 via an encrypted connection. (see below) This mixes your queries in with a large number of other users, and gets the potential improvements of having a much larger active cache nearby which will have "hot" answers. Running a home resolver for yourself or even a few dozen (or even a few hundred) people is not difficult. But with all services, things change with scale. As the query volume and number of locations grow, you soon find yourself hitting all possible exception cases, instantly. Many millions of requests a second requires a lot of time, expertise, and money to ensure nearly 100% uptime. We are admittedly quite a small group - less than 10 full time - but even that is under-staffed for supporting more than 100 million daily users. We do quite a bit with a very small resource set, and I doubt it could be done less expensively with the same robustness for the same scale. Again, we appreciate Mullvad's sponsorship to help keep this expanding at our normal weekly growth rate of around 2%.

    "I want ad blocking, and Quad9 doesn't do that" - Correct, Quad9 does not do ad blocking at this time. There are good solutions like PiHole or AdGuard extensions that provide this functionality, and getting local control and logging of your DNS queries is probably useful for power users. There are also commercial platforms that provide this capability, and they may provide significantly more "knobs" for what you want to block. Quad9 is a non-profit - we're not out to corner the market, and as long as privacy and security is increased for the end user, we're all for commercial solutions!

    "Quad9 blocks domains in Germany" - Currently there are no mandatory blocks that Quad9 is integrating or enforcing on our DNS platform, from any external party. We did briefly block some domains as a result of legal actions against us in Germany. The good news is that we won that case in Germany, after two years and three appeals and an enormous amount of time and money (which despite Germany's "loser pays" rule, is not even close to expenditures.) https://quad9.net/news/blog/quad9-turns-the-sony-case-around... The bad news is that the identical thing is happening now in France where we have a number of legal cases open against Quad9, and we do not see an end to this any time soon as long as there is an open question in the EU about what a content-neutral intermediary is and is not required to do.

    "Mullvad exiting creates more centralization, and that is bad." On the fact that centralization is bad, we agree. DNS resolver centralization is not a great thing, and it seems to be trending in the wrong direction. It's not just large public resolvers - consolidation in the ISP industry is causing more and more of the world's internet-using population to utilize a smaller number of recursive servers. Those servers are operated (mostly) by law-abiding companies, and so there is a strong interest by various parties interested in control of content to "put a hand on the available throat" even though it's the wrong throat to choke. We're busy with some ideas of how to solve this, both from a legal defense position as well as a technology position - stay tuned in the coming months. In the meantime, you can contribute a few euros/francs/dollars to us and we'll have more funds to pay for legal defense in France and hopefully up to the EU courts. https://quad9.net/donate/

    "Government agencies can tap data" - Quad9 is based in Switzerland. Despite what may be common knowledge from movies, there is a very formal and rigorous process for governments (Swiss or non-Swiss) to demand data. It is (ultimately) transparent, and managed in a way that is quite well structured - this is, after all, what the Swiss have been doing with financial data for many years. More importantly: Quad9 stores no user data about queries. There isn't anything to demand - the box of data is quite empty. Because of this technological decision and our wide announcement of it (https://quad9.net/about/transparency-report/) we have never received a request for data. As for technological methods: Quad9 operates in 200+ widely-separated locations, with no backbone or central data transport network - it is intentionally 'islanded'. It would be a significant challenge to intercept data at all those locations, though we're certain that there are many queries that are observed due to their presence on various ISP or cable networks which are under surveillance. We support all major DNS encryption methods today (even the two that run on QUIC - HTTP/3 and DOQ) and we encourage users to use one of those for their communications to us. We are also one of the few major resolvers experimenting with ADOx, which encrypts messages between the recursive resolver and authoritative server. (https://dnsprivacy.org/adox_status_and_deployment/)

  • For awhile I self-hosted adguard dns server. It supports iphone profiles thus forcing iOS DNS. I eventually disabled it due to timeout issues specific to iOS. Issue was something DNSSEC related.

    While reproing the issue I noted the average recursor round trip time from my OVH server hosted in Oregon to the default upstream DNS - Quad9 - was around 70ms. When I changed it to Hurricane Electric the roundtrip dropped to a steady 20ms. Later I changed it again to Cloudflare and the roundtrip was a consistent 2 to 3ms.

  • It's not that I don't trust Quad9 or dns.sb or any of the others, it's just that I trust Mullvad more.

    Sad to see this going away, but I assume this is so Mullvad can focus on their primary services.

  • This feels like a nitpick but it's important to mention anyway

    > Mullvad Browser uses them [ the DoH servers ] by default when you're not on Mullvad VPN, preventing your ISP from seeing the domains you visit.

    This is a half-truth until Encrypted Client Hello (ECH) is in-use for most of your traffic. Sure, you won't have clear-text DNS floating out there in the series of tubes. However, without ECH the hostname you're connecting to is exposed in the SNI field during TLS handshakes.

    I imagine most sites we are browsing will eventually be able to leverage ECH, so this should become less of an issue over time, but in the event you frequent any self-hosted operations (e.g. no Cloudflare or similar), encrypted client hello could still reveal identifying information since it requires still exposing an "outer SNI" that a valid certificate needs to be presented for. You only get to easily hide in with the masses when you use a big infrastructure provider as a consequence, since the common outer SNI of cloudflare-ech.com doesn't really reveal anything different than an IP <-> ASN database would. But if the outer SNI is "dunder-cat-enterprises.com", then all I've protected you from is your ISP snooping on the subdomain or pinpointing exactly which one of my domains you might be talking to.

  • Quad9 is a reasonable choice given the stance on privacy and the similar jurisdiction (Mullvad would probably face the same takedown orders as Quad9), but really anyone who cares about bypassing national blocking orders should run a local caching recursive resolver. Unbound is a great choice.

    Unbound can also be used to block malware and advertising domains using shared public lists, or you can build your own list. Your resolver’s DNS queries could be piped through Mullvad or Tor if you want additional privacy.

  • I'm always wondering whether those centralized privacy services are not the easiest first target for three-letter-agencies to infiltrate to gain access to the most relevant users to track - and what currently would prevent them from doing so if they haven't already ? Maybe, as with the case of many TOR nodes , they might be running them.
  • >We want a public service to be available. Going forward, we will support Quad9 instead of running it ourselves. Running a privacy-focused public DNS service is a highly specialized undertaking, and the Quad9 Foundation is the undisputed leader in the field. Rather than duplicating their efforts to achieve only part of what they do, we're putting those resources toward financially supporting Quad9 instead.

    Brilliant.

Explore Birbla archives