ADD Working Group D. Liu Internet-Draft Jinan University Intended status: Informational Z. Yan Expires: 22 September 2026 CNNIC G. Geng G. Zeng Jinan University 21 March 2026 DNS-Based Service Discovery for Encrypted DNS Services draft-liu-add-dnssd-edns-02 Abstract This document defines a DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks. It specifies new service types (_dot, _doh, _doq) and associated service parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. The mechanism works over both multicast DNS (mDNS) and unicast DNS- SD, addressing critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763. This document leverages SVCB and HTTPS resource records (RFC 9460) for parameter negotiation, with TXT records provided for compatibility with legacy implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 22 September 2026 [Page 1] Internet-Draft Encrypted DNS SD March 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Local Network Privacy Challenge . . . . . . . . . . . 3 1.2. DNS-SD as a Solution for Privacy-Aware Discovery . . . . 3 1.3. Key Use Cases . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Relationship to Existing Standards . . . . . . . . . . . 4 2. Terminology and Requirements . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 3. Service Type Definitions . . . . . . . . . . . . . . . . . . 5 3.1. Encrypted DNS Service Types . . . . . . . . . . . . . . . 5 3.2. Service Instance Name Format . . . . . . . . . . . . . . 5 4. DNS Resource Records . . . . . . . . . . . . . . . . . . . . 6 4.1. PTR Records (Service Discovery) . . . . . . . . . . . . . 6 4.2. SRV Records (Service Location) . . . . . . . . . . . . . 6 4.3. TXT Records (Legacy Compatibility) . . . . . . . . . . . 6 4.4. SVCB/HTTPS Records for Service Parameters . . . . . . . . 7 5. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Advertisement . . . . . . . . . . . . . . . . . . 8 5.2. Client Discovery . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Spoofing Countermeasures . . . . . . . . . . . . . . . . 9 6.2. Certificate Validation Models . . . . . . . . . . . . . . 10 6.3. Privacy Implications . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. New DNS-SD Service Types . . . . . . . . . . . . . . . . 11 7.2. TXT Record Key Registry . . . . . . . . . . . . . . . . . 12 7.3. SVCB Parameters Usage . . . . . . . . . . . . . . . . . . 13 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Full DoT Service Advertisement with SVCB . . . . . . . . 13 8.2. DoH Service with Custom Path using HTTPS RR . . . . . . . 13 8.3. Client Discovery Sequence with SVCB . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.3. Other References . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Liu, et al. Expires 22 September 2026 [Page 2] Internet-Draft Encrypted DNS SD March 2026 1. Introduction 1.1. The Local Network Privacy Challenge While encrypted DNS protocols such as DNS over TLS (DoT)[RFC7858], DNS over HTTPS (DoH)[RFC8484], and DNS over QUIC (DoQ)[RFC9250] have gained widespread adoption for public Internet resolution, local network environments often remain vulnerable to surveillance and manipulation of DNS traffic. Many devices and applications in home, enterprise, and industrial networks still rely on plaintext DNS, exposing sensitive metadata such as device activities, service dependencies, and user behavior patterns. Traditional discovery mechanisms (e.g., DHCP, Router Advertisements) lack the flexibility to negotiate fine-grained encrypted DNS configurations and fail in infrastructure-less environments where centralized servers are unavailable. 1.2. DNS-SD as a Solution for Privacy-Aware Discovery DNS-Based Service Discovery (DNS-SD, [RFC6763]) and its multicast variant (mDNS, [RFC6762]) provide an ideal foundation for encrypted DNS service discovery due to their: Zero-configuration operation: Devices autonomously advertise and discover services without requiring a central server. Topology independence: Functions in isolated networks (e.g., home labs, industrial control systems) even without Internet connectivity. Real-time updates: Service availability changes propagate within seconds, unlike DHCP's lease-based delays. Rich parameter negotiation: SVCB records (or TXT records for compatibility) allow flexible exchange of protocol details (ports, ALPN preferences, certificate fingerprints). 1.3. Key Use Cases This specification enables: IoT and Smart Home Privacy: Devices (e.g., cameras, voice assistants) automatically discover and use encrypted DNS without manual configuration in home networks where no DHCP server is present or when users bring devices to temporary locations. Enterprise Network Segmentation: Departments can advertise isolated DNS services (e.g., _dot.finance.corp.local) with policy enforcement, even in air-gapped segments. Liu, et al. Expires 22 September 2026 [Page 3] Internet-Draft Encrypted DNS SD March 2026 Offline and Air-Gapped Networks: Secure DNS resolution in environments where Internet access is restricted but internal name resolution is still required (e.g., industrial control systems, military networks, disaster recovery scenarios). Ad-hoc and Temporary Networks: When devices form a temporary network (e.g., during a conference, emergency response), they can discover and use encrypted DNS services without any pre-existing infrastructure. 1.4. Relationship to Existing Standards [RFC9463] defines DHCP and Router Advertisement options for encrypted DNS discovery (DNR), and [I-D.ietf-add-ddr] specifies Discovery of Designated Resolvers (DDR) using DNS queries. These mechanisms require infrastructure support (DHCP server, router, or recursive resolver) and are suitable for managed networks. This document provides a complementary solution that operates without any infrastructure, making it ideal for ad-hoc, isolated, or zero- configuration environments. The following table summarizes the differences: +================+==============+===============+===================+ | Capability | DNR (RFC | DDR (draft- | This | | | 9463) | ietf-add- | Specification | | | | ddr) | | +================+==============+===============+===================+ | Infrastructure | DHCP/RA | Recursive | None (zero- | | Required | server | DNS server | configuration) | +----------------+--------------+---------------+-------------------+ | Update Latency | Minutes- | DNS TTL | Seconds (event- | | | hours (lease | dependent | driven) | | | time) | | | +----------------+--------------+---------------+-------------------+ | Parameter | Limited by | SVCB-based | SVCB-based | | Flexibility | option space | | | +----------------+--------------+---------------+-------------------+ | Primary Use | Managed | Managed | Ad- | | Cases | networks | networks | hoc/IoT/dynamic/ | | | | with DNS | isolated networks | +----------------+--------------+---------------+-------------------+ Table 1: Comparison with Existing Encrypted DNS Discovery Mechanisms This document defines new DNS-SD service types (_dot._tcp, _doh._tcp, _doq._udp) and leverages SVCB/HTTPS resource records for service parameter exchange, while maintaining backward compatibility with TXT-based discovery for legacy implementations. Liu, et al. Expires 22 September 2026 [Page 4] Internet-Draft Encrypted DNS SD March 2026 2. Terminology and Requirements 2.1. Requirements Language Key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" per BCP 14 [RFC2119] [RFC8174] 2.2. Defined Terms * Encrypted DNS: Collective term for DoT, DoH, and DoQ. * ADN: Authentication Domain Name (FQDN for certificate validation). * Service Instance: Unique identifier for an encrypted DNS resolver (e.g., Finance DoT._dot._tcp.local). 3. Service Type Definitions 3.1. Encrypted DNS Service Types +==============+==========+===========+=================+ | Service Type | Protocol | Transport | IANA Assignment | +==============+==========+===========+=================+ | _dot._tcp | DoT | TCP | REQUIRED | +--------------+----------+-----------+-----------------+ | _doh._tcp | DoH | TCP | REQUIRED | +--------------+----------+-----------+-----------------+ | _doq._udp | DoQ | UDP | REQUIRED | +--------------+----------+-----------+-----------------+ Table 2: Encrypted DNS Service Types 3.2. Service Instance Name Format .. * Instance: Human-readable identifier (e.g., CorpDNS, HomeGateway). * Service: One of _dot._tcp, _doh._tcp, _doq._udp. * Domain: "local." for mDNS, or any domain for unicast DNS-SD. Example: SecurityDoH._doh._tcp.local. Liu, et al. Expires 22 September 2026 [Page 5] Internet-Draft Encrypted DNS SD March 2026 4. DNS Resource Records 4.1. PTR Records (Service Discovery) ; Service enumeration _services._dns-sd._udp.local. PTR _dot._tcp.local _services._dns-sd._udp.local. PTR _doh._tcp.local _services._dns-sd._udp.local. PTR _doq._udp.local 4.2. SRV Records (Service Location) .. [Class] [TTL] SRV * Target: Hostname offering the service (A/AAAA must resolve). Example: HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local. 4.3. TXT Records (Legacy Compatibility) For compatibility with existing DNS-SD implementations, services MAY include TXT records with the following keys. However, new implementations SHOULD use SVCB/HTTPS records as described in Section 4.4. Liu, et al. Expires 22 September 2026 [Page 6] Internet-Draft Encrypted DNS SD March 2026 +===========+============+===================+======================+ | Key | Format | Description | Example | +===========+============+===================+======================+ | path | String | DoH URI path | path=/dns-query | | | | (required for | | | | | DoH when using | | | | | TXT) | | +-----------+------------+-------------------+----------------------+ | alpn | Comma-list | Supported ALPN | alpn=h2,h3 | | | | protocols | | +-----------+------------+-------------------+----------------------+ | pri | Number | Service | pri=10 | | | | selection | | | | | preference | | | | | (0-65535), | | | | | lower is more | | | | | preferred | | +-----------+------------+-------------------+----------------------+ | fp_sha256 | Hex string | Certificate | fp_sha256=9F86D0... | | | | SHA-256 | | | | | fingerprint | | | | | (optional if | | | | | ADN used) | | +-----------+------------+-------------------+----------------------+ | adn | FQDN | Authentication | adn=dns.corp.example | | | | Domain Name | | | | | for | | | | | certificate | | | | | validation | | +-----------+------------+-------------------+----------------------+ Table 3: Legacy TXT Record Keys Full Example (TXT-based): HomeDoH._doh._tcp.local. 120 IN TXT "path=/dns" "alpn=h2" "adn=dns.home.net" "fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08" 4.4. SVCB/HTTPS Records for Service Parameters Following [RFC9460], services SHOULD use SVCB (for DoT/DoQ) or HTTPS (for DoH) resource records to convey connection parameters. The SvcParam keys used are: Liu, et al. Expires 22 September 2026 [Page 7] Internet-Draft Encrypted DNS SD March 2026 +===========+===========================+==========================+ | Key | Description | Example | +===========+===========================+==========================+ | port | Port number (if different | port=443 | | | from SRV or default) | | +-----------+---------------------------+--------------------------+ | alpn | ALPN protocol list. When | alpn=h2,h3 | | | containing HTTP versions | | | | (h2, h3), the 'dohpath' | | | | key MUST be present. | | +-----------+---------------------------+--------------------------+ | dohpath | DoH URI template (for DoH | dohpath=/dns-query{?dns} | | | only) | | +-----------+---------------------------+--------------------------+ | adn | Authentication Domain | adn=dns.example.com | | | Name | | +-----------+---------------------------+--------------------------+ | fp_sha256 | Certificate SHA-256 | fp_sha256=9F86D0... | | | fingerprint (alternative | | | | to adn) | | +-----------+---------------------------+--------------------------+ Table 4: SVCB Parameters for Encrypted DNS The SVCB record also provides the target hostname and priority, which may override the SRV record. Clients MUST first check for SVCB records; if absent, they MAY fall back to SRV+TXT. Example SVCB record for a DoH service: _doh._tcp.local. 7200 IN HTTPS 1 dns-home.local. alpn=h2,h3 dohpath=/dns-query adn=dns.home.net For DoT, use SVCB (not HTTPS) with appropriate ALPN (e.g., "dot"). 5. Discovery Process 5.1. Service Advertisement 1. Encrypted DNS resolver periodically announces its services via mDNS (or unicast DNS update). Liu, et al. Expires 22 September 2026 [Page 8] Internet-Draft Encrypted DNS SD March 2026 +--------------+ +------------------+ | Resolver | | Network | +--------------+ +------------------+ | PTR _services._dns-sd._udp -> _doh._tcp | |----------------------------------------->| | HTTPS HomeDoH._doh._tcp -> alpn=h2, path=... | |----------------------------------------->| | (optionally SRV for legacy clients) | Figure 1: Example mDNS Advertisement with SVCB 5.2. Client Discovery 1. Client queries for service types: ; Query available encrypted DNS services _services._dns-sd._udp.local. IN PTR 2. Query specific instances: ; Query DoH instances _doh._tcp.local. IN PTR 3. Resolve selected service: first request SVCB/HTTPS, fallback to SRV+TXT. ; Request SVCB/HTTPS record HomeDoH._doh._tcp.local. IN HTTPS ; If no HTTPS record, request SRV and TXT HomeDoH._doh._tcp.local. IN SRV HomeDoH._doh._tcp.local. IN TXT router.home.local. IN A router.home.local. IN AAAA 6. Security Considerations 6.1. Spoofing Countermeasures * mDNS Response Validation: Clients MUST verify source IP matches query target (link-local scope). * Rate Limiting: Implement mDNS response rate limiting per Section 11 of [RFC6762]. * TLS Enforcement: Clients MUST validate server certificates against the ADN (from adn parameter) or the fingerprint (fp_sha256). Liu, et al. Expires 22 September 2026 [Page 9] Internet-Draft Encrypted DNS SD March 2026 * Clients SHOULD NOT automatically trust discovered services; user confirmation or policy (e.g., only on trusted networks) is RECOMMENDED. In open or untrusted networks (e.g., public Wi-Fi), malicious devices may advertise fake encrypted DNS services. To mitigate such risks, clients SHOULD adopt additional trust considerations: * Only auto-discover on networks designated as trusted (e.g., home SSID, corporate network). * Require user confirmation before using a discovered resolver. * Allow administrators to pre-configure trusted ADNs or fingerprints. 6.2. Certificate Validation Models +=============+=====================+==========================+ | Trust Model | Verification Method | Use Case | +=============+=====================+==========================+ | Public PKI | ADN + CA validation | General-purpose networks | +-------------+---------------------+--------------------------+ | Fingerprint | fp_sha256 exact | High-security/IoT | | Pinning | match | devices | +-------------+---------------------+--------------------------+ | Private PKI | ADN + custom trust | Enterprise networks | | | anchors | | +-------------+---------------------+--------------------------+ Table 5: Certificate Validation Models In addition to the models above, clients MAY establish trust via out- of-band mechanisms, such as scanning a QR code that encodes the server's certificate fingerprint (fp_sha256) or authentication domain name (ADN). Such mechanisms can be used to bootstrap secure connections in environments where public PKI is unavailable or where higher assurance is required. 6.3. Privacy Implications * Metadata Leakage: mDNS queries reveal client interest in encrypted DNS. * Mitigation: Clients SHOULD use service type enumeration (_services._dns-sd) before specific queries to reduce leakage. In unicast DNS-SD, queries are not broadcast. Liu, et al. Expires 22 September 2026 [Page 10] Internet-Draft Encrypted DNS SD March 2026 7. IANA Considerations 7.1. New DNS-SD Service Types This document requests IANA to register the following service names in the "Service Name and Transport Protocol Port Number Registry" [RFC6335] and the corresponding service types in the "DNS-SD Service Type Bindings" registry. +==============+====================+===========+===================+ | Service Name | Transport Protocol | Reference | Assignment | | | | | Policy | +==============+====================+===========+===================+ | dot | tcp | RFC-TBD | Standard | +--------------+--------------------+-----------+-------------------+ | doh | tcp | RFC-TBD | Standard | +--------------+--------------------+-----------+-------------------+ | doq | udp | RFC-TBD | Standard | +--------------+--------------------+-----------+-------------------+ Table 6: New DNS-SD Service Types The registration templates for these service types are as follows: Service Name: dot Transport Protocol(s): tcp Assignee: IESG Contact: IESG Description: DNS over TLS (DoT) Resolver Service Discovery Reference: RFC-TBD Assignment Notes: This service type is used for discovering encrypted DNS services. The corresponding DNS-SD type is _dot._tcp. Service Name: doh Transport Protocol(s): tcp Assignee: IESG Contact: IESG Description: DNS over HTTPS (DoH) Resolver Service Discovery Liu, et al. Expires 22 September 2026 [Page 11] Internet-Draft Encrypted DNS SD March 2026 Reference: RFC-TBD Assignment Notes: This service type is used for discovering encrypted DNS services. The corresponding DNS-SD type is _doh._tcp. Service Name: doq Transport Protocol(s): udp Assignee: IESG Contact: IESG Description: DNS over QUIC (DoQ) Resolver Service Discovery Reference: RFC-TBD Assignment Notes: This service type is used for discovering encrypted DNS services. The corresponding DNS-SD type is _doq._udp. 7.2. TXT Record Key Registry This document requests IANA to create a new registry titled "Encrypted DNS Service Discovery (DNS-SD) TXT Record Keys" under the "DNS-Based Service Discovery (DNS-SD) Parameters" registry. The registration policy for this registry is "Expert Review" as defined in [RFC8126]. The initial contents of this registry are as follows: +===========+==================================+===========+ | Key | Meaning | Reference | +===========+==================================+===========+ | path | HTTP URI path (for DoH) | RFC-TBD | +-----------+----------------------------------+-----------+ | alpn | Supported ALPN protocols | RFC-TBD | +-----------+----------------------------------+-----------+ | pri | Service selection preference | RFC-TBD | +-----------+----------------------------------+-----------+ | fp_sha256 | Certificate SHA-256 fingerprint | RFC-TBD | +-----------+----------------------------------+-----------+ | adn | Authentication Domain Name (ADN) | RFC-TBD | +-----------+----------------------------------+-----------+ Table 7: TXT Record Key Registry Liu, et al. Expires 22 September 2026 [Page 12] Internet-Draft Encrypted DNS SD March 2026 New assignments require Expert Review. This registry is primarily for compatibility; new implementations should use SVCB parameters as defined in [RFC9460]. 7.3. SVCB Parameters Usage The SVCB parameters defined in [RFC9460] are used as described in Section 4.4. No new IANA registrations are required for SVCB keys; implementers should follow the registration procedures of RFC 9460 if new keys are needed. 8. Examples 8.1. Full DoT Service Advertisement with SVCB ; Service type announcement _services._dns-sd._udp.local. PTR _dot._tcp.local ; SVCB record (preferred) _dot._tcp.local. 7200 IN SVCB 1 router.home.local. alpn=dot adn=dns.home.net ; Legacy SRV and TXT for compatibility HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local. HomeDoT._dot._tcp.local. 120 IN TXT "adn=dns.home.net" "fp_sha256=9F86D08188..." router.home.local. 120 IN A 192.168.1.1 router.home.local. 120 IN AAAA fd12:3456::1 8.2. DoH Service with Custom Path using HTTPS RR OfficeDoH._doh._tcp.local. 7200 IN HTTPS 1 dnsgateway.corp.local. alpn=h2,h3 dohpath=/internal/dns adn=dns.corp.example 8.3. Client Discovery Sequence with SVCB Liu, et al. Expires 22 September 2026 [Page 13] Internet-Draft Encrypted DNS SD March 2026 +--------+ +----------+ +------------+ +---------+ | Client | | mDNS | | Encrypted | | Router | | | | Responder| | DNS Resolver| | | +--------+ +----------+ +------------+ +---------+ | PTR Query (services) | | | |--------------------->| | | | PTR Response (instances) | | |<---------------------| | | | HTTPS Query (HomeDoH) | | |--------------------------------->| | | HTTPS Response (alpn,adn,path) | | |<---------------------------------| | | TLS Handshake (validate adn) | |--------------------------------------------------->| | Encrypted DNS Session Established | |<---------------------------------------------------| Figure 2: Client Discovery Sequence 9. References 9.1. Normative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . Liu, et al. Expires 22 September 2026 [Page 14] Internet-Draft Encrypted DNS SD March 2026 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . 9.2. Informative References [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, November 2023, . [I-D.ietf-add-ddr] Reddy.K, T., Boucadair, M., Cook, N., and D. Wing, "Discovery of Designated Resolvers", Work in Progress, Internet-Draft, draft-ietf-add-ddr-latest, . [IOT-DNS] ISOC, "IoT Device DNS Privacy Report", 2023. 9.3. Other References [RFC-TBD] Liu, D., Yan, Z., Geng, G., and G. Zeng, "DNS-Based Service Discovery for Encrypted DNS Services", RFC TBD, 2025, . Liu, et al. Expires 22 September 2026 [Page 15] Internet-Draft Encrypted DNS SD March 2026 Acknowledgements This work is supported by the National Key Research and Development Program of China (No. 2023YFB3105700). The authors would like to thank Stuart Cheshire, Chris Box, Tommy Jensen, Michel François, Lorenzo, Tommy Pauly, Jim Reid, Petr Menšík, Amanda Baber (IANA), Éric Vyncke and the ADD working group chairs for their valuable feedback during IETF 124 and on the mailing list. We also appreciate comments from other participants in the ADD working group. Authors' Addresses Dongjie Liu Jinan University Email: dongjieliu8917@gmail.com Zhiwei Yan CNNIC Email: yanzhiwei@cnnic.cn Guanggang Geng Jinan University Email: guanggang.geng@gmail.com G. Zeng Jinan University Email: zeng.guoqiang5@gmail.com Liu, et al. Expires 22 September 2026 [Page 16]