DNS-Based Service Discovery for Encrypted DNS Services

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

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:¶

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

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.1. Encrypted DNS Service Types

3.2. Service Instance Name Format

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

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)

<Instance>.<Service>.<Domain> [Class] [TTL] SRV <Priority> <Weight> <Port> <Target>¶

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

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 <Instance> for the same service type), mDNS implementations SHOULD follow the conflict resolution procedures in [RFC6762], Section 9.¶

   +--------------+                       +------------------+
   |   Resolver   |                       |      Network     |
   +--------------+                       +------------------+
           | PTR _services._dns-sd._udp -> _doh._tcp  |
           |----------------------------------------->|
           | HTTPS HomeDoH._doh._tcp  -> alpn=h2, path=... |
           |----------------------------------------->|
           | (optionally SRV for legacy clients)       |

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).¶

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

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

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

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