DNSSEC Lookaside Validation (DLV) IANA Registry
Summary: Needs a YES.
(Ron Bonica) (was No Record, Discuss) Discuss
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".
Supporting Russ's discuss. IANA should not maintain this registry.
(Russ Housley) (was Yes) Discuss
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.
(Tim Polk) Discuss
[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.
(Dan Romascanu) Discuss
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.
This issue was raised by Olaf Gudmundsson from the DNS Directorate, wrt. draft-weiler-dnssec-dlv: there is one issue that keeps nagging at me as a BAD thing. I'm talking about the "aggressive negative caching behavior". I think the same effect can be accomplished without any protocol change by allowing the validating resolvers to have a copy of the DLV zone, in that case the normal name lookup algorithm is used not some special resolver addition. This will also reduce the lookup times, but the operational aspects of this are many and require some thought.
(Jari Arkko) No Objection
I agree with the Discusses and Comments.
(Ross Callon) No Objection
(Lars Eggert) No Objection
(Sam Hartman) No Objection
I support publication of the base DLV spec. I have concerns about dlv-iana.