ADD Working Group D. Liu Internet-Draft Jinan University Intended status: Standards Track Z. Yan Expires: 17 March 2027 CNNIC G. Geng G. Zeng Jinan University 13 September 2026 DNS-Based Service Discovery for Encrypted DNS Services draft-liu-add-dnssd-edns-03 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 17 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 17 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 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 . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Service Advertisement . . . . . . . . . . . . . . . . . . 9 5.1.1. TTL, Caching and Service Teardown . . . . . . . . . . 10 5.2. Client Discovery . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Spoofing Countermeasures . . . . . . . . . . . . . . . . 11 6.2. Certificate Validation Models . . . . . . . . . . . . . . 12 6.3. Privacy Implications . . . . . . . . . . . . . . . . . . 13 6.4. DoQ-Specific Security Considerations . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.1. New DNS-SD Service Types . . . . . . . . . . . . . . . . 14 7.2. TXT Record Key Registry . . . . . . . . . . . . . . . . . 15 7.3. SVCB Parameters Usage . . . . . . . . . . . . . . . . . . 16 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Full DoT Service Advertisement with SVCB . . . . . . . . 16 8.2. DoH Service with Custom Path using HTTPS RR . . . . . . . 17 8.3. Client Discovery Sequence with SVCB . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Liu, et al. Expires 17 March 2027 [Page 2] Internet-Draft Encrypted DNS SD September 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 17 March 2027 [Page 3] Internet-Draft Encrypted DNS SD September 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 [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 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 17 March 2027 [Page 4] Internet-Draft Encrypted DNS SD September 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): 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). 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. Liu, et al. Expires 17 March 2027 [Page 5] Internet-Draft Encrypted DNS SD September 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: 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. 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 17 March 2027 [Page 6] 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 17 March 2027 [Page 7] 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 17 March 2027 [Page 8] 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 17 March 2027 [Page 9] 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 17 March 2027 [Page 10] 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 * 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]. * TLS Enforcement: Clients MUST validate server certificates against the ADN (from adn parameter) or the fingerprint (fp_sha256). 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. Liu, et al. Expires 17 March 2027 [Page 11] Internet-Draft Encrypted DNS SD September 2026 Automatic usage policy: Clients MUST NOT automatically use mDNS-discovered encrypted DNS resolvers unless the attached network has been explicitly designated as trusted via local configuration or administrative policy. On untrusted networks, explicit user confirmation is REQUIRED before using any discovered resolver. 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 | Certificate subject-alt-name (or | General-purpose | | | subject common-name) matches | networks | | | ADN; certificate chain validates | | | | against public CA trust anchors | | +-------------+----------------------------------+-----------------+ | Fingerprint | fp_sha256 exact match | High-security/ | | Pinning | | IoT devices | +-------------+----------------------------------+-----------------+ | Private PKI | Certificate subject-alt-name (or | Enterprise | | | subject common-name) matches | networks | | | ADN; certificate chain validates | | | | against private/custom trust | | | | anchors | | +-------------+----------------------------------+-----------------+ Table 5: Certificate Validation Models Liu, et al. Expires 17 March 2027 [Page 12] Internet-Draft Encrypted DNS SD September 2026 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. When both adn and fp_sha256 are present in the TXT record of a service instance, clients MUST accept the service if at least one of the two validation checks succeeds. Implementations MAY provide an optional configuration mode requiring both checks to pass for enhanced security. 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. 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. Liu, et al. Expires 17 March 2027 [Page 13] Internet-Draft Encrypted DNS SD September 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 | [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. Service Name: doh Transport Protocol(s): tcp Assignee: IESG Liu, et al. Expires 17 March 2027 [Page 14] Internet-Draft Encrypted DNS SD September 2026 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 17 March 2027 [Page 15] 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 17 March 2027 [Page 16] 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 17 March 2027 [Page 17] 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 17 March 2027 [Page 18] 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-03, 13 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, . 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 17 March 2027 [Page 19]