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