In the IESG's last call on this document, there was a request to evaluate whether
the publication of this document is in the community's best interest and, if so,
whether it should be direction to IANA or advice to IANA on what to do if
it were to deploy a DLV. After reading the document, I do not believe it has
sufficient detail to be advice to IANA. This is the meat of this very short document:
2. IANA Considerations
IANA is asked to create a DLV registry at dlv.dnssec.arpa targeting
the root and containing DLV records for those TLDs and reverse zones
delegated directly by IANA that ask to have DLV records published for
their own zones.
IANA is instructed to use its own best practices for authenticating
zone operators' requests to insert, modify, and delete DLV entries.
This DLV registry MUST itself be signed with DNSSEC.
To be clear, IANA is only being asked to publish DLV records for top
level domains and reverse zones delegated directly from IANA, thereby
taking advantage of the IANA's existing relationships with the these
zone operations and established procedures for authenticating
requests from these zone operators.
The other three numbered sections are the introduction, the security
considerations (which state it inherits them from weiler-dnssec-dlv),
and the references. As advice goes, it isn't much. It is also pretty
clearly a request to IANA to set up a particular DLV, and I do not
see how the IESG can treat it as
(b) These are the things that IANA would need to do to
implement DLV, and IANA should follow them if DLV is
deployed at some time in the future.
without essentially rejecting it and indicating to the author that
a re-write of a specific form would get sponsorship. Even in that
case, though, I believe that a re-write would need a new last call,
since it would have to be significantly different from this
document to be worth it.
To take a single example of what might be advice in such
a document, draft-arends-dnsext-dlvptr-00.txt proposes an extension
to the DLV mechanism that allows a zone holder to enter a record
naming which DLV is the repository of choice. If draft-arends-dnsext-dlvptr-00.txt is accepted, then it might be
reasonable to advise IANA, should it decide to set up a DLV, to
ensure that the salient dlvptr records point to its DLV. Of course,
this would be useful advice to anyone setting up a DLV, and the
advice would likely need to be updated as new mechanisms are added
and experience with DLVs gained. Having a working group like DNSOP
develop that over time seems like a reasonable thing to do if
we do get stuck with DLVs, but I doubt that there is sufficient
operational experience at this time to do so.
To put this more bluntly, I think b) should be off the
table for this document.
On the remaining question, should the IESG approve this
document as:
(a) These are the things that IANA would need to do to
implement DLV, and the IETF is in favor of IANA doing
them.
I think even that is an inaccurate reflection of this document.
"Should the IETF instruct the IANA to set up this registry?" would
be a closer reading, at least in my opinion. My answer to that
question is no.
There are two reasons for that. The first is that I strongly
prefer a signed root, and I believe that a success in the use of
DLV at this level would distract from, rather than lead the way to,
a signed root. DLV as a success here would be difficult to get out
of the DNS system once deployed (at least if cruft in any other
aspect of the Internet is any guide), and the more "official" it
appears to be, the worse that removal process will get (at least if
I read the tea leaves right this morning).
The second is that these instructions essentially
force the use of at least two DLVs. Because these instructions limit
the included zones to those in the root, the DLV created by these
will not handle any other missing links in the chains of trust. This
has already been pointed out by Mark Andrews, relative to the ISC
DLV, but it warrants repeating: doing this might create an ersatz
signed root (and I emphasize ersatz here), but that does not solve
the problem for zones within TLDs that are not signed. A single
DLV is plenty bad enough; having multiple DLVs without some real
design work looks to me like a potential disaster.
Speaking only for myself,
Ted Hardie
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf