| Internet-Draft | Client-side ADoX Signal | November 2026 |
| Fernandez & Gosu | Expires 6 May 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://zluudg.github.io/draft-client-side-adox-signal/draft-fernandez-dnsop-client-side-adox-signal.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fernandez-dnsop-client-side-adox-signal/.¶
Discussion of this document takes place on the DNSOP Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.¶
Source for this draft and an issue tracker can be found at https://github.com/zluudg/draft-client-side-adox-signal.¶
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 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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 [RFC8484], QUIC [RFC9250] and TLS [RFC7858]. 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 [RFC6891] 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, [RFC9539], [I-D.johani-dnsop-transport-signaling] and [I-D.wesplaap-deleg-transport]. 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.¶
Client: A stub resolver as defined in [RFC9499] or some other software, such as a browser, is close to the end-user and sends recursice DNS queries.¶
Resolver: As defined in [RFC9499].¶
ADoX: Authoritative DNS-over-X, where X implies some arbitrary encrypted transport protocol.¶
The EDNS0 PRIVACY option is structured as follows:¶
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | PRIVACY REQUEST | PRIVACY_RESPONSE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
¶
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 Section 4. 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 Section 5. In a DNS query, the recipient MUST ignore this field and the sender SHOULD set it to 0.¶
| Value | Mnemonic |
|---|---|
| 0 | NONE |
| 1 | OPPORTUNISTIC |
| 2 | OPPORTUNISTIC-NO-FALLBACK |
| 3 | STRICT |
| Value | Mnemonic |
|---|---|
| 0 | CLEARTEXT |
| 1 | ENCRYPTED |
| 2 | CACHED |
| 3 | AUTHENTICATED |
Same effect as having no client signal at all. No privacy requested by the client that is sending the query.¶
The client is requesting a preference for resolving the query using encrypted transports. However, fallback to unencrypted transport is acceptable.¶
The client is requesting a preference for resolving the query using encrypted transports. Fallback to unencrypted transport is not acceptable.¶
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.¶
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.¶
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¶
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 [RFC8914] 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.¶
QNAME minimisation [RFC9156] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section is to be removed before publishing as an RFC.¶
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 [RFC7942]. 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 [RFC7942], "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".¶
The Swedish Internet Foundation¶
TDNS, a framework of experimental DNS servers. https://github.com/johanix/tdns¶
Experimental¶
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.¶
BSD-2-Clause¶
johan.stenstam@internetstiftelsen.se¶
October 2026¶
Mozilla¶
Firefox, a web-browser. https://phabricator.services.mozilla.com/D321467¶
Experimental¶
Setting the PRIVACY value in outgoing DoH queries and interpreting the PRIVACY value in the response.¶
MPL-2.0¶
ietf.valentin@gosu.se¶
October 2026¶
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 [RFC4035].¶
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 ) |
TODO acknowledge.¶