Session Date/Time: 05 Nov 2025 19:30

ADD Session

Summary

The ADD Working Group met at IETF-124 to review the status of its adopted working group draft (draft-ietf-add-svcb-dns-discovery) and hear presentations on two new individual submissions: draft-dliu-add-edns-sd (Multicast DNS-based Service Discovery for Encrypted DNS) and draft-dliu-add-ppp-ipcp-edns (Encrypted DNS Configuration in PPP IPCP). Discussions highlighted the need for addressing outstanding issues in the WG draft and raised significant concerns and questions regarding the motivation, security implications, and appropriate technical mechanisms for the new drafts, particularly concerning user control over DNS and the use of existing SVCB/SVC parameters. The session also touched upon the future of the working group and broader IETF efforts to organize DNS-related work.

Key Discussion Points

Working Group Draft Update: Adaptive DNS Discovery (draft-ietf-add-svcb-dns-discovery)
- Status: The draft has expired due to no updates in six months.
- Reason for Delay: John Todd (speaking for the editors) reported one outstanding item: adding an example suggested by Tommy Jensen. The primary reason for the delay is ongoing work on implementing and testing edge cases, such as chain redirects and mismatched features between servers, before a Working Group Last Call (WGLC).
- Timeline: Editors hope to provide an update before or at IETF-125.
- Assistance: The editors welcome help from anyone willing to implement the draft to aid testing.
- Next Steps: The co-chair expressed that an email-based WGLC could follow the next update, assuming no major new feedback.
New Draft Presentation 1: Multicast DNS-based Service Discovery for Encrypted DNS (EDNS-SD) (draft-dliu-add-edns-sd)
- Motivation: Dong DeLieu presented the draft, highlighting the need for encrypted DNS discovery in local networks (homes, enterprises, IoT, temporary/disaster recovery) that lack centralized infrastructure. The draft aims to complement existing standards like RFC 9463, which are infrastructure-dependent.
- Solution: The proposal introduces three new service types for DoT, DoH, and DoQ, using mDNS-SD for discovery. It specifies rich TXT record parameters for configuration details like ALPN and DOH paths.
- Discussion:
  - Stuart Cheshire (Apple): Expressed support for the general idea. Suggested that the "multicast" aspect might not be strictly necessary, as the mechanism could apply to unicast DNS-SD as well. Recommended reviewing DNS-SD.org for examples.
  - Chris Box: Raised security concerns about rogue devices advertising encrypted DNS services on local networks, similar to issues with rogue DHCP/RA. Questioned the use case, particularly in scenarios where such announcements could be exploited.
  - Stuart Cheshire (Apple) (responding to Chris Box): Argued that existing network defenses (like RA guard, DHCP snooping) and mDNS filtering already prevent rogue advertising in managed environments.
  - Eric Vink: Noted that mDNS filtering in places like Starbucks is often for multicast traffic reduction, not necessarily security. Questioned the use of TXT records instead of SVCB/SVC parameters (as used in RFC 9462/9463).
  - Tommy Jensen (Cloudflare): Expressed concern about automatically using mDNS-SD for DNS discovery, as DNS should generally be transparent to users. Viewed disaster recovery as a broader network problem beyond DNS, requiring more than just DNS server discovery.
  - Michel Francois: Echoed the suggestion to use SVCB/SVC parameters for consistency with RFC 9463 and noted that SVCB can be carried over mDNS. Advised against using "EDNS" in the title/document to avoid confusion with DNS Extension Mechanisms.
  - Lorenzo: Highlighted security and privacy risks on home networks if mDNS-SD allows untrusted parties to advertise DNS services and potentially sniff queries. Argued that authentication requires prior trust, defeating the zero-configuration goal. Suggested DHCP/RA are simpler for providing network config.
  - Tommy Pauley (Apple): Emphasized that existing mechanisms like DDR/DNR cover many cases for network-provisioned encrypted DNS. Stressed the lack of a clear trust model for this mDNS-SD approach. Suggested that for emergency scenarios, pre-configured public DNS lists might be more practical for clients than relying on local discovery. Agreed on reusing SVCB encoding.
  - Jim Reid: Requested clearer problem statements and use cases. Reiterate concerns about using TXT records over dedicated record types like SVCB.
