]> 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 multicast DNS (mDNS) and 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 TXT record parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This extension addresses critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763.

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.

Multicast DNS (mDNS, ) and DNS-Based Service Discovery (DNS-SD, ) 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: TXT records 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. Enterprise Network Segmentation: Departments can advertise isolated DNS services (e.g., _dot.finance.corp.local) with policy enforcement. 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).

While provides DHCP/RA-based encrypted DNS discovery, this mDNS-based approach offers complementary advantages: Relationship to Existing Standards

Capability	DHCP/RA	mDNS/DNS-SD (This Spec)
Infrastructure	Requires DHCP server/router	Works without infrastructure
Update Latency	Minutes-hours (lease time)	Seconds (event-driven)
Parameter Flexibility	Limited by option space	Rich TXT key-value pairs
Use Cases	Managed networks	Ad-hoc/IoT/dynamic networks

This document defines new DNS-SD service types (_dot._tcp, _doh._tcp, _doq._udp) and standardized TXT record parameters to enable seamless discovery of encrypted DNS services while maintaining backward compatibility with .

Key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" per BCP 14

• EDNS: Encrypted DNS (DoT, DoH, DoQ collectively)
• ADN: Authentication Domain Name (FQDN for certificate validation)
• Service Instance: Unique identifier for an EDNS 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 (default) or custom domain

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.

Defined Keys: TXT Records (Service Parameters)

Key	Format	Description	Example
path	String	DoH URI path (required for DoH)	path=/dns-query
alpn	Comma-list	Supported ALPN protocols	alpn=h2,h3
pri	Number	Selection priority (0-65535)	pri=10
fp_sha256	Hex string	Certificate SHA-256 fingerprint	fp_sha256=9F86D0...
domain	FQDN	ADN for certificate validation	domain=dns.corp.example

Full Example: HomeDoH._doh._tcp.local. 120 IN TXT "path=/dns" "alpn=h2" "domain=dns.home.net" "fp_sha256=9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08"

1. EDNS resolver sends mDNS broadcast:

_doh._tcp | |----------------------------------------->| | SRV HomeDoH._doh._tcp -> router:443 | |----------------------------------------->| | TXT path=/dns alpn=h2 | |----------------------------------------->| ]]>

1. Client queries for service types:
2. Query specific instances:
3. Resolve selected service:

• mDNS Response Validation: Clients MUST verify source IP matches query target
• Rate Limiting: Implement mDNS response rate limiting
• TLS Enforcement: Clients MUST validate server certificates against ADN or fingerprint

Certificate Validation Models

Trust Model	Verification Method	Use Case
Public PKI	ADN (domain= key) + CA validation	General-purpose networks
Fingerprint Pinning	fp_sha256 exact match	High-security/IoT devices
Private PKI	ADN + custom trust anchors	Enterprise networks

• Metadata Leakage: mDNS queries reveal client interest in encrypted DNS
• Mitigation: Clients SHOULD use service type enumeration (_services._dns-sd) before specific queries

This document requests IANA to register the following service types in the "DNS-SD Service Type Bindings" registry located at <https://www.iana.org/assignments/dns-sd/dns-sd.xhtml#service-types>. 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 as defined in RFC-TBD. 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 as defined in RFC-TBD. 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 as defined in RFC-TBD.

This document requests IANA to create a new registry titled "EDNS-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 priority	RFC-TBD
fp_sha256	Certificate SHA-256 fingerprint	RFC-TBD
domain	Authentication Domain Name (ADN)	RFC-TBD

New assignments in this registry require Expert Review as defined in . The expert should consider whether the proposed key is well-defined, does not duplicate existing functionality, and is relevant to encrypted DNS service discovery.

| | | | PTR Response | | | |<---------------| | | | SRV/TXT Query | | |-------------------------------->| | | SRV/TXT Response | | |<--------------------------------| | | TLS Handshake(validate certificate) | |------------------------------------------------->| | DoT Session Established | |<-------------------------------------------------| ]]>

This document provides guidelines to authors of Internet-Drafts on how to write an IANA Considerations section. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. ISOC Jinan University CNNIC Jinan University Jinan University This document defines a multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks.

This work is supported by the National Key Research and Development Program of China (No. 2023YFB3105700).