I read through the document and had a lot of comments, so maybe I need to "back up a bit."
I'm conflicted over documents that define good operational practices over top of a standard protocol. There's much evidence we need this, for example, just to pick one, the number of TLD zones with very large DNSKEY sets. On the other hand, confusing operations and protocol can impair efforts to improve the protocol, such as how round-robin made DNSSEC more difficult in needing to define a canonical order of the resource records within an RR set. I'd support this document but it has to state up front that it has a limited scope, which needs to be properly defined. The origin of my comment is section 2.1 which says that a delegations' name must be a hostname (a'la RFC 1123) and further that registered names are generally good for this. I know that there's no need for a delegation's name to be "printable" in general, the only delegation I can't make work (with DNSSEC) is '*'. E.g., there's no reason I can't have "\007.mylab.mydept.myorg.example" in my zone. Of course, that would not be very easy to access via a web browser location bar. Contrary to that, I had few "problems" with section 3 because it states up front "the public Internet DNS hierarchy" as the application domain. Section 2 and earlier didn't scope the work. What I can't find is a definition for, what is called in section 8, a "fully functional" delegation. Again, that is tied to the lack of scope. And, (as this dives deeper than I intended to mention), in section 8.2 there is this: "Any DNSKEY algorithm number used for in a zone MUST be assigned by IANA." Does that include PRIVATEDNS (253)? (To pick nits, it's not DNSKEY algorithm number, it's the registry of DNS Security Algorithm Numbers.) If someone uses that "IANA assigned" number they won't be "fully functional" for some interpretation of "fully functional." And ... I think IANA "assigned" is the wrong verbage, perhaps IANA registered. By now I've gone far into the weeds. I'd like to see the document state or define what kind of delegations it is covering. I think it is fine to define a kind of something more generic and apply rules to that. Much in the same way that IDNA defines rules for IDNA-aware applications while not altering the basic protocol definition. Bottom line - there ought to be a way to provide operational guidance to participants on the global public Internet while allowing for continued permission-less innovation. Guidance is needed but don't give it in a way that can be used to stop anyone from trying other things in their sandboxes.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
