David, On Thu, 2008-10-23 at 09:14 -0700, David Conrad wrote:
This does not scale.
True, however it does scale for TLDs.
I disagree, for my own (admittedly lazy) sysadmin standards. Right now, one needs: * SE keys, pulled from their WWW site, plus you need to subscribe to a mailing list to get announcements about key rollovers. * RIPE keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list; which is the same as the SE list now thankfully. (Okay, RIPE is not a TLD, but I consider the DNSSEC-secured reverse tree to be at an equivalent level.) * BR keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list. * PR keys, pulled from their WWW site (not SSL secured, but oh well). There is a link for a mailing list, but the page wasn't working when I tried (reported, surely just a temporary error). * CZ keys, pulled from their WWW site, plus you need to subscribe to the appropriate mailing list. * BG keys, pulled from... the Unbound setup? (Sorry, I could not find they trust anchor information online, nor a mailing list. Possibly only in Bulgarian?) At least, this is how I think one has to do this "properly" (instead of just looking for keys in the TLD servers). This is already a lot of work, really. If you use DLV, you can remove the work for BR and CZ from this list (and hopefully more soon), *plus* get a lot of records for unsigned TLDs.
FWIW, on my laptop, I have a really simple cronjob that fetches the root zone trust anchor from IANA's testbed and HUPs the server. However, I won't actually care about the ITAR itself, since I slave the root zone on my laptop and the IANA DNSSEC testbed root zone has all the TLD trust anchors to date and will continue to do so. The ITAR could, of course be fetched instead of the root zone trust anchor if you don't happen to trust IANA's generation of the root zone in its DNSSEC testbed.
Nice! At least for the TLD space. :) -- Shane