]> Jinan University

dongjieliu8917@gmail.com

CNNIC

yanzhiwei@cnnic.cn

Jinan University

guanggang.geng@gmail.com

Jinan University

zeng.guoqiang5@gmail.com

Internet Area ADD Working Group 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.

While encrypted DNS protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) 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, ) and its multicast variant (mDNS, ) 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.

defines DHCP and Router Advertisement options for encrypted DNS discovery (DNR), and 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: Comparison with Existing Encrypted DNS Discovery Mechanisms

Capability	DNR (RFC 9463)	DDR (RFC 9462)	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

• 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 (). The client MUST validate that the certificate's Subject Name matches this ADN per the procedures in .
• Service Instance: Unique identifier for an encrypted DNS resolver (e.g., Finance DoT._dot._tcp.local).

Encrypted DNS Service Types

Service Type	Protocol	Transport	Reference
_dot._tcp	DoT	TCP
_doh._tcp	DoH	TCP
_doq._udp	DoQ	UDP

<Instance>.<Service>.<Domain>

• 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.

.. [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 (), for DoH is 443 (), and for DoQ is 853 (). Per , SRV records MUST include a port value even when using the default port number.

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 . Legacy TXT Record Keys

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 (64 hex characters, no colons)	SHA‑256 fingerprint of the server certificate, encoded as a hexadecimal string without separators	fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08
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-query{?dns}" "alpn=h2" "adn=dns.home.net" "fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08"

Following , services SHOULD use SVCB (for DoT/DoQ) or HTTPS (for DoH) resource records to convey connection parameters. The SvcParam keys used are: 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 . 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. SVCB Parameters for Encrypted DNS

Key	Description	Example
port	Port number (if different from SRV or default)	port=443
alpn	ALPN protocol list (e.g., dot, doq, h2, h3)	alpn=h2,h3
dohpath	DoH URI template (for DoH only)	dohpath=/dns-query{?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 . 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.
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: For DoT, use SVCB (not HTTPS) with appropriate ALPN (e.g., "dot").

The discovery process follows the DNS-SD procedures defined in and, for mDNS, the multicast DNS mechanisms defined in . In particular, mDNS implementations SHOULD implement the Known‑Answer Suppression mechanism described in , Section 7.1. For large answer sets that span multiple packets, the multi‑packet Known‑Answer Suppression mechanism defined in , Section 7.2 SHOULD also be implemented.

1. Encrypted DNS resolver periodically announces its services via mDNS.
2. When an instance name conflict occurs (two hosts advertise the same <Instance> for the same service type), mDNS implementations SHOULD follow the conflict resolution procedures in , Section 9.

_doh._tcp | |----------------------------------------->| | HTTPS HomeDoH._doh._tcp -> alpn=h2, path=... | |----------------------------------------->| | (optionally SRV for legacy clients) | ]]>

For mDNS, TTL handling for individual resource records follows the requirements of . 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 . 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.

1. Client queries for service types:
2. Query specific instances:
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).
   2. If only SRV+TXT records are available, use the SRV priority and weight fields per .
   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 is authoritative when SVCB/HTTPS records are absent.
   The following DNS queries illustrate the resolution process:

This section discusses security and privacy considerations for encrypted DNS service discovery using DNS-SD and mDNS. Implementers should also consult for a comprehensive analysis of DNS-SD security requirements.

• 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 ) as the primary defense against spoofing.
• Rate Limiting: Implement mDNS response rate limiting per .
• 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. 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.

Certificate Validation Models

Trust Model	Verification Method	Use Case
Public PKI	Certificate subject‑alt‑name (or subject common‑name) matches ADN; certificate chain validates against public CA trust anchors	General‑purpose networks
Fingerprint Pinning	fp_sha256 exact match	High-security/IoT devices
Private PKI	Certificate subject‑alt‑name (or subject common‑name) matches ADN; certificate chain validates against private/custom trust anchors	Enterprise networks

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.

• 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.

When using DoQ resolvers discovered via DNS‑SD, implementers must follow all security requirements of . Clients need to pay attention to QUIC connection‑migration risks when operating within multi‑homed or Wi‑Fi roaming environments.

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. New DNS-SD Service Types

Service Name	Transport Protocol	Reference	Assignment Policy
dot	tcp		Standards Action
doh	tcp		Standards Action
doq	udp		Standards Action

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: 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: 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: 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 "Specification Required" as defined in . The initial contents of this registry are as follows: TXT Record Key Registry

Key	Meaning	Reference
path	HTTP URI path template
alpn	Supported ALPN protocols
pri	Service selection preference
fp_sha256	Certificate SHA-256 fingerprint
adn	Authentication Domain Name (ADN)

New assignments require Specification Required. Expert Review is RECOMMENDED but not required. This registry is primarily for compatibility; new implementations should use SVCB parameters as defined in .

The SVCB parameters defined in 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 , 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.

| | | | PTR Response (instances) | | |<---------------------| | | | HTTPS Query (HomeDoH) | | |--------------------------------->| | | HTTPS Response (alpn,dohpath) | | |<---------------------------------| | | TLS Handshake (validate adn) | |--------------------------------------------------->| | Encrypted DNS Session Established | |<---------------------------------------------------| ]]>

Normative References Informative References Jinan University CNNIC Jinan University Jinan University

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.