ADD Working Group D. Liu Internet-Draft Jinan University Intended status: Standards Track Z. Yan Expires: 25 March 2027 CNNIC G. Geng G. Zeng Jinan University 21 September 2026 DNS-Based Service Discovery for Encrypted DNS Services draft-liu-add-dnssd-edns-04 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._tcp, _doh._tcp, _doq._udp) and associated service parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This mechanism is defined for use with multicast DNS (mDNS), 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 25 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 25 March 2027 [Page 1] Internet-Draft Encrypted DNS SD September 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 1.5. Relationship to DNSSD . . . . . . . . . . . . . . . . . . 5 2. Terminology and Requirements . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 3. Service Type Definitions . . . . . . . . . . . . . . . . . . 6 3.1. Encrypted DNS Service Types . . . . . . . . . . . . . . . 6 3.2. Service Instance Name Format . . . . . . . . . . . . . . 6 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) . . . . . . . . . . . 7 4.4. SVCB/HTTPS Records for Service Parameters . . . . . . . . 8 5. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Service Advertisement . . . . . . . . . . . . . . . . . . 10 5.1.1. TTL, Caching and Service Teardown . . . . . . . . . . 11 5.2. Client Discovery . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1. Spoofing Countermeasures . . . . . . . . . . . . . . . . 12 6.2. Certificate Validation Models . . . . . . . . . . . . . . 14 6.3. Privacy Implications . . . . . . . . . . . . . . . . . . 15 6.4. DoQ-Specific Security Considerations . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. New DNS-SD Service Types . . . . . . . . . . . . . . . . 16 7.2. TXT Record Key Registry . . . . . . . . . . . . . . . . . 17 7.3. SVCB Parameters Usage . . . . . . . . . . . . . . . . . . 18 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Full DoT Service Advertisement with SVCB . . . . . . . . 18 8.2. DoH Service with Custom Path using HTTPS RR . . . . . . . 19 8.3. Client Discovery Sequence with SVCB . . . . . . . . . . . 19 9. Normative References . . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 20 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Liu, et al. Expires 25 March 2027 [Page 2] Internet-Draft Encrypted DNS SD September 2026 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. Liu, et al. Expires 25 March 2027 [Page 3] Internet-Draft Encrypted DNS SD September 2026 Enterprise Network Segmentation: Departments can advertise isolated DNS services (e.g., _dot.finance.corp.local) with policy enforcement, even in air-gapped segments. 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 [RFC9462] 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 for multicast-DNS-based zero-configuration environments. It operates without any supporting infrastructure. The following table summarizes the differences focusing on the mDNS operating mode: +================+===============+==========+======================+ | Capability | DNR (RFC |DDR (RFC | This Specification | | | 9463) |9462) | | +================+===============+==========+======================+ | Infrastructure | DHCP/RA |Recursive | None (zero- | | Required | server |DNS server| configuration) | +----------------+---------------+----------+----------------------+ | Update Latency | Minutes-hours |DNS TTL | Seconds (event- | | | (lease time) |dependent | driven) | +----------------+---------------+----------+----------------------+ | Parameter | Limited by |SVCB-based| SVCB-based | | Flexibility | option space | | | +----------------+---------------+----------+----------------------+ | Primary Use | Managed |Managed | Ad-hoc/IoT/dynamic/ | | Cases | networks |networks | isolated networks | | | |with DNS | | +----------------+---------------+----------+----------------------+ Table 1: Comparison with Existing Encrypted DNS Discovery Mechanisms Liu, et al. Expires 25 March 2027 [Page 4] Internet-Draft Encrypted DNS SD September 2026 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. 1.5. Relationship to DNSSD The underlying discovery mechanism used by this document is DNS-Based Service Discovery (DNS-SD, [RFC6763]) over multicast DNS (mDNS, [RFC6762]). A generic document describing the discovery of nearby DNS resolvers would naturally belong to the DNSSD working group. This document, however, is scoped to the zero-configuration discovery of encrypted DNS resolvers, and to the encrypted-DNS-specific parameters needed to discover and validate them: the DoT, DoH, and DoQ service types (_dot._tcp, _doh._tcp, and _doq._udp), ALPN negotiation, the DoH URI template (dohpath), and certificate validation via the ADN or fp_sha256 parameters. These encrypted-DNS- specific aspects are what distinguish this document from a generic resolver-discovery mechanism. This document therefore complements, rather than duplicates, the work of the DNSSD working group. If the ADD working group determines that the encrypted-DNS-specific aspects are not sufficient to keep the whole document in ADD, the generic mDNS discovery behavior could be moved to a DNSSD document, with this document retaining only the encrypted-DNS-specific parameters and validation requirements. 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): The Fully Qualified Domain Name (FQDN) that the client expects to find in the server's TLS certificate, as conveyed by the 'adn' key within TXT records (Section 4.3). The client MUST validate that the certificate's Subject Name matches this ADN per the procedures in [RFC6125]. * Service Instance: Unique identifier for an encrypted DNS resolver (e.g., Finance DoT._dot._tcp.local). Liu, et al. Expires 25 March 2027 [Page 5] Internet-Draft Encrypted DNS SD September 2026 3. Service Type Definitions 3.1. Encrypted DNS Service Types +==============+==========+===========+===========+ | Service Type | Protocol | Transport | Reference | +==============+==========+===========+===========+ | _dot._tcp | DoT | TCP | [THIS] | +--------------+----------+-----------+-----------+ | _doh._tcp | DoH | TCP | [THIS] | +--------------+----------+-----------+-----------+ | _doq._udp | DoQ | UDP | [THIS] | +--------------+----------+-----------+-----------+ 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: MUST be "local." for mDNS. Example: SecurityDoH._doh._tcp.local. 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: The hostname of the host offering the service. The client MUST resolve this hostname to an IP address via A or AAAA records before establishing a connection. If resolution fails, the client MUST discard this service instance. Liu, et al. Expires 25 March 2027 [Page 6] Internet-Draft Encrypted DNS SD September 2026 Example: HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local. The default port for DoT is 853 ([RFC7858]), for DoH is 443 ([RFC8484]), and for DoQ is 853 ([RFC9250]). Per [RFC2782], SRV records MUST include a port value even when using the default port number. 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 25 March 2027 [Page 7] Internet-Draft Encrypted DNS SD September 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 |SHA-256 |fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08| | |(64 hex |fingerprint of| | | |characters,|the server | | | |no colons) |certificate, | | | | |encoded as a | | | | |hexadecimal | | | | |string without| | | | |separators | | +---------+-----------+--------------+-------------------------------------------------------------------------+ |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-query{?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 25 March 2027 [Page 8] Internet-Draft Encrypted DNS SD September 2026 Clients MUST query the appropriate record type based on the service type being discovered: for _doh._tcp, clients MUST query the HTTPS RR; for _dot._tcp and _doq._udp, clients MUST query the SVCB RR. Clients SHOULD NOT query SVCB for _doh._tcp or HTTPS for _dot._tcp, as these are not defined by [RFC9460]. When processing records for the _doq._udp service type, clients MUST verify that the SVCB alpn SvcParam includes the doq ALPN identifier. If doq is absent, clients MUST discard this service instance. The transport protocol (UDP for DoQ) is derived solely from the DNS-SD service type label. If a client receives a resource-record type different than expected (e.g., receiving SVCB when querying HTTPS for _doh._tcp), the client MUST discard that entire service-instance response. +=========+===========================+==========================+ | Key | Description | Example | +=========+===========================+==========================+ | port | Port number (if different | port=443 | | | from SRV or default) | | +---------+---------------------------+--------------------------+ | alpn | ALPN protocol list (e.g., | alpn=h2,h3 | | | dot, doq, h2, h3) | | +---------+---------------------------+--------------------------+ | dohpath | DoH URI template (for DoH | dohpath=/dns-query{?dns} | | | only) | | +---------+---------------------------+--------------------------+ Table 4: SVCB Parameters for Encrypted DNS For DoH services, when the 'alpn' SvcParam contains 'h2' or 'h3', the 'dohpath' SvcParam MUST be present. If present h2/h3 but dohpath is omitted, clients MUST discard this DoH service instance. The dohpath value MUST follow the URI-template syntax defined in [RFC8484]. When both SVCB/HTTPS and SRV records exist for the same service instance, clients MUST apply the following precedence rules: 1. Priority: use priority value from SVCB/HTTPS, ignore SRV priority. 2. Target hostname: use target from SVCB/HTTPS, ignore SRV target. 3. Port: if the SVCB port SvcParam is present, use that value; otherwise use SRV port value; if SRV port is absent use protocol-specific default port. Liu, et al. Expires 25 March 2027 [Page 9] Internet-Draft Encrypted DNS SD September 2026 4. Weight: SVCB does not carry a weight field. When multiple SVCB/ HTTPS records share equal priority, clients SHOULD perform random-based load-balancing among those records. SRV weight values MUST be ignored when SVCB/HTTPS records are available. Clients MUST first check for SVCB or HTTPS records; if absent, they MAY fall back to SRV+TXT. When the SVCB port SvcParam is omitted, clients MUST use the protocol-specific default port: 853 for DoT, 443 for DoH, and 853 for DoQ. When both SVCB/HTTPS and TXT records are present, clients that support SVCB/HTTPS MUST use the SVCB/HTTPS record and MUST ignore the TXT record for configuration parameters. This includes ignoring the TXT-record 'pri' key. Service publishers that advertise both record types MUST ensure that the TXT record parameters are consistent with the SVCB/HTTPS record. If the parameters are inconsistent, clients that support SVCB/HTTPS MUST use the SVCB/HTTPS record. Publishers SHOULD be aware that legacy clients may consume the inconsistent TXT values. Example SVCB record for a DoH service: _doh._tcp.local. 7200 IN HTTPS 1 dns-home.local. alpn=h2,h3 dohpath=/dns-query{?dns} For DoT, use SVCB (not HTTPS) with appropriate ALPN (e.g., "dot"). 5. Discovery Process The discovery process follows the DNS-SD procedures defined in [RFC6763] and, for mDNS, the multicast DNS mechanisms defined in [RFC6762]. In particular, mDNS implementations SHOULD implement the Known-Answer Suppression mechanism described in [RFC6762], Section 7.1. For large answer sets that span multiple packets, the multi-packet Known-Answer Suppression mechanism defined in [RFC6762], Section 7.2 SHOULD also be implemented. 5.1. Service Advertisement 1. Encrypted DNS resolver periodically announces its services via mDNS. 2. When an instance name conflict occurs (two hosts advertise the same for the same service type), mDNS implementations SHOULD follow the conflict resolution procedures in [RFC6762], Section 9. Liu, et al. Expires 25 March 2027 [Page 10] Internet-Draft Encrypted DNS SD September 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.1.1. TTL, Caching and Service Teardown For mDNS, TTL handling for individual resource records follows the requirements of [RFC6762]. This specification does not override the per-resource-record TTL rules defined in RFC 6762. Each resource record (SVCB/HTTPS, SRV, TXT) maintains its own independent TTL in the client cache. For mDNS operation, service publishers MUST send DNS-SD goodbye messages when an encrypted DNS service becomes unavailable, following Section 10.1 of [RFC6762]. Clients receiving a goodbye message (TTL=0) for a service instance MUST set the TTL of that cached resource record to 1 second, and remove the cached service-instance entry once that 1-second period expires. 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. When multiple service instances are discovered, the client SHOULD select an instance based on the following priority order: 1. If SVCB/HTTPS records are present, use the SVCB priority field (lower value is more preferred). Liu, et al. Expires 25 March 2027 [Page 11] Internet-Draft Encrypted DNS SD September 2026 2. If only SRV+TXT records are available, use the SRV priority and weight fields per [RFC2782]. 3. If the TXT record contains a 'pri' key, it MAY be used as an additional weighting factor, but it MUST NOT override the SRV priority field. The SRV priority field per [RFC2782] is authoritative when SVCB/HTTPS records are absent. The following DNS queries illustrate the resolution process: ; 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 This section discusses security and privacy considerations for encrypted DNS service discovery using DNS-SD and mDNS. Implementers should also consult [RFC8882] for a comprehensive analysis of DNS-SD security requirements. 6.1. Spoofing Countermeasures Discovery is not authorization: mDNS is an unauthenticated link-local multicast protocol, and any node on the link can advertise any service instance. This document therefore treats discovery as candidate discovery, not as authorization: it provides candidates for an encrypted DNS resolver, and any trust decision remains with the client's local policy, which MUST anchor trust in pre-configured information or an equivalent out-of-band-established trust decision (see Section 6.2). * mDNS Response Validation: Clients SHOULD verify that mDNS responses are received from the link-local scope and SHOULD discard responses from non-local sources. However, this does not prevent spoofing attacks from other hosts on the same link; therefore, clients MUST rely on TLS certificate validation (see Section 6.2) as the primary defense against spoofing. * Rate Limiting: Implement mDNS response rate limiting per Section 11 of [RFC6762]. Liu, et al. Expires 25 March 2027 [Page 12] Internet-Draft Encrypted DNS SD September 2026 * TLS Enforcement: Clients MUST validate server certificates against the ADN (from the adn parameter) or the fingerprint (fp_sha256), subject to the pre-configured-trust requirement of Section 6.2. Instance count limits: To mitigate resource-exhaustion denial-of-service attacks from malicious link-local advertisers, clients SHOULD enforce a configurable upper bound on the total number of encrypted-DNS service instances processed per link. Clients SHOULD deduplicate service instances with identical instance name, target and parameters. Unreachable or repeatedly invalid service instances SHOULD be temporarily suppressed. Automatic usage policy: Whether mDNS discovery is performed at all is a deployment decision. A network designated as trusted via local configuration or administrative policy MAY be used as a gate that controls when discovery is considered, but it is a deployment policy gate, not a security mechanism. Unlike router advertisements (RAs), which trusted infrastructure can filter, mDNS is inherently peer-to- peer: there is no practical way to block malicious mDNS advertisements on a trusted network without disabling mDNS entirely. A trusted-network designation therefore never serves as the basis for trusting a discovered resolver. Clients MUST NOT automatically use an mDNS-discovered encrypted DNS resolver unless trust has been pre-configured (see Section 6.2). Pre-configured trust takes the form of a pre-configured certificate fingerprint (fp_sha256), a pre-configured ADN, or an equivalent out- of-band-established trust decision. In the pre-configured ADN case, the authorization comes from the pre-configured name itself, not from the PKI chain. Without such pre-configuration, clients MUST NOT use the discovered resolver automatically; use is possible only with explicit user confirmation, and this path carries residual risk. 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 the following measures: * Treat the designation of a network as trusted (e.g., home SSID, corporate network) only as a gate controlling whether discovery is considered at all; the designation does not make advertisements on that link trustworthy. * Require user confirmation before using a discovered resolver in the absence of pre-configured trust. * Require pre-configured trust (a pre-configured ADN or fp_sha256 fingerprint, or an equivalent out-of-band-established trust decision) for automatic use of a discovered resolver. Liu, et al. Expires 25 March 2027 [Page 13] Internet-Draft Encrypted DNS SD September 2026 6.2. Certificate Validation Models +=============+==============================+=====================+ | Trust Model | Verification Method | Use Case | +=============+==============================+=====================+ | Public PKI | Certificate subject-alt-name | General-purpose | | | (or subject common-name) | networks; automatic | | | matches ADN; certificate | use additionally | | | chain validates against | requires the ADN to | | | public CA trust anchors | be pre-configured | | | | (see below) | +-------------+------------------------------+---------------------+ | Fingerprint | fp_sha256 exact match | High-security/IoT | | Pinning | | devices | +-------------+------------------------------+---------------------+ | Private PKI | Certificate subject-alt-name | Enterprise networks | | | (or subject common-name) | | | | matches ADN; certificate | | | | chain validates against | | | | private/custom trust anchors | | +-------------+------------------------------+---------------------+ Table 5: Certificate Validation Models Certificate validation verifies that the server certificate matches the identity claimed in the service advertisement; it does not, by itself, authorize the resolver. In particular, validating a certificate against a public PKI trust anchor using an ADN learned from the same unauthenticated mDNS advertisement does not provide authorization, because the ADN is not anchored in pre-configured trust. For automatic use of a discovered resolver, pre-configured trust is REQUIRED: a pre-configured certificate fingerprint (fp_sha256), a pre-configured ADN (in which case the authorization comes from the pre-configured name itself, not from the PKI chain), or an equivalent out-of-band-established trust decision (e.g., scanning a QR code that encodes the fingerprint or ADN). In air-gapped or offline networks where OCSP and CRL revocation resources are unreachable, clients MAY provide administrative configuration to disable certificate-revocation checking. Revocation checking MUST remain enabled by default; this requirement applies to factory-default settings and MAY be overridden via explicit administrative configuration. Disabling revocation checks increases exposure to compromised certificates and SHOULD be used with caution. Trust anchors used for these environments SHOULD be configured via out-of-band means. Liu, et al. Expires 25 March 2027 [Page 14] Internet-Draft Encrypted DNS SD September 2026 When both adn and fp_sha256 are present in the TXT record of a service instance, clients MUST apply the combined validation rule consistently with the pre-configured-trust requirement above: automatic use is permitted only if at least one of the two values is anchored by pre-configured trust or an equivalent out-of-band- established trust decision, and the corresponding validation check succeeds. Implementations MAY provide an optional configuration mode requiring both checks to pass for enhanced security. With pre-configured trust in place, the primary remaining security risk introduced by the discovery mechanism itself is availability of discovery (for example, an on-link attacker could suppress or flood mDNS advertisements); it does not affect the authenticity of an accepted resolver, because acceptance still requires a certificate that matches the pre-configured trust anchor. The mechanism therefore does not reach the security ceiling of infrastructure-based discovery (e.g., [RFC9463]), and the intended deployment scenarios are those without such infrastructure. 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._udp) before specific queries to reduce leakage. * Broadcast of service metadata: Service advertisements transmitted over mDNS expose service instance metadata including ADN values and certificate fingerprints to any passive eavesdropper on the local link. No mitigation is defined for this exposure; operators should be aware of this disclosure property. * Note that this specification defines only a resolver-discovery mechanism. It does *not* provide any privacy protection for DNS query contents sent to the discovered encrypted DNS resolvers. Liu, et al. Expires 25 March 2027 [Page 15] Internet-Draft Encrypted DNS SD September 2026 6.4. DoQ-Specific Security Considerations When using DoQ resolvers discovered via DNS-SD, implementers must follow all security requirements of [RFC9250]. Clients need to pay attention to QUIC connection-migration risks when operating within multi-homed or Wi-Fi roaming environments. 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 | [THIS] | Standards | | | | | Action | +--------------+--------------------+-----------+-------------------+ | doh | tcp | [THIS] | Standards | | | | | Action | +--------------+--------------------+-----------+-------------------+ | doq | udp | [THIS] | Standards | | | | | Action | +--------------+--------------------+-----------+-------------------+ 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: [THIS] Assignment Notes: This service type is used for discovering encrypted DNS services. The corresponding DNS-SD type is _dot._tcp. Liu, et al. Expires 25 March 2027 [Page 16] Internet-Draft Encrypted DNS SD September 2026 Service Name: doh Transport Protocol(s): tcp Assignee: IESG Contact: IESG Description: DNS over HTTPS (DoH) Resolver Service Discovery Reference: [THIS] 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: [THIS] 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 "Specification Required" as defined in [RFC8126]. The initial contents of this registry are as follows: Liu, et al. Expires 25 March 2027 [Page 17] Internet-Draft Encrypted DNS SD September 2026 +===========+==================================+===========+ | Key | Meaning | Reference | +===========+==================================+===========+ | path | HTTP URI path template | [THIS] | +-----------+----------------------------------+-----------+ | alpn | Supported ALPN protocols | [THIS] | +-----------+----------------------------------+-----------+ | pri | Service selection preference | [THIS] | +-----------+----------------------------------+-----------+ | fp_sha256 | Certificate SHA-256 fingerprint | [THIS] | +-----------+----------------------------------+-----------+ | adn | Authentication Domain Name (ADN) | [THIS] | +-----------+----------------------------------+-----------+ Table 7: TXT Record Key Registry New assignments require [RFC8126] Specification Required. Expert Review is RECOMMENDED but not required. 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.Note that the 'mandatory' SvcParamKey (key 0) as defined in [RFC9460], Section 8, is not used by this specification. Clients that do not understand a SvcParam listed in 'mandatory' MUST treat the SVCB/HTTPS record as unusable for that service. 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 ; 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 Liu, et al. Expires 25 March 2027 [Page 18] Internet-Draft Encrypted DNS SD September 2026 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{?dns} 8.3. Client Discovery Sequence with SVCB +--------+ +----------+ +------------+ +---------+ | Client | | mDNS | | Encrypted | | Router | | | | Responder| | DNS Resolver| | | +--------+ +----------+ +------------+ +---------+ | PTR Query (services) | | | |--------------------->| | | | PTR Response (instances) | | |<---------------------| | | | HTTPS Query (HomeDoH) | | |--------------------------------->| | | HTTPS Response (alpn,dohpath) | | |<---------------------------------| | | TLS Handshake (validate adn) | |--------------------------------------------------->| | Encrypted DNS Session Established | |<---------------------------------------------------| Figure 2: Client Discovery Sequence 9. Normative References [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity in TLS", RFC 6125, March 2011, . [RFC8882] Cheshire, D. and S. Cheshire, "DNS-Based Service Discovery (DNS-SD) Security and Privacy Requirements", RFC 8882, October 2020, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, . [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, . Liu, et al. Expires 25 March 2027 [Page 19] Internet-Draft Encrypted DNS SD September 2026 [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, . [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, . 10. Informative References Liu, et al. Expires 25 March 2027 [Page 20] Internet-Draft Encrypted DNS SD September 2026 [THIS] Liu, D., Yan, Z., Geng, G., and G. Zeng, "DNS-Based Service Discovery for Encrypted DNS Services", Work in Progress, Internet-Draft, draft-liu-add-dnssd-edns-04, 21 September 2026, . [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, . [RFC9462] Pauly, T., Kinnear, E., Wood, C.A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, November 2023, . Change Log Changes from draft-liu-add-dnssd-edns-03: * Made the discovery-is-not-authorization boundary explicit and required trust anchoring in pre-configured information or an equivalent out-of-band-established trust decision. * Added a Relationship to DNSSD subsection to clarify the scope and relationship of the encrypted-DNS-specific aspects to generic DNSSD work. * Reframed the trusted-network concept as a deployment policy gate rather than a security mechanism. * Required pre-configured trust for automatic use of an mDNS- discovered encrypted DNS resolver and clarified the residual risk of user-confirmed use without such trust. * Clarified that certificate validation alone does not authorize a resolver and aligned the combined adn/fp_sha256 validation rule with the pre-configured-trust requirement. Acknowledgements This work is supported by the National Key Research and Development Program of China (No. 2023YFB3105700). Liu, et al. Expires 25 March 2027 [Page 21] Internet-Draft Encrypted DNS SD September 2026 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 25 March 2027 [Page 22]