Re: [dd] [Ext] Listing of mentioned potential desired extensions to today's DNS delegation

[Edward Lewis <[e-mail]>]

Regarding any chartering conversation - are you seeking a list restricted to updates of the DNS for which there is a realistic chance of it being implemented based on current conditions or a list including "blue-sky" futures?  As an example of the latter, migrating to an entirely different wire-format?


On 2/22/24, 10:30, "dd on behalf of Paul Hoffman" <[e-mail] on behalf of [e-mail]> wrote:

    Greetings again. Thanks for your earlier comments on the beginnings of the list of possible desired extensions for DNS delegation. This will help us as we formulate a proposed charter for the future WG.

    The following is a fuller list of desired extensions mentioned in the mailing list, along with an initial list of how those desired extensions might be implemented in later protocols. Again, these are just preliminary lists, mostly to help people think more about how to form a charter. It is likely that only a subset of the list will be considered.  Other ideas will also likely come up in the eventual WG chartering discussion.  Most importantly, many of these might be significantly out of scope from a likely initial charter but are listed here for sake of completeness.


    - Aliasing: A single-step mechanism that says "all of the delegation material for the child can be found on that server over there"

    - Signed NS and glue records: Greater assurance for validating resolvers of information they receive currently

    - Other DNS transports: Know what non-port-53 transports the given name servers can use

    - Child specific centricity: only use parental information to bootstrap gathering full information from the child

    - DBOUND/PSL: Declare that this is a policy boundary (maybe is not related to delegation), potentially with historical information

    - Split delegation: Parent delegates, but also is authoritative for some RRtypes for the child

    - DS pinning for particular nameservers: The resolver will only expect specified signing algorithms to be used by specified name servers.  This is specifically needed for improved multi-signer DNSSEC situations.

    - Error reporting destination: Specify where error reports can be sent to when the delegated name servers behave unexpectedly

    - Denial support: A mechanism to allow a nameserver to deny that it serves that zone

    - Auto delegation updates: Auto-signaling of changes in delegation information, with increased usability over existing choices (CDS/CSYNC)

    - Child zone policies and properties: Signed statements of child zone policies or properties mapped into the parent (akin to DNSKEY flags)

    - Multi-hosting failure detectiong: Better detection for moving between multi-hosting environments when one is failing

    - Do not contect: Indication from the parent that contacting the child is not necessary after this response


    How they might be implemented 

    Specifying delegation extensions
     Single new RRtype, extensible, in Authority section
     Multiple new RRtypes, each specific to an extension, in Authority section
       Reserve a range of RRtypes at IANA to indicate "resolve at parent"
     Overload DS records (requires changing DS display format)
     Allow aliasing of DS records in DS (requires changing DS display format)
     EDNS0

    Aliasing
     Target has a SVCB record IP addresses of delegated servers
     If one alias among multiple gives a bad result, try another

    Signed NS and glue records
     Put in a new RR, sign that
     Add signatures for NS and glue in reply

    Child centricity
     Parent and child both have delegation records, use child's unless parent's is signed and child's isn't
     DBOUND/PSL in child can point one level up

    -- 
    dd mailing list
    [e-mail]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dd__;!!PtGJab4!7mBFeH-StW2p-o3NOXXbD1oKWCG1Ct9Fw1inul6dG2nR8iaO2iRKVrSJK2cz2LYSG2oK8feYhoZEV2MOgxoi1w-uA55gqRM$ [ietf[.]org]