[dd] Proposed alternate opening for the charter

[Edward Lewis <[e-mail]>]

"traditionally" - that is the current specified way of the protocol!

"children often have more up-to-date information" - of course they do!  They define the name servers they use.  Clarifications to the DNS (2181) places the apex NS set at a higher trustworthiness than the cut NS set, DNSSEC only signs the former for a reason.

"registries" - the problem is not with the DNS provisioning system.  Keep that field out of it!   This is about how the DNS moves data from one place to another, well, about how to find the source of information, so it can be retrieved and delivered to the requestor.  Don't mention registries.  It is not about TLDs nor down-tree open-for-registration zones, don't open that can-of-use-cases.

The charter ought to include themes of how the DNS operating environment has evolved and how the existing mechanisms restrict modifications.  I've added proposed new text.  The old text is here as well, to keep this in the email archives.

Existing text -

"The DNS protocol has traditionally had limited ability to signal to recursive resolvers about the capabilities of authoritative servers they communicate with. In part, this stems from the inability of parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records. Further complicating matters is the inability of a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child. A significant issue in today's deployed DNS that derives from these issues is data often being out of synchronization between parents and children. Said another way, children often have more up-to-date information about the nameservers and DNSSEC keying information than their parents due to slowness, or complete lack, of automated child-to-parent updates."

Proposed text:

The DNS protocol uses two records to declare a delegation in the namespace, the NS Resource Record and the DS Resource Record.  These two records permit the finding of IP addresses for name servers and the keys used for DNSSEC.  (Glue address records are used as hints to find the name servers.)  Other information regarding the delegation, such as port number, is left to assumptions hardcoded in software or in configuration files, limiting the ability to modify the DNS protocol.  The use of service negotiation, which could happen once a delegation is followed, is hampered by the one-way nature of DNS information flow due to the ability to scale required by DNS.

The operational environment surrounding DNS has emerged and evolved since the initial deployment of the protocol.  Scale has led to massive numbers of delegations being created and managed and manged over years and decades.  Inattentiveness, whether due to too-many-to-manage or zones being forgotten over time, has resulted in misconfigured NS and DS records causing operational outages.  Increased functionality has been placed on the DNS as it is as much the center of the Internet as any other system, motivating desire to modify the protocol that requires changes to the original assumptions.  The greater role DNS plays in Internet operations has led to zone administrators outsourcing DNS operations to expert firms and in cases where a single point of failure is not acceptable, multiple expert DNS operators.

Extending the DNS to support the current demand placed upon it is hampered by the limitations of having delegations defined by the NS Resource Record and the DS Resource Record.  A new means to express delegation information is needed, one that permits flexibility in the protocol to meet the needs of the operational environment and that aids in the deployment of protocol improvements.