johnhtodd

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