- Chair's Read/Direction: The chairs' sense was that the authors received substantial comments, particularly regarding motivation, use cases, and technical mechanisms (SVCB vs. TXT). Authors were asked to incorporate this feedback, especially refining the why for the draft, and submit a revised version for further discussion on the mailing list.
New Draft Presentation 2: Encrypted DNS Configuration in PPP IPCP (draft-dliu-add-ppp-ipcp-edns)
- Motivation: Dong DeLieu presented this draft, addressing the widespread use of PPP/PPPoE in broadband access and the lack of a standard for encrypted DNS negotiation within PPP's IPCP, which currently only supports plaintext DNS (RFC 1877).
- Solution: The draft proposes three new IPCP configuration options: Type 133 for primary encrypted DNS server, Type 134 for secondary, and Type 135 for encryption parameters (e.g., ALPN, DoH path). These are backward compatible with RFC 1877.
- Discussion:
  - Tommy Jensen (Cloudflare): Raised a strong concern about a stated motivation in the draft's introduction: "ISPs can enforce authenticated DNS resolvers and prevent bypassing." The author confirmed this was a goal. Tommy Jensen vehemently disagreed, stating it conflicts with the IETF's goal of enabling user control over DNS queries.
  - Tommy Pauley (Apple): Agreed with Tommy Jensen that preventing client bypass of ISP-provided encrypted DNS is not a desirable goal. Questioned the appropriate venue for this work, as it primarily involves PPP expertise, suggesting IPSEC WG or the INT area might be more suitable, with ADD providing DNS expertise.
  - Tobias Wiabich (Max Planck Institute): Echoed Tommy Jensen's concerns about the "enforcement" motivation and the technical feasibility of such enforcement. Asked why IPv6 configuration doesn't use existing RA options for DNR. Authors noted they are considering adding an IPv6 section. Re-clarified the overall vision of the two drafts: EDNS-SD for local/infrastructure-less, PPP IPCP for access networks with central authentication, and DNR covering the rest.
  - Jim Reid: Suggested an early technical review of both new drafts by the DNS Directorate to provide input on DNS content while the appropriate working group is being determined.
  - Wes Herdicker: Expressed concern that adding non-adopted drafts to the DNS Directorate's review queue would increase an already heavy workload.
  - Glenn: (wearing DNS Directorate co-chair hat) Clarified that DNS Directorate co-chairs do review documents, but are subject to the same queue as other directorate members.
  - Tommy Jensen (Cloudflare): Reiterated that the PPP draft's technical mechanism (advertising encrypted DNS via PPP) is reasonable and could belong in ADD. However, the stated motivation of ISP control is fundamentally problematic and does not align with IETF principles.
- Chair's Read/Direction: The authors received significant feedback, particularly on the problematic motivation of preventing client bypass. They were directed to incorporate these changes, refine the draft's motivation, and submit an updated version for further discussion on the mailing list.
Working Group Future and SVCB Bleaching Discussion
- Eric Vink (AD): Inquired about the working group's future. While the primary WG document is nearing completion, new proposals suggest there may be ongoing work, indicating the group might remain open.
- Tommy Pauley (Apple): Discussed the WG's lifespan, suggesting that the PPP case might be the most relevant remaining work. Asked if future "DNS over Foo" provisioning mechanisms should be handled by ADD or a different home. Also reminded the chairs of a previously chartered operations document that had not been pursued but might cover topics like SVCB operational issues.
- Chairs: Confirmed an outstanding chartered item regarding certificate provisioning on CP devices, which could reignite if issues are resolved.
- Eric Vink (AD): Expressed intent to keep the WG open, especially given the new drafts and the group's expertise in SVCB/DNS discovery, which may not exist in other groups like the INT area.
- Lorenzo: Reported observing "bleaching" of SVCB records in production networks, impacting DDR, where some encrypted DNS traffic "vanished." Asked for guidance on this operational issue.
- Chairs: Acknowledged the issue might fall under the previously unpursued "operations document" in the ADD charter.
- Wes Herdicker: Mentioned he is collecting feedback on behalf of the IESG regarding the organization of DNS-related working groups across the IETF, including questions about WG lifespan and scope. He encouraged strong opinions to be shared with him or the relevant mailing list.
- Tommy Pauley (Apple): Acknowledged SVCB bleaching exists but might be tied to attempts to block other SVCB uses. Suggested such operational issues might better belong in DNSOP. Discussed potential client-side heuristics (e.g., remembering previous results) to mitigate bleaching. However, if networks are intentionally blocking non-network-picked DNS servers, that's a policy issue beyond technical solutions.

Decisions and Action Items

Working Group Draft (draft-ietf-add-svcb-dns-discovery): Editors are to incorporate the suggested example and complete the implementation testing for edge cases. An update is expected before or at IETF-125, after which a WGLC is anticipated via email.
draft-dliu-add-edns-sd: The authors are to revise the draft, giving particular attention to clarifying the motivations and use cases. The revised draft should be submitted, and further discussion regarding its direction will occur on the mailing list.
draft-dliu-add-ppp-ipcp-edns: The authors are to revise the draft, specifically addressing the contentious motivation related to ISP control over client DNS resolvers. The revised draft should be submitted, and further discussion regarding its direction will occur on the mailing list.

Next Steps

The authors of both new drafts are expected to incorporate the feedback received during the session, with particular emphasis on clarifying and aligning the motivations and use cases with IETF principles. They should then submit updated versions of their drafts and engage in further discussion on the ADD mailing list.
The chairs will continue to monitor the progress of the working group's adopted draft and facilitate discussions on the new submissions.
The IETF-wide discussion on the organization of DNS-related work (led by Wes Herdicker) will continue to gather input on working group scope and longevity, which may impact the future direction and home of DNS-related work.
The ADD Working Group will continue to evaluate its future, balancing the completion of existing work with the potential for new chartered items and the broader IETF landscape for DNS work.