Re: [dd] [Ext] starting charter text for the DELEG BOF discussion

[Edward Lewis <[e-mail]>]

Having read the ensuing thread, I'm coming back to the start.

First question - will a revised proposed charter be posted to the list?  Might be good to discuss again, post-bof.

Some comments on this: I think the term "registry" ought to be avoided - it puts emphasis on the current registration system model driving the Internet as we know it, as opposed to the finer points of the DNS protocol.  To this point - it's not that the registries couldn't provide more information, it's that the protocol limited what was specified, leaving much to assumed, have-to-be-hard-coded parameters.

DELEG is a replacement mechanism for delegating the name space.  What we have now (NS) is weak and is an operational nightmare (dual NS sets at cut point/apex).  We can improve it by, to start with, using the information collected and maintained to run the DNS and include that information as run-time parameters as opposed to compile-time parameters.  DELEG can help eliminate confusion over delegation points and differentiate between the kinds of delegations.

My suggestion is that the charter reflect more the impact on the protocol we now run over port 53 (or that other one for DoT) and less on the how the top-level registration system has evolved.  There's already been posts noting the registries below the TLD registries.  Beyond that substructure, DELEG will have to support other ways the name space has been carved up as well.  DELEG needs to solve for more than the TLD use case.

On 3/2/24, 15:40, "dd on behalf of Wes Hardaker" <[e-mail] on behalf of [e-mail]> wrote:


    Greetings all,

    Your BOF chairs have worked on starting text for a potential charter based on the discussions to date.  Clearly, this is starting text and deserves discussion both on the list and in the BOF. We look forward to the upcoming BOF and from hearing from everyone's opinions on this starting point for a charter.

    ----------


    # Background and Problem Space

    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.

    The Internet's dependence on the DNS as a critical starting point for most communication has resulted in the development of a complex ecosystem that consists of many different parties, business relationships, and software packages.
    Software deployments exist in environments that range from small CPE devices and software packages to entire clusters of world-wide distributed server platforms.

    # Objective and Scope

    To address these challenges, the working group will first develop the requirements for adding a new signaling mechanism that allows parents to return DNS delegation information to resolvers.

    The working group will also list the other types of information not available today that might be be provided over a designed signaling mechanism.

    The working group will then define the semantics of a new signaling mechanism, taking future extensibility into account.

    The first use case for this DNS delegation signalling mechanism is expected to be delegation aliasing, where the parent returns a pointer to service provider that will then return the needed delegation information.
    This use case has been discussed for many years in the DNSOP and other Working Groups.

    The working group will only specify extensions to the DNS protocol that relate to delegation.

    # Deliverables

    - A document listing the consensus-derived requirements for a new signaling mechanism between a parent and a resolver about communication parameters available for communicating with a delegated child.
    This need not be published as an RFC and may remain as an Internet-draft.

    - A document listing, and ideally prioritizing, new delegation attributes to be distributed from parents that would benefit resolver and child communications.
    This need not be published as an RFC and may remain as an Internet-draft.

    - A specification defining the new delegation attribute signaling mechanism.
    This is expected to become a standards-track RFC.

    - A specification for how to use the new delegation attribute signaling mechanism to perform aliasing for delegation.
    This is expected to become a standards-track RFC.



    -- 
    Wes Hardaker
    USC/ISI

    -- 
    dd mailing list
    [e-mail]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dd__;!!PtGJab4!6oEk1JPdXfpJ7mC-LsETadRh7r1_NrsDGsLdlBNmymR4QagOGSb2t7tFT5l_Ndg7s6qpf4oxBJp6HmNHbBrOYPhIHg$ [ietf[.]org]