]> 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, _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.

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 that operates without any infrastructure, making it ideal for ad-hoc, isolated, or zero-configuration environments. The following table summarizes the differences: Comparison with Existing Encrypted DNS Discovery Mechanisms

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

• Encrypted DNS: Collective term for DoT, DoH, and DoQ.
• ADN: Authentication Domain Name (FQDN for certificate validation).
• Service Instance: Unique identifier for an encrypted DNS resolver (e.g., Finance DoT._dot._tcp.local).

Encrypted DNS Service Types

Service Type	Protocol	Transport	IANA Assignment
_dot._tcp	DoT	TCP	REQUIRED
_doh._tcp	DoH	TCP	REQUIRED
_doq._udp	DoQ	UDP	REQUIRED

<Instance>.<Service>.<Domain>

• Instance: Human-readable identifier (e.g., CorpDNS, HomeGateway).
• Service: One of _dot._tcp, _doh._tcp, _doq._udp.
• Domain: "local." for mDNS, or any domain for unicast DNS-SD.

Example: SecurityDoH._doh._tcp.local.

.. [Class] [TTL] SRV ]]>

• Target: Hostname offering the service (A/AAAA must resolve).

Example: HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local.

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

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: For DoT, use SVCB (not HTTPS) with appropriate ALPN (e.g., "dot").

1. Encrypted DNS resolver periodically announces its services via mDNS (or unicast DNS update).

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

1. Client queries for service types:
2. Query specific instances:
3. Resolve selected service: first request SVCB/HTTPS, fallback to SRV+TXT.

• mDNS Response Validation: Clients MUST verify source IP matches query target (link-local scope).
• 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).
• Clients SHOULD NOT automatically trust discovered services; user confirmation or policy (e.g., only on trusted networks) is RECOMMENDED.

In open or untrusted networks (e.g., public Wi-Fi), malicious devices may advertise fake encrypted DNS services. To mitigate such risks, clients SHOULD adopt additional trust considerations:

• Only auto-discover on networks designated as trusted (e.g., home SSID, corporate network).
• Require user confirmation before using a discovered resolver.
• Allow administrators to pre-configure trusted ADNs or fingerprints.

Certificate Validation Models

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.

• Metadata Leakage: mDNS queries reveal client interest in encrypted DNS.
• Mitigation: Clients SHOULD use service type enumeration (_services._dns-sd) before specific queries to reduce leakage. In unicast DNS-SD, queries are not broadcast.

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

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 .

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.

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

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