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:
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.
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.
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.