DNS-Based Service Discovery for Encrypted DNS Services
draft-liu-add-dnssd-edns-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dongjie Liu , Zhiwei Yan , Guanggang Geng , Guoqiang Zeng | ||
| Last updated | 2026-03-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-add-dnssd-edns-02
ADD Working Group D. Liu
Internet-Draft Jinan University
Intended status: Informational Z. Yan
Expires: 22 September 2026 CNNIC
G. Geng
G. Zeng
Jinan University
21 March 2026
DNS-Based Service Discovery for Encrypted DNS Services
draft-liu-add-dnssd-edns-02
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires 22 September 2026 [Page 1]
Internet-Draft Encrypted DNS SD March 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Local Network Privacy Challenge . . . . . . . . . . . 3
1.2. DNS-SD as a Solution for Privacy-Aware Discovery . . . . 3
1.3. Key Use Cases . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Relationship to Existing Standards . . . . . . . . . . . 4
2. Terminology and Requirements . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Service Type Definitions . . . . . . . . . . . . . . . . . . 5
3.1. Encrypted DNS Service Types . . . . . . . . . . . . . . . 5
3.2. Service Instance Name Format . . . . . . . . . . . . . . 5
4. DNS Resource Records . . . . . . . . . . . . . . . . . . . . 6
4.1. PTR Records (Service Discovery) . . . . . . . . . . . . . 6
4.2. SRV Records (Service Location) . . . . . . . . . . . . . 6
4.3. TXT Records (Legacy Compatibility) . . . . . . . . . . . 6
4.4. SVCB/HTTPS Records for Service Parameters . . . . . . . . 7
5. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Advertisement . . . . . . . . . . . . . . . . . . 8
5.2. Client Discovery . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Spoofing Countermeasures . . . . . . . . . . . . . . . . 9
6.2. Certificate Validation Models . . . . . . . . . . . . . . 10
6.3. Privacy Implications . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. New DNS-SD Service Types . . . . . . . . . . . . . . . . 11
7.2. TXT Record Key Registry . . . . . . . . . . . . . . . . . 12
7.3. SVCB Parameters Usage . . . . . . . . . . . . . . . . . . 13
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Full DoT Service Advertisement with SVCB . . . . . . . . 13
8.2. DoH Service with Custom Path using HTTPS RR . . . . . . . 13
8.3. Client Discovery Sequence with SVCB . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
9.3. Other References . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Liu, et al. Expires 22 September 2026 [Page 2]
Internet-Draft Encrypted DNS SD March 2026
1. Introduction
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.
Liu, et al. Expires 22 September 2026 [Page 3]
Internet-Draft Encrypted DNS SD March 2026
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 [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 | DDR (draft- | This |
| | 9463) | ietf-add- | Specification |
| | | ddr) | |
+================+==============+===============+===================+
| Infrastructure | DHCP/RA | Recursive | None (zero- |
| Required | server | DNS server | configuration) |
+----------------+--------------+---------------+-------------------+
| Update Latency | Minutes- | DNS TTL | Seconds (event- |
| | hours (lease | dependent | driven) |
| | time) | | |
+----------------+--------------+---------------+-------------------+
| Parameter | Limited by | SVCB-based | SVCB-based |
| Flexibility | option space | | |
+----------------+--------------+---------------+-------------------+
| Primary Use | Managed | Managed | Ad- |
| Cases | networks | networks | hoc/IoT/dynamic/ |
| | | with DNS | isolated networks |
+----------------+--------------+---------------+-------------------+
Table 1: Comparison with Existing Encrypted DNS Discovery Mechanisms
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.
Liu, et al. Expires 22 September 2026 [Page 4]
Internet-Draft Encrypted DNS SD March 2026
2. Terminology and Requirements
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 (FQDN for certificate validation).
* Service Instance: Unique identifier for an encrypted DNS resolver
(e.g., Finance DoT._dot._tcp.local).
3. Service Type Definitions
3.1. 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 |
+--------------+----------+-----------+-----------------+
Table 2: 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: "local." for mDNS, or any domain for unicast DNS-SD.
Example: SecurityDoH._doh._tcp.local.
Liu, et al. Expires 22 September 2026 [Page 5]
Internet-Draft Encrypted DNS SD March 2026
4. DNS Resource Records
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: Hostname offering the service (A/AAAA must resolve).
Example:
HomeDoT._dot._tcp.local. 120 IN SRV 0 5 853 router.home.local.
4.3. TXT Records (Legacy Compatibility)
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.
Liu, et al. Expires 22 September 2026 [Page 6]
Internet-Draft Encrypted DNS SD March 2026
+===========+============+===================+======================+
| Key | Format | Description | Example |
+===========+============+===================+======================+
| path | String | DoH URI path | path=/dns-query |
| | | (required for | |
| | | DoH when using | |
| | | TXT) | |
+-----------+------------+-------------------+----------------------+
| alpn | Comma-list | Supported ALPN | alpn=h2,h3 |
| | | protocols | |
+-----------+------------+-------------------+----------------------+
| pri | Number | Service | pri=10 |
| | | selection | |
| | | preference | |
| | | (0-65535), | |
| | | lower is more | |
| | | preferred | |
+-----------+------------+-------------------+----------------------+
| fp_sha256 | Hex string | Certificate | fp_sha256=9F86D0... |
| | | SHA-256 | |
| | | fingerprint | |
| | | (optional if | |
| | | ADN used) | |
+-----------+------------+-------------------+----------------------+
| adn | FQDN | Authentication | adn=dns.corp.example |
| | | Domain Name | |
| | | for | |
| | | certificate | |
| | | validation | |
+-----------+------------+-------------------+----------------------+
Table 3: Legacy TXT Record Keys
Full Example (TXT-based):
HomeDoH._doh._tcp.local. 120 IN TXT "path=/dns" "alpn=h2"
"adn=dns.home.net"
"fp_sha256=9F86D081884C7D659A2FEA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08"
4.4. SVCB/HTTPS Records for Service Parameters
Following [RFC9460], services SHOULD use SVCB (for DoT/DoQ) or HTTPS
(for DoH) resource records to convey connection parameters. The
SvcParam keys used are:
Liu, et al. Expires 22 September 2026 [Page 7]
Internet-Draft Encrypted DNS SD March 2026
+===========+===========================+==========================+
| Key | Description | Example |
+===========+===========================+==========================+
| port | Port number (if different | port=443 |
| | from SRV or default) | |
+-----------+---------------------------+--------------------------+
| alpn | ALPN protocol list. When | alpn=h2,h3 |
| | containing HTTP versions | |
| | (h2, h3), the 'dohpath' | |
| | key MUST be present. | |
+-----------+---------------------------+--------------------------+
| dohpath | DoH URI template (for DoH | dohpath=/dns-query{?dns} |
| | only) | |
+-----------+---------------------------+--------------------------+
| adn | Authentication Domain | adn=dns.example.com |
| | Name | |
+-----------+---------------------------+--------------------------+
| fp_sha256 | Certificate SHA-256 | fp_sha256=9F86D0... |
| | fingerprint (alternative | |
| | to adn) | |
+-----------+---------------------------+--------------------------+
Table 4: SVCB Parameters for Encrypted DNS
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").
5. Discovery Process
5.1. Service Advertisement
1. Encrypted DNS resolver periodically announces its services via
mDNS (or unicast DNS update).
Liu, et al. Expires 22 September 2026 [Page 8]
Internet-Draft Encrypted DNS SD March 2026
+--------------+ +------------------+
| Resolver | | Network |
+--------------+ +------------------+
| PTR _services._dns-sd._udp -> _doh._tcp |
|----------------------------------------->|
| HTTPS HomeDoH._doh._tcp -> alpn=h2, path=... |
|----------------------------------------->|
| (optionally SRV for legacy clients) |
Figure 1: Example mDNS Advertisement with SVCB
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.
; 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. Security Considerations
6.1. Spoofing Countermeasures
* mDNS Response Validation: Clients MUST verify source IP matches
query target (link-local scope).
* 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).
Liu, et al. Expires 22 September 2026 [Page 9]
Internet-Draft Encrypted DNS SD March 2026
* 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.
6.2. Certificate Validation Models
+=============+=====================+==========================+
| Trust Model | Verification Method | Use Case |
+=============+=====================+==========================+
| Public PKI | ADN + CA validation | General-purpose networks |
+-------------+---------------------+--------------------------+
| Fingerprint | fp_sha256 exact | High-security/IoT |
| Pinning | match | devices |
+-------------+---------------------+--------------------------+
| Private PKI | ADN + custom trust | Enterprise networks |
| | anchors | |
+-------------+---------------------+--------------------------+
Table 5: Certificate Validation Models
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.
6.3. Privacy Implications
* 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.
Liu, et al. Expires 22 September 2026 [Page 10]
Internet-Draft Encrypted DNS SD March 2026
7. IANA Considerations
7.1. New DNS-SD Service Types
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 |
+--------------+--------------------+-----------+-------------------+
Table 6: New DNS-SD Service Types
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
Liu, et al. Expires 22 September 2026 [Page 11]
Internet-Draft Encrypted DNS SD March 2026
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.
7.2. TXT Record Key Registry
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 |
+-----------+----------------------------------+-----------+
Table 7: TXT Record Key Registry
Liu, et al. Expires 22 September 2026 [Page 12]
Internet-Draft Encrypted DNS SD March 2026
New assignments require Expert Review. This registry is primarily
for compatibility; new implementations should use SVCB parameters as
defined in [RFC9460].
7.3. SVCB Parameters Usage
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.
8. Examples
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 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
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 adn=dns.corp.example
8.3. Client Discovery Sequence with SVCB
Liu, et al. Expires 22 September 2026 [Page 13]
Internet-Draft Encrypted DNS SD March 2026
+--------+ +----------+ +------------+ +---------+
| 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 |
|<---------------------------------------------------|
Figure 2: Client Discovery Sequence
9. References
9.1. Normative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
Liu, et al. Expires 22 September 2026 [Page 14]
Internet-Draft Encrypted DNS SD March 2026
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
9.2. Informative References
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
[I-D.ietf-add-ddr]
Reddy.K, T., Boucadair, M., Cook, N., and D. Wing,
"Discovery of Designated Resolvers", Work in Progress,
Internet-Draft, draft-ietf-add-ddr-latest,
<https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-
latest>.
[IOT-DNS] ISOC, "IoT Device DNS Privacy Report", 2023.
9.3. Other References
[RFC-TBD] Liu, D., Yan, Z., Geng, G., and G. Zeng, "DNS-Based
Service Discovery for Encrypted DNS Services", RFC TBD,
2025, <https://www.rfc-editor.org/rfc/rfcTBD>.
Liu, et al. Expires 22 September 2026 [Page 15]
Internet-Draft Encrypted DNS SD March 2026
Acknowledgements
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.
Authors' Addresses
Dongjie Liu
Jinan University
Email: dongjieliu8917@gmail.com
Zhiwei Yan
CNNIC
Email: yanzhiwei@cnnic.cn
Guanggang Geng
Jinan University
Email: guanggang.geng@gmail.com
G. Zeng
Jinan University
Email: zeng.guoqiang5@gmail.com
Liu, et al. Expires 22 September 2026 [Page 16]