]> The Swedish Internet Foundation

leon.fernandez@internetstiftelsen.se

Mozilla

ietf.valentin@gosu.se

OPS DNSOP DNS Privacy This document describes an EDNS0 option that a client can attach to a DNS query to signal to a recursive resolver that it SHOULD prefer encrypted transports while resolving the query. The option can also be used on the return path by the resolver to signal whether encryption was achievable or not. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the DNSOP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A DNS client can choose what protocol to use when it sends a query to a resolver. There are several privacy-friendly options that the client can choose between such as HTTPS , QUIC and TLS . However, the choice only affects the first hop and the query will typically be sent in cleartext by the resolver during the resolution process. In order to preserve the privacy of the client beyond the first hop, the client SHOULD be able to signal a desire that the resolver uses encrypted transports during the resolution process. Furthermore, the client SHOULD be informed of how the resolution was carried out, in case it would like to discard data that was not received over an encrypted transport. This document defines an EDNS0 option that allows a client to signal a preference for encrypted authoritative DNS (ADoX). By signalling a preference, the client can urge a recursive resolver to discover possibilities for encrypted transport. Means of discovery include, but are not limited to, , and . The signal from the client can also prevent the recursive resolver from leaking queries that would otherwise have been sent in cleartext. The same EDNS0 option can also be used on the return path so that the recursive resolver can give an indication to the client about what level of privacy was achieved for a particular query.

Terminology Client: A stub resolver as defined in or some other software, such as a browser, is close to the end-user and sends recursice DNS queries. Resolver: As defined in . ADoX: Authoritative DNS-over-X, where X implies some arbitrary encrypted transport protocol.

The EDNS0 PRIVACY Option The EDNS0 PRIVACY option is structured as follows: Field definition details: OPTION-CODE: The EDNS0 option code for client-privacy-signal, defined as TBD1. OPTION-LENGTH: The option length MUST have a value of 2 if this option is present. Consumers of this signal SHOULD NOT act on malformed options. PRIVACY REQUEST: This value encodes the client's desired level of privacy. Currently defined values are listed in . In a DNS response, the recipient MUST ignore this field and the sender SHOULD set it to 0. PRIVACY RESPONSE: This value encodes the level of privacy that the resolver was able to achieve. Currently defined values are listed in . In a DNS query, the recipient MUST ignore this field and the sender SHOULD set it to 0.

PRIVACY REQUEST Values

Value	Mnemonic
0	NONE
1	OPPORTUNISTIC
2	OPPORTUNISTIC-NO-FALLBACK
3	STRICT

PRIVACY RESPONSE Values

Value	Mnemonic
0	CLEARTEXT
1	ENCRYPTED
2	CACHED
3	AUTHENTICATED

Interpretations of Privacy Request Values

NONE Same effect as having no client signal at all. No privacy requested by the client that is sending the query.

OPPORTUNISTIC The client is requesting a preference for resolving the query using encrypted transports. However, fallback to unencrypted transport is acceptable.

OPPORTUNISTIC-NO-FALLBACK The client is requesting a preference for resolving the query using encrypted transports. Fallback to unencrypted transport is not acceptable.

STRICT The client is requesting a preference for resolving the query using authenticated encrypted transport.

Interpretations of Privacy Response Values

CLEARTEXT The resolver had to send at least one unencrypted query during resolution.

ENCRYPTED The resolver only sent encrypted queries or used cached data during resolution.

CACHED The final answer was fetched directly from the resolver's cache.

AUTHENTICATED The resolver only sent encrypted queries or used cached data during resolution. Moreover, encrypted connections were authenticated, for example via a TLSA record, and cached data was only used if it was received via an authenticated transport.

Protocol Description A client adds the PRIVACY EDNS0 option to a recursive query before sending it. A client SHOULD NOT add the PRIVACY option to recursive queries being sent in cleartext as this would be counter to what the client is trying to achieve. Given that the client sent its query using an encrypted transport, the recursive resolver will try to honor the PRIVACY option. If it is NONE, it means the client does not care about what transports are used to resolve the query and the resolver may resolve it in any way deemed suitable. If the option is OPPORTUNISTIC, the resolver MUST attempt encrypted transport to all nameserver it knows support encryption while traversing the delegation chain. However, the resolver is allowed to fall back to an unencrypted transport after a failed attempt. If the option is OPPORTUNISTIC-NO-FALLBACK the resolver MUST NOT perform such a fallback at any point during the resolution process. Using contents from the cache is always okay as this does not leak any information about the client's query. If the STRICT option is set, the resolver MUST authenticate all encrypted connections it makes during resolution. If cached data is to be used during resolution, it MUST have been received over an authenticated encrypted connection.

Setting a PRIVACY RESPONSE Value A recursive resolver SHOULD only set an EDNS0 PRIVACY option if the option was present in the query. If the data was readily available in the resolver's cache, it sets a value of CACHED. If at any point during the resolution process, a query was sent unencrypted (either due to falling back or to the client query having a value of NONE), the resolver MUST set the value to CLEARTEXT. If the resolver solely used encrypted transports and data from its cache to retrieve the answer, it responds with a value of ENCRYPTED. What transport cached data arrived over does not matter in this case. If the resolver was able to resolve the query using only data that arrived over authenticated transports (either from the cache or from a response), it response with a value of AUTHENTICATED

Failure to Honor a OPPORTUNISTIC-NO-FALLBACK or STRICT Request If the recursive resolver cannot obtain the answer without sending a query over an unencrypted transport, and the client requested OPPORTUNISTIC-NO-FALLBACK, the resolver MUST NOT send the query that could not be sent encrypted. It MUST instead respond with RCODE SERVFAIL and SHOULD include an Extended DNS Error with INFO-CODE TBD2 ("Encrypted Transport Unavailable"). The response MUST include the PRIVACY option with the value ENCRYPTED, since no information about the query was sent in cleartext. Failure to honor a STRICT request works similarly, the resolver sets an INFO-CODE of TBD2 and an AUTHENTICATED value for the PRIVACY RESPONSE field. It is expected that during early deployment, most OPPORTUNISTIC-NO-FALLBACK and STRICT requests will fail. However, for debugging purposes, such a signal is valuable for testing that recursive resolvers actually honor the encryption request. Also, as the technology matures, the OPPORTUNISTIC-NO-FALLBACK and STRICT options might eventually become viable.

Relation to QNAME minimisation QNAME minimisation is another privacy-enhancement for authoritative DNS that recursive resolvers can implement. It SHOULD be considered orthogonal to what is proposed in this draft. That is, the value that the resolver sets for the PRIVACY option SHOULD NOT be affected in any way by whether the resolver employs QNAME minimisation or not. QNAME minimization does not give as good privacy as encryption if there are more than two or three delegations. On the other hand, QNAME minimization avoids leaking information to authoritative servers, which means there might still be good reasons to use it.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

TDNS

Organization:

The Swedish Internet Foundation

Description:

TDNS, a framework of experimental DNS servers. https://github.com/johanix/tdns

Maturity:

Experimental

Coverage:

Recursive resolver: parsing the client signal, honoring OPPORTUNISTIC requests, setting the response PRIVACY value. Stub/client: Setting the PRIVACY value and interpreting the PRIVACY value in the response.

Licensing:

BSD-2-Clause

Contact:

johan.stenstam@internetstiftelsen.se

Last updated:

October 2026

Firefox

Organization:

Mozilla

Description:

Firefox, a web-browser. https://phabricator.services.mozilla.com/D321467

Maturity:

Experimental

Coverage:

Setting the PRIVACY value in outgoing DoH queries and interpreting the PRIVACY value in the response.

Licensing:

MPL-2.0

Contact:

ietf.valentin@gosu.se

Last updated:

October 2026

Security Considerations Enables/simplifies cache probing through the CACHED option. However, this is already possible through measuring response times or inspecting TTLs. The PRIVACY option does not introduce any novel attack vectors. The client can only really trust the PRIVACY option when it is received over a secure channel, such as DoH, from a trusted recursive resolver. This is somewhat analogous to how the AD-bit is used between a client and a resolver in DNSSEC .

IANA Considerations This document defines a new EDNS(0) option, entitled "client-privacy-signal", assigned a value of TBD1 "DNS EDNS0 Option Codes (OPT)" registry

Value	Name	Status	Reference
TBD1	client-privacy-signal	Standard	( This document )

This document also defines a new INFO-CODE, entitled "Encrypted Transport Unavailable", assigned a value of TBD2 in the "Extended DNS Error Codes" registry.

Value	Name	Status	Reference
TBD2	encrypted-transport-unavailable	Standard	( This document )

References Normative References 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 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. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. 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. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Informative References This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation NLnet Labs Sinodun IT This document proposes a mechanism for authoritative DNS servers to signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)). This signaling may either be provided within the Additional section of authoritative DNS responses or be the result of direct DNS queries. The former, "opportunistic mode" is hint-based and aims to enable resolvers to discover alternative transports efficiently and then opportunistically upgrade connections to the authoritative, thereby improving privacy, security, and performance for subsequent interactions. The mechanism is designed to not require any protocol change or additional queries. It is safe, backward-compatible, and effective even when DNSSEC validation of the hint is not possible or desired. In certain circumstances and with additional overhead it is also possible to use direct queries to securely obtain authentication information for the authoritative that can then be used to authenticate an encrypted connection. It is also possible to establish a "validated mode" where the communication between the resolver and the authoritative server is provably both secure and authentic. Validated mode may not always be possible, depending on whether the resolver is able to DNSSEC validate the signal or not. When Validated mode is possible it does provide a stronger and more trustworthy connection. This document proposes an improvement to the opportunistic (but blind) testing of alternative transports suggested in RFC9539 by providing a mechanism by which a responding authoritative server may signal what alternative transports it supports. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-transport-signaling (https://github.com/johanix/draft-johani-dnsop-transport-signaling). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. ISC Akamai Technologies Salesforce This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in [I-D.draft-wesplaap-deleg], with ability to specify transport protocols and authentication parameters supported by name servers. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Acknowledgments TODO acknowledge.