DNSSEC Lookaside Validation (DLV) IANA Registry
draft-weiler-dnssec-dlv-iana-00

The following issue realted to draft-weiler-dnssec-dlv-iana was raised by Olaf Gudmundsson from the DNS Directorate and seems to deserve being DISCUSS-ed:

The second document makes silently an assumption that I'm not sure is valid that the root zone will remain unsigned for a while. While signed root is some time off the main point of this proposal is to give legitimacy to DLV operation. Rather than having a IANA DLV I would suggest that IANA publish a PGP signed file listing all DS records their children have and any DLV operators can include that file in their DLV trees.
At least the DLV operation should not continue once IANA zones are all signed.

The following are a few comments from the DNS Directorate:

There are uses of language in the draft that make me uncomfortable,

 o Quote from section 2:

     DNSSEC Lookaside Validation allows a set of domains, called "DLV
     domains", to publish secure entry points for zones that are not their
     own children.

   "Domains" do not publish anything, they are a means of publication.

 o The draft mixes "resolver" and "validator" more than we usually do today.

 o In sections 4 and 5 the draft mentions queries as the subject of validation,
   where that should be responses.

 o The use of "zone" vs. "domain", although appearingly carefully chosen,
   doesn't feel right in some of the cases. I'd need a bit more time (than I
   have now) to validate this and give concrete examples/suggestions.

 o And, of course, my favourite nit: s/RRset/RRSet/g;

Two higher level comments:

1) The method of locating a DLV RR suggested in this draft is climbing
   the tree leaves to root (where the tree climbing alone gives us hard times
   e.g. in DKIM, but let's assume it is reasonabel in this exceptional case),
   but other directions have been proposed.  This kind of competition has
   always confused me, but now this draft seems to be in agreement with
   ISC's <http://www.isc.org/pubs/tn/isc-tn-2006-1.html>.  Still a caveat
   more prominent than the reference to [INI1999-19] might be necessary here,
   since the validator's walking direction will influence the result.

2) The second DLV document -- and I share all the concerns and reservations
   raised during our meeting -- suggests a "TLD only" DLV registry. This
   would depend heavily on the resolvers (well, validators) to make use of
   aggressive negative caching, since there's no other way to signal
   "only TLDs served here".

  The dlv-iana document raises a big issue that came out in the IETF
  Last Call: Given the MOU with IANA, the IETF should not be asking
  IANA to take this action.
  
  I suggest that the IAB needs to be part of the discussion to determine
  the best way forward with the dlv-iana document.

  If the documents are placed on separate ballots, I see no problem with
  approving the dnssec-dlv document as an Informational RFC.

[The first part of this is basically a rant.  At the end I will get to an actioanble statement,
I promise!]

I have no problems with the technical content of dnssec-dlv.  Accelerating dnssec deployment
while reducing the number of trust anchors that needs to be maintained is a laudable goal,
and the document deserves to be published.  I am a bit worried about unintended
consequences, though.  I would probably be comfortable with dlv-iana, but am very nervous
about the alternatives if another organization ends up signing DLVs for the root and
top-level domains.

Issue #1
Will DLVs delay or accelerate signing the root zone?  A signed root is certainly
perferable to a set of DLVs.  I personally can't decide if this would make a signed
root seem unnecessary, or if it would encourage signing the root to ensure
continued relevance!

Issue #2
What performance impact is expected from DLVs?  If the performance impact is too great,
this could become yet another impediment to deployment.

Issue #3
Selection of the DLV signer for top level domains is an important but tricky issue.  IANA
has the relationships and procedures in place that are needed for a secure foundation,
but this may be out of scope.  If another organization provides this service, they become
a competitive source of authority for the DNS, and that is very ugly!

The actionable part of the discuss: I believe that the dnssec-dlv should more clearly state that
DLVs are an interim measure and that the normal dnsssec delegation chain is the preferred
mechanism.  *If* my worries about performance are realistic, the draft should note these
problems and describe how to mitigate them.