**Session Date/Time:** 18 Mar 2024 23:30

# deleg

## Summary

This meeting was held to discuss the formation of a working group to address limitations in current DNS delegation methods. Presentations were given on the problem space, including issues with capability discovery, registrar dependencies, and parent/child inconsistency. The existing DNS Up Deleg draft was reviewed, and charter text was discussed. The primary goals are to improve delegation security, enable capability discovery (e.g., for encrypted DNS), and consider future extensibility.

## Key Discussion Points

*   **Limitations of current delegations:**
    *   Lack of a method to signal capabilities (secure transport, error reporting, etc.).
    *   Operational dependency on registrar/registry chain for DS record updates.
    *   Unsigned glue records in parent zones.
    *   Inconsistency between parent and child zones.
*   **Goals for new delegation methods:**
    *   Facilitate name server capability advertisement.
    *   Add layers of indirection for operational independence.
    *   Enable name server authentication before use.
    *   Avoid inconsistency between parent and child zones.
    *   Provide cryptographic security against downgrade attacks.
    *   Maintain backwards compatibility with existing implementations.
    *   Ensure future safety and extensibility.
*   **Downgrade resistance for encrypted DNS (DoT):**
    *   Current opportunistic security (RFC 9539) is vulnerable to downgrade attacks.
    *   Wide deployment of downgrade resistance is needed.
    *   Deleg is seen as enabling downgrade resistance.
*   **Rebound effort & Domain Boundaries:**
    *   Discussion of how delegations could express domain boundaries beyond zone cuts.
    *   Consideration of "policy only" delegations without name server or glue records to announce policy for children domains
*   **Existing draft (DNS Up Deleg):**
    *   Mimics NS records but with the ability to sign glue records in the delegation itself.
    *   Includes "alias mode" for redirecting delegation to an operator who has trust.
    *   Initial positive results from hackathon and testing.
*   **Charter Discussion:**
    *   Several points were raised about the proposed charter text, specifically:
        *   Jeff Houston: Suggested deleting the second paragraph in the background section.
        *   Warren: Suggested reordering the priority of use cases in the 4th paragraph of the Objectives and Scope section or restating the language so that priority wasn't implied.
        *   David: Suggesting just calling the use cases in the 4th paragraph of the objectives and scope section as potential use cases rather than prioritized use cases. He also suggested that for extensibility, to change from, "taking future extensibility into account," to "considering the possibility of future extensibility."
        *   Eric: Would like it to strongly emphasize the requirements specification in both the objectives and scope and the deliverables section.
        *   Duane: Pointed out that Delec requires more than DNS changes like EPP changes.

## Decisions and Action Items

*   Paul and Wes will iterate on the charter text based on the feedback received during the meeting and on the mailing list.
*   Attendees are requested to be active on the `deleg@ietf.org` mailing list to contribute to the charter discussion.
*   It was determined that Registrars needed to be involved in future discussions.
*   Deliverables include a requirements document, a specification for the delegation mechanism, and considerations for how the solution will work with transports like DOT or DoQ.

## Next Steps

*   Continue charter discussion on the `deleg@ietf.org` mailing list.
*   Refine charter text based on mailing list discussion.
*   Submit the charter to the ISG for review and approval.