i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude. as i was exiting the room, i heard sam weiler at the Q&A mic repeating his prior comments as to how ISC should not be a DLV registry, and i saw mark kosters in line at another mic probably as a followup to my followup to his earlier question. i apologize for the length of this note, and for the fact that it says more about DNS bits and kibble than anybody really ever wanted to know, and also for my rudeness in attending joao's talk without having registered for nanog. first, sam weiler's question. let me answer, here on the mailing list where rudeness is an art form, that ISC intends to follow through on DLV. while we solicited (and got!) much design input (from sam weiler among others including david conrad who gave me the idea for DLV in the first place), ISC holds "change control". this isn't an IETF effort. just a cooperative based on some source code. both the source code (bind9.3 and bind9.4) and the DLV specification are completely forkable in the BSD tradition-- anyone else who wants to do this differently is welcome to any of the ideas or code ISC has published. and if someone else with similar resources and similar trust tells me that they are going to run a DLV registry (starting immediately-- ours is open NOW) then we would possibly re-evaluate the need to do a DLV registry inside ISC. none of that appears likely. to me, continued nondeployment of dnssec is what seems likely, seasoned with periodic 11th hour "oh no, the secure dns spec isn't done, let's re-open all the issues we thought were closed" parties. sam also wanted to know how ISC planned to verify zone ownership for the purpose of knowing whether or not we should accept a proferred key for, say, "bankofamerica.com". i think sam also echoed randy bush's earlier concern as to how we would secure our DLV registry against data loss, hacking, and so on. joao damas already answered those, and he's the programme manager for DLV, so we can all trust his answers. so i've heard sam's comments before, and had i actually registered for nanog i would surely have answered them as i've answered before, and now you all know what i would have said. second, mark kosters' additional question. i have no idea what mark kosters' additional question was, but if it had to do with my followup to his previous question, it was probably "what's the real difference, if any, between a TLD registry putting their key in ISC's DLV registry vs. running a DLV registry themselves?" if so, then i'm glad he asked, it's a favorite topic of mine. if a TLD registry (such as mark kosters' employer, verisign, for "COM" and some other TLDs) wants to sign their zone but their desire is irrelevant because the root zone is not yet signed, then they could meet some of the same requirements by sending ISC a DLV RR. their customers (VIX.COM in my case) would not have to do anything special -- we could just sign our zones and send our keys to our registrar (alice's registry in my case) who would then forward them to the TLD registry via some proposed EPP extensions. this is the best case scenario since there's only one key held by DLV, which is the one for COM, and once IANA gets around to signing the root zone, the only change will be that verisign will send its COM key to IANA rather than to ISC. no registrar or registrant ("zone holder") would have to know or make any changes to their software or procedures. if on the other hand a TLD registry (such as verisign) was not planning, for reasons such as subdomain enumeration or size-of-metadata (both of which are proposed to be solved by NSEC3, now in early preproduction), to sign their TLD (for example, COM), then that registry would have no key to send to IANA (if the root was signed) or to ISC for the DLV registry (if the root remains unsigned, as appears likely for the near term.) in this less-than-best case, registrars could send ISC blocks of registrant keys for the DLV registry, or registrants could send ISC zone keys directly. the reason this is less-than-best is that ISC would have to verify zone ownership before publishing a zone's key, unless we can get registrars to do this for us and send us blocks of keys). since we aren't charging any fees for DLV registrations, we're currently putting the burden of proof of zone ownership on the zone owners. (they have to contact joao damas or come to ISC's main office and present credentials, ideally using strong-chain PGP.) there is some question in my mind as to why a TLD registry would choose to run a DLV registry rooted at their TLD, rather than just signing their TLD. perhaps it's because DLV, even as ugly as it is, avoids the same subdomain enumeration ("zone walking") and metadata-size problems that NSEC3 avoids, but DLV is in its late stages whereas NSEC3 is in its early stages. or perhaps a TLD registry might not want to see other companies, even 501(c)(3) public benefit companies like ISC, carrying data for their registrants or having direct relationships with their registrants and registrars. i dunno. but to now repeat my earlier answer with this additional context: if every TLD registry wants to run its own DLV registry, then the world's validator population will probably experience "cut and paste fatigue". there are about 250 TLD's, and there are potentially many millions of validators. if one TLD per month needs to update its static DLV validation key, that's a whole lot of cutting and pasting that'll never happen after month 2 or so. that's why a clearinghouse, such as IANA for the root zone as called for in the dnssec-bis specification, or ISC's DLV registry until the root zone is signed, is necessary. ISC's actions in undertaking this without sharing change control in the usual IETF way have been called controversial. my advice to those of you who think we are doing the wrong thing is, pick one of the following and execute: 1. figure out why the root zone isn't signed and fix whatever it is. 2. design your own version of DLV (as sam weiler has done, long before ISC's although i didn't learn this until later), publish it, and urge adoption (find someone to run a DLV registry, implement the validator side, and so on.) 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code for the validator side, start your own DLV registry. 4. go to IETF and say "i think something DLV should be a standard but i don't like ISC's, so let's make an RFC together." what you should note in common with all of these things is that ISC could never prevent alternatives from coming into existence (nor would we wish to), and indeed all of our work on DLV is directly forkable/leveragable by any alternative effort, even potentially proprietary or commercial ones. so, go for it! (my concern is, DLV is an evolutionary dead end, a deployment aid, and pissing away even more time and money on it seems like a waste of time compared to finishing NSEC3, signing the root, y'know, important stuff.)