**Session Date/Time:** 26 Jul 2022 19:00

# add

## Summary

The "add" (Adaptive DNS Discovery) session began with administrative challenges, including a late start and microphone issues. Eric, the Area Director, presented the plan for a new DNS Directorate to provide early review for DNS-related drafts across the IETF. The session also reviewed the status of several key working group documents, including "Split Horizon Authority," "DNS Resolver Information," and "Reputation Verified Selection of Upstream Encrypted Resolvers," with calls for feedback, implementer interest, and working group adoption. The latter part of the combined session transitioned to "d-priv" (DNS Privacy) discussions, focusing on the "Unilateral Probing" draft, which aims to encourage opportunistic encryption between recursive and authoritative DNS servers.

## Key Discussion Points

*   **Administrative & Logistics**
    *   The session began with technical difficulties, including microphone issues for co-chair Glenn and login problems for co-chair Dave.
    *   Paul Hoffman kindly volunteered to scribe for the session.
    *   Thanks were extended to Andrew Kampling for his significant work as a document shepherd, advancing three large documents through IESG review.
    *   The chairs noted that this was the first in-person ADD session with a chair present, and acknowledged the group's productivity in virtual settings over the past two years.

*   **DNS Directorate Introduction (Eric, AD)**
    *   **Problem Statement:** An increasing number of IETF drafts (estimated 59) rely on DNS, but many working groups lack sufficient DNS expertise, leading to potential protocol or infrastructure issues in proposed solutions.
    *   **Solution:** The IESG, along with ADD, D-PRIV, and DNSOP chairs, has decided to create a "DNS Directorate" (analogous to Yurt Doctors for YANG drafts).
    *   **Function:** The Directorate will offer early review for adopted working group drafts with DNS content, providing expert feedback before reaching IESG review.
    *   **Goals:** Ensure proper use of DNS in IETF documents and foster a pipeline of new talent (reviewers, shepherds, chairs) for DNS-related work.
    *   **Discussion:**
        *   **Review Rubric:** Anacond Gilmore (ACLU) inquired about review rubrics. Eric responded that any early review is beneficial, and the secretariat will aim to match reviewers with relevant expertise.
        *   **Draft Identification:** Jim Reid asked how drafts would be identified. Eric clarified that working group chairs would explicitly request reviews.
        *   **Conflict of Views:** Paul Hoffman raised concern about potential conflicting "don't do that in DNS" vs. "ooh cool new thing" advice. Eric stated the primary goal is to prevent bad designs early.

*   **Document Status Updates (Chairs)**
    *   Several documents shepherded by Andrew Kampling have progressed through IESG review with "solid" status and are expected to move towards publication (RFC).
    *   The "Service Speed" document has cleared all IESG "Discuss" comments.

*   **Split Horizon Authority (draft-ietf-add-split-horizon-authority) - Dan Wing & Ben Schwartz**
    *   **Status:** Adopted as a working group draft (`00` version).
    *   **Key Changes in `00`:** Refined definitions of "split horizon DNS" and "validated split horizon." Clarified scope, how to use pre-configured external resolvers, and mechanisms to avoid leaking internal domain data.
    *   **Validated Split Horizon:** The draft focuses on scenarios where the public domain owner explicitly authorizes a split view, verified by DNSSEC or public resolver queries, preventing its use for general filtering.
    *   **DNSSEC Validation:** Identified a need for further working group feedback on handling DNSSEC validation within captive portal environments and refining "must-not" language regarding data leakage.
    *   **Data Leakage:** The draft aims not to leak internal hostnames (e.g., `mail.internal.example.com`), but acknowledged that the zone name (e.g., `internal.example.com`) would be visible if queried publicly for validation.
    *   **Discussion:**
        *   Ben Schwartz emphasized the draft's self-consistency and readiness for last call, soliciting specific feedback on desired changes. He noted its evolution to a general "local domain hint" concept, applicable to various network types (e.g., DHCP).
        *   Andrew Kampling supported the draft, noting it addresses an important problem and should proceed to last call.
        *   Tommy Pauly requested implementation/deployment experience. He questioned the strict requirement for DoNR (DNS over Named Resolver) for validation, suggesting that a more "ugly" but secure method using DoDR (DNS over Designated Resolver) certificate validation could be highly beneficial for enterprise deployments given hardware upgrade cycles. Ben Schwartz acknowledged the possibility of such a method.

*   **DNS Resolver Information (draft-elkarrat-add-resolver-info) - Ahmed Elkarrat**
    *   **Status:** Seeking working group adoption.
    *   **Key Updates:** Shortened the list of advertised attributes, constrained some attributes (primarily for diagnostics), and strengthened validation requirements for attribute consumption.
    *   **Rationale:** Addresses a charter item for the ADD working group (discovery of resolver information) and supports other working group solutions (e.g., structured errors).
    *   **Discussion:**
        *   Punit Sood (Google Public DNS) noted a lack of client-side implementer interest. He suggested using numeric codes for EDNS0 options instead of text strings for compactness and to avoid IANA allocation. Ahmed Elkarrat agreed this was a workable change post-adoption.

*   **Reputation Verified Selection of Upstream Encrypted Resolvers (draft-box-add-rvs) - Chris Box & Ben Schwartz**
    *   **Status:** New `02` revision, new name ("Reputation Verified Selection..."), now proposes client behavior (not merely informational).
    *   **Problem:** Millions of home routers are difficult to upgrade, leaving many users reliant on unencrypted Do53, vulnerable to passive monitoring. Upgrading core ISP networks is faster than individual routers.
    *   **Solution (RVS):** Clients perform DDR discovery; if the local forwarder doesn't understand DDR, it forwards to an upstream recursive resolver that supports encrypted service. The client then uses a reputation system to verify the identity of the offered encrypted service. If the reputation meets client criteria, encrypted DNS is used.
    *   **Cross-Forwarder Upgrade:** This mechanism enables encrypted DNS even when the local forwarder is unencrypted and on a private IP.
    *   **Issues & Mitigations:**
        *   **Blocking Function:** Local forwarders providing blocking (e.g., malware) should block this upgrade mechanism (e.g., by blocking `resolver.arpa`).
        *   **Split Horizon:** Clients must detect split horizon names to exempt them from cross-forwarder upgrades.
    *   **Reputation System:** The draft allows for various reputation models (e.g., embedded lists, online systems), leaving the choice to the client.
    *   **Open Questions:**
        *   **Identity Confirmation:** Current method involves a "certificate dance." An alternative (service binding target name) exists but requires SNI and may not be compatible with all upstreams.
        *   **Resolver Identity Simplification:** Whether to use the full URI template or just the domain name for reputation checks, balancing simplicity with differentiation.
    *   **Discussion:**
        *   Eric (AD) provided a strong vote of confidence, expressing enthusiasm for adoption, stating it's the best plan to solve the home router upgrade problem.
        *   Andrew Kampling highlighted the extreme benefit to users, especially given the high percentage of traffic from private IPs, and urged rapid progression.
        *   Tommy Jensen (Microsoft) found the new direction (evaluating resolver trustworthiness vs. upgrade security) interesting and a better security approach. However, he questioned client-side adoption, noting that Microsoft avoids trust lists, relying on user selection. He asked why clients needing custom trust evaluation couldn't use a similar out-of-band mechanism to *provide* resolvers directly.

*   **d-priv Session Transition & Unilateral Probing (draft-ietf-dprive-unilateral-probing) - Daniel Gilmore & Paul Hoffman**
    *   **Working Group Status:** The d-priv chairs noted slow progress on other drafts and suggested possibly "going dark" for a period to encourage implementations.
    *   **Unilateral Probing Goal:** To gain practical experience with encrypted transport (DoT/DoQ) between recursive resolvers and authoritative DNS servers, without requiring authentication or hard-fail mechanisms initially.
    *   **Mechanism:** Recursive resolvers opportunistically "try" encrypted transport (similar to Happy Eyeballs for IPv4/IPv6). Authoritative servers should offer encrypted transport. Guidance is provided to minimize resource consumption and reduce cleartext use.
    *   **Key Changes:** Moved future steps to an appendix, clarified state transitions (allowing continued encrypted attempts even if cleartext succeeds), and corrected timing for persisting learned successful connections.
    *   **Implementations Noted:** PowerDNS recurser (ADoT), PowerDNS.com zone, and `a.n.s.facebook.com` (TLS on port 853).
    *   **Call for Implementers/Operators:** Strong call for implementers to try the approach and report experiences (successes, issues, resource impact). Authoritative server operators are also sought for feedback on query volumes and optimal TLS tuning (e.g., resumption, idle timers, load balancers). The draft is designed to be harmless for authoritative servers even with client misimplementation.
    *   **Outstanding Questions:** Address FixMEs related to error handling guidance for recursive resolvers, determine if the document should be Standards Track (leaning yes), and consider adding explicit visualizations (flow diagrams) of resolver steps.

## Decisions and Action Items

*   **DNS Directorate:**
    *   **Decision:** An IESG-backed DNS Directorate will be created to provide early review for DNS-related drafts.
    *   **Action Item:** Warren and Eric will send an email by the end of August 2022 to solicit volunteers for experienced and less experienced reviewers, as well as two secretariat roles.
*   **Split Horizon Authority (draft-ietf-add-split-horizon-authority):**
    *   **Action Item:** Authors request specific feedback from the working group, particularly on DNSSEC validation in captive portal situations and the wording of non-leakage, to prepare for a working group last call.
*   **DNS Resolver Information (draft-elkarrat-add-resolver-info):**
    *   **Action Item:** The working group will consider a call for adoption. Authors to consider integrating numeric codes for EDNS0 options.
*   **Reputation Verified Selection of Upstream Encrypted Resolvers (draft-box-add-rvs):**
    *   **Action Item:** The working group is encouraged to review and provide feedback towards adoption. Authors to further refine the discussion on resolver identity confirmation and simplification.
*   **Unilateral Probing (draft-ietf-dprive-unilateral-probing):**
    *   **Action Item:** Implementers of recursive resolvers and operators of authoritative DNS servers are strongly encouraged to experiment with the draft and provide feedback on implementation experiences, resource impact, and TLS tuning.
    *   **Action Item:** Authors will address remaining FixMEs (error handling) and consider adding visual diagrams. The working group will discuss whether the document should be a Standards Track RFC.

## Next Steps

*   **DNS Directorate:** Volunteers needed by end of August 2022.
*   **ADD Working Group Documents:** Chairs will monitor feedback for `split-horizon-authority` to prepare for last call. Chairs will proceed with a working group adoption call for `resolver-info` and `rvs` based on interest.
*   **d-priv Working Group Documents:** The chairs may consider a period of reduced activity ("going dark") for other d-priv drafts to allow for more implementation experience for `unilateral-probing`.
*   **AOB:** Additional items from the chairs (Dave and Glenn) have been deferred to IETF 115.