johnhtodd

I will say that Vidmar, Lista, and Rousseau make thin drawer cabinets that work well for cables if you have graduated from "big box of cables" to "cabinets full of cables". Also, old map or blueprint drawers work well. Still requires obsessive coiling, but being able to see (semi-random access) all of them in a drawer all at once is a big speed improvement for searches.

This place was amazing, and worth a whole afternoon every time I went there. The owner was even more interesting, and a whole story in his own right. (I just looked at his wikipedia entry- wasn't aware there have been features on him! https://en.wikipedia.org/wiki/Ed_Grothus)

He was not just an interesting person, but had a fantastic memory for what was in the place (though I think that was quite selective.) I came in one day looking for an aluminum plate I could use as a heatsink, but I was hoping for something with rounded edges so it wouldn't cut my car seat (for my overly-hot laptop.) He squinted for a few seconds, and then walked directly to a giant pile of random metal debris, and threw a bunch of things aside, reached in up to his shoulder, and pulled out _exactly_ the piece I needed, including chamfered edges on one side.

I am sad places like this are going away quickly. I made a map a long time ago dedicated to documenting places like The Black Hole - scraphounds are welcome to update it with interesting destinations. https://www.google.com/maps/d/u/0/edit?hl=en&mid=1Y1XmPsqClK...

No, canaries in our opinion are not a particularly good idea for a variety of reasons. We have not received any requests/demands for information in 2026 - we'll try to update the page to reflect that this is no longer a quarterly update.

This is an area that is fraught with challenges. Serving a truly global audience means standards are difficult to measure as to what is "adult content" - it varies widely (Wikipedia in some areas is "adult content", as an example.)

In the near term, there is no filter set that we offer that mimics that functionality.

However, we recognize some variation of "best effort" adult content segmentation is a useful filter to have. We're considering it in the near term, as we have some specific educational institutional pressure to try to meet as well, since students are often easy targets for phishing, classroom computers are rife with malware, and there is also the problem of inappropriate DNS-based profiling of students and schools - problems that Quad9 can help solve.

We actually quite like DOQ and DOH3, both of which use QUIC.

All modern Apple systems use QUIC. For instance if given 9.9.9.9 via DHCP they will automatically upgrade to encryption via DDR, then then upgrade to DOH3 with no intervention by the end user. We find that encryption load is lower with QUIC-based transports, but we need to really get a formal research paper together on that "in our spare time."

Faster? Probably, but is it measurably "better" remains a question for others to answer. Due to parallelism in most query sets, minor wins with DNS latency matter less than you might think.

Our goal is not "insulation" as much as it is "transparency." Governments that do not adhere to legal frameworks like the ones you reference above are also governments that have inconsistent or easily-changed legal structures - we are not hiding in some obscure and possibly unstable nation that ignores international standards. Our jurisdictional choice of Switzerland is the opposite of that. Switzerland has a strong history of making legal enforcement events transparent, with processes that follow expected process. We cannot avoid following the law, nor is that our goal.

Swiss data privacy law is also much more strict on us, which "puts our money where out mouth is" as the saying goes. Violating privacy laws in Switzerland may result in criminal penalties, not simply civil penalties - jail time, rather than just fines.

Cost and staff time to pursue were not significantly higher than the return. We just want to help people with security and privacy and do DNS stuff - this legal fighting is absurd and misplaced and a spectacular waste of time, but here we are.

What's even worse: the court fined us because they claimed this use case was in some way in contempt of their ruling. Then, when we won the overall case, that money was never returned because it wasn't specifically referenced by the final court. The response from the lower court was effectively: "Well, you will need to sue the court to get that money back." <table flip>

Edit: I'm with Quad9 (CTO)

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/)

I am constantly amazed that people rely on anyone else's compute infrastructure for things like doorbells, cameras, locks, switches, or sensors (network infrastructure is, at the moment, a seemingly acceptable integration for isolated communication.) There is inevitable over-pricing and capture by these companies; it's in their nature.

Add to this the security and downtime risks, and the equation really doesn't look good. Equipment that is tied to someone else's cloud is an astonishingly bad idea, but everyone has their own immediate (or even long-term) reasons for ignoring advice. "You get what you deserve."

Works sporadically - some sites just have no "copied to clipboard" even after a 3-4 minute delay. However, works enough that it's quite useful to have in the inventory of tools - thanks, random internet link!

I purchased quite a few of those systems when they came out of production and went into the surplus supply chain. I don't recall anything unusual about the cubes with NeXTDimension boards that were in there though. Some had two boards, which was outrageously over-the-top powerful. There were a lot of slabs that were also labelled "NRO", and I bought lots and lots of them. No hard drives, of course. There was a surplus yard in Maryland that had the contracts for the TLAs. Not open to the public, but if you spent enough and brought donuts, you could clamber across the content of that week's 18-wheeler crammed to the top with magical gear coming out of places that had unlimited budgets and fast replacement cycles. It was legendary. I still have a fax machine somewhere in my dusty piles with "Joint Chiefs of Staff - Whitehouse" property tags.

Quad9 employs DNSSEC on all endpoints now. https://quad9.net/news/blog/quad9-enables-dnssec-on-all-serv...

One approach to solving this for a very limited set of intervals is to actually block namespace that has been removed at the registry level. There is a paper on this from Raffaele Sommese:

https://static.sched.com/hosted_files/icann83/5b/Rafaelle%20...

Quad9 (9.9.9.9) consumes this feed from U Twente of "just deleted" names, as most of them are malicious, and blocking them even if they are NOT malicious causes zero harm. Currently, this is only names that are very short-lived, so may not catch the longer intervals where names are deleted and become ghosts.

Another model using something similar would be to specifically clear those "just-deleted" name cached entries out of the recursive resolver, but that is expensive. Also, with blocking instead of removal it is possible to get high-level metrics on how often those are being abused where NXDOMAIN tracking is not measured in the same dimensions.

(disclaimer: I work for Quad9)

This is conflating BGP routes and DNS.

DNS data: Root server data is available via AXFR ("dig . AXFR @f.root-servers.net") but this isn't what you're referencing.

Second level TLD server data is available is available at CZDS. (https://czds.icann.org/home) but some TLDs don't participate, but this also isn't what you're referencing.

What I think you want: There is no canonical list of all zones that exist - there is no "central repository" once you pass the root zone downwards - that's a feature, not a bug. Some organizations have partial views based on large recursive resolver data (DomainTools, Google, Cisco, Cloudflare, Quad9) but access to that data is limited to vetted researchers or more typically only available at a cost (disclaimer: I work for Quad9.) Smaller versions of recursive data sets exist, but are usually significantly limited by geography and demographics of the user community that generates the data set.

BGP route data: This exists in many forms in realtime like the site referenced above, though historic data is difficult to track. No matter what the source or latency, there is bias in the data set because BGP pathing is unique to each ASN that collects it - no two views of the table are identical, and any data set is as "best guess" at state conditions at that time.

Here are some possible data sets for BGP:

Packet Clearing House (PCH) provides a set of snapshots going back 20+ years (though it seems to be offline at the moment): https://www.pch.net/resources/Routing_Data/

Cymru has a live version you can query via various APIs (including ironically via DNS): https://www.team-cymru.com/ip-asn-mapping

Routeviews from University of Oregon also has a data set that is widely used by researchers: https://www.routeviews.org/routeviews/

This is a great project and I'd use it immediately, but I'm heavily invested in ONVIF devices and have no VISCA-based cameras. Plus, I'm betting that most VISCA devices aren't weatherproof. I know that VISCA has the very nice feature of reporting back current x/y/z parameters, but that can be semi-spoofed with ONVIF by using a grid of presets and then "guessing" based on commands issued. Is that out of the question as a feature for this project? There is a massive installed base of ONVIF devices that could immediately be pulled into use.

Hi - the guy who wrote the blog speaking here - I'm the General Manager for Quad9. You're right - this was done by the team a bit too hastily. However, the document is public as a court filing, try to be as cautious as possible with people's names in online filings. We wanted to keep the PDF as intact as possible so people could cut/paste other parts of it for reference without having to dig up the actual document from the courts, or having to do error-prone OCR work on a PNG.

Interestingly, one of the things I didn't need to see redacted was the name of the domain itself - we publish that in the blog post text. Previously, we'd blocked it out of previous documents in an abundance of caution so that we could not be accused of promotion of the site by an obtuse mis-reading of intention. Everyone here has been working nonstop on this case for a long time, and we'll try to fix this tomorrow after some sleep.

JT