| Internet-Draft | Encrypted DNS SD | March 2026 |
| Liu, et al. | Expires 22 September 2026 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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).¶
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.¶
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.¶
[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 9463) | DDR (draft-ietf-add-ddr) | This Specification |
|---|---|---|---|
| Infrastructure Required | DHCP/RA server | Recursive DNS server | None (zero-configuration) |
| Update Latency | Minutes-hours (lease time) | DNS TTL dependent | Seconds (event-driven) |
| Parameter Flexibility | Limited by option space | SVCB-based | SVCB-based |
| Primary Use Cases | Managed networks | Managed networks with DNS | Ad-hoc/IoT/dynamic/isolated networks |
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.¶
Key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" per BCP 14 [RFC2119] [RFC8174]¶
| Service Type | Protocol | Transport | IANA Assignment |
|---|---|---|---|
| _dot._tcp | DoT | TCP | REQUIRED |
| _doh._tcp | DoH | TCP | REQUIRED |
| _doq._udp | DoQ | UDP | REQUIRED |
<Instance>.<Service>.<Domain>¶
Example: SecurityDoH._doh._tcp.local.¶
; 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
¶
<Instance>.<Service>.<Domain> [Class] [TTL] SRV <Priority> <Weight> <Port> <Target>¶
Example:¶
HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local.¶
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.¶
| Key | Format | Description | Example |
|---|---|---|---|
| path | String | DoH URI path (required for DoH when using TXT) | path=/dns-query |
| alpn | Comma-list | Supported ALPN protocols | alpn=h2,h3 |
| pri | Number | Service selection preference (0-65535), lower is more preferred | pri=10 |
| fp_sha256 | Hex string | Certificate SHA-256 fingerprint (optional if ADN used) | fp_sha256=9F86D0... |
| adn | FQDN | Authentication Domain Name for certificate validation | adn=dns.corp.example |
Full Example (TXT-based):¶
HomeDoH._doh._tcp.local. 120 IN TXT "path=/dns" "alpn=h2" "adn=dns.home.net" "fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08"¶
Following [RFC9460], services SHOULD use SVCB (for DoT/DoQ) or HTTPS (for DoH) resource records to convey connection parameters. The SvcParam keys used are:¶
| Key | Description | Example |
|---|---|---|
| port | Port number (if different from SRV or default) | port=443 |
| alpn | ALPN protocol list. When containing HTTP versions (h2, h3), the 'dohpath' key MUST be present. | alpn=h2,h3 |
| dohpath | DoH URI template (for DoH only) | dohpath=/dns-query{?dns} |
| adn | Authentication Domain Name | adn=dns.example.com |
| fp_sha256 | Certificate SHA-256 fingerprint (alternative to adn) | fp_sha256=9F86D0... |
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").¶
+--------------+ +------------------+
| Resolver | | Network |
+--------------+ +------------------+
| PTR _services._dns-sd._udp -> _doh._tcp |
|----------------------------------------->|
| HTTPS HomeDoH._doh._tcp -> alpn=h2, path=... |
|----------------------------------------->|
| (optionally SRV for legacy clients) |
Client queries for service types:¶
; Query available encrypted DNS services
_services._dns-sd._udp.local. IN PTR
¶
Query specific instances:¶
; Query DoH instances
_doh._tcp.local. IN PTR
¶
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
¶
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:¶
| Trust Model | Verification Method | Use Case |
|---|---|---|
| Public PKI | ADN + CA validation | General-purpose networks |
| Fingerprint Pinning | fp_sha256 exact match | High-security/IoT devices |
| Private PKI | ADN + custom trust anchors | Enterprise networks |
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.¶
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 |
The registration templates for these service types are as follows:¶
Service Name: dot¶
Transport Protocol(s): tcp¶
Assignee: IESG <iesg@ietf.org>¶
Contact: IESG <iesg@ietf.org>¶
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 <iesg@ietf.org>¶
Contact: IESG <iesg@ietf.org>¶
Description: DNS over HTTPS (DoH) Resolver Service Discovery¶
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 <iesg@ietf.org>¶
Contact: IESG <iesg@ietf.org>¶
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.¶
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 |
New assignments require Expert Review. This registry is primarily for compatibility; new implementations should use SVCB parameters as defined in [RFC9460].¶
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.¶
; 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
¶
OfficeDoH._doh._tcp.local. 7200 IN HTTPS 1 dnsgateway.corp.local. alpn=h2,h3 dohpath=/internal/dns adn=dns.corp.example¶
+--------+ +----------+ +------------+ +---------+
| 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 |
|<---------------------------------------------------|
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.¶