DNSOP L. Fernandez Internet-Draft The Swedish Internet Foundation Intended status: Standards Track V. Gosu Expires: 6 May 2027 Mozilla 2 November 2026 Client-side Request for Encrypted Authoritative DNS Queries draft-fernandez-dnsop-client-side-adox-signal-00 Abstract 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 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. 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/. Fernandez & Gosu Expires 6 May 2027 [Page 1] Internet-Draft Client-side ADoX Signal November 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The EDNS0 PRIVACY Option . . . . . . . . . . . . . . . . . . 4 4. PRIVACY REQUEST Values . . . . . . . . . . . . . . . . . . . 4 5. PRIVACY RESPONSE Values . . . . . . . . . . . . . . . . . . . 5 5.1. Interpretations of Privacy Request Values . . . . . . . . 5 5.1.1. NONE . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.2. OPPORTUNISTIC . . . . . . . . . . . . . . . . . . . . 5 5.1.3. OPPORTUNISTIC-NO-FALLBACK . . . . . . . . . . . . . . 5 5.1.4. STRICT . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Interpretations of Privacy Response Values . . . . . . . 5 5.2.1. CLEARTEXT . . . . . . . . . . . . . . . . . . . . . . 5 5.2.2. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 6 5.2.3. CACHED . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.4. AUTHENTICATED . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 6.1. Setting a PRIVACY RESPONSE Value . . . . . . . . . . . . 6 6.2. Failure to Honor a OPPORTUNISTIC-NO-FALLBACK or STRICT Request . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Relation to QNAME minimisation . . . . . . . . . . . . . . . 7 8. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 9.1. TDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 Fernandez & Gosu Expires 6 May 2027 [Page 2] Internet-Draft Client-side ADoX Signal November 2026 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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 [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. 2. Terminology 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. Fernandez & Gosu Expires 6 May 2027 [Page 3] Internet-Draft Client-side ADoX Signal November 2026 3. The EDNS0 PRIVACY Option 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. 4. PRIVACY REQUEST Values +=======+===========================+ | Value | Mnemonic | +=======+===========================+ | 0 | NONE | +-------+---------------------------+ | 1 | OPPORTUNISTIC | +-------+---------------------------+ | 2 | OPPORTUNISTIC-NO-FALLBACK | +-------+---------------------------+ | 3 | STRICT | +-------+---------------------------+ Table 1 Fernandez & Gosu Expires 6 May 2027 [Page 4] Internet-Draft Client-side ADoX Signal November 2026 5. PRIVACY RESPONSE Values +=======+===============+ | Value | Mnemonic | +=======+===============+ | 0 | CLEARTEXT | +-------+---------------+ | 1 | ENCRYPTED | +-------+---------------+ | 2 | CACHED | +-------+---------------+ | 3 | AUTHENTICATED | +-------+---------------+ Table 2 5.1. Interpretations of Privacy Request Values 5.1.1. NONE Same effect as having no client signal at all. No privacy requested by the client that is sending the query. 5.1.2. OPPORTUNISTIC The client is requesting a preference for resolving the query using encrypted transports. However, fallback to unencrypted transport is acceptable. 5.1.3. OPPORTUNISTIC-NO-FALLBACK The client is requesting a preference for resolving the query using encrypted transports. Fallback to unencrypted transport is not acceptable. 5.1.4. STRICT The client is requesting a preference for resolving the query using authenticated encrypted transport. 5.2. Interpretations of Privacy Response Values 5.2.1. CLEARTEXT The resolver had to send at least one unencrypted query during resolution. Fernandez & Gosu Expires 6 May 2027 [Page 5] Internet-Draft Client-side ADoX Signal November 2026 5.2.2. ENCRYPTED The resolver only sent encrypted queries or used cached data during resolution. 5.2.3. CACHED The final answer was fetched directly from the resolver's cache. 5.2.4. 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. 6. 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. 6.1. 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 Fernandez & Gosu Expires 6 May 2027 [Page 6] Internet-Draft Client-side ADoX Signal November 2026 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 6.2. 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 [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. 7. Relation to QNAME minimisation 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. 8. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Fernandez & Gosu Expires 6 May 2027 [Page 7] Internet-Draft Client-side ADoX Signal November 2026 9. Implementation Status 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". 9.1. TDNS Organization: The Swedish Internet Foundation Description: TDNS, a framework of experimental DNS servers. https://github.com/johanix/tdns (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 9.2. Firefox Organization: Mozilla Fernandez & Gosu Expires 6 May 2027 [Page 8] Internet-Draft Client-side ADoX Signal November 2026 Description: Firefox, a web-browser. https://phabricator.services.mozilla.com/D321467 (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 10. 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 [RFC4035]. 11. 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 ) | +-------+-----------------------+----------+-------------------+ Table 3 This document also defines a new INFO-CODE, entitled "Encrypted Transport Unavailable", assigned a value of TBD2 in the "Extended DNS Error Codes" registry. Fernandez & Gosu Expires 6 May 2027 [Page 9] Internet-Draft Client-side ADoX Signal November 2026 +=======+=================================+==========+============+ | Value | Name | Status | Reference | +=======+=================================+==========+============+ | TBD2 | encrypted-transport-unavailable | Standard | ( This | | | | | document ) | +-------+---------------------------------+----------+------------+ Table 4 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . Fernandez & Gosu Expires 6 May 2027 [Page 10] Internet-Draft Client-side ADoX Signal November 2026 [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . 12.2. Informative References [I-D.johani-dnsop-transport-signaling] Stenstam, J., Fernandez, L., Bergström, E., Homburg, P., and S. Dickinson, "Authoritative DNS Transport Signaling", Work in Progress, Internet-Draft, draft-johani-dnsop- transport-signaling-03, 20 October 2025, . [I-D.wesplaap-deleg-transport] April, T., Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS using different transport protocols", Work in Progress, Internet-Draft, draft- wesplaap-deleg-transport-00, 3 March 2025, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9539] Gillmor, D. K., Ed., Salazar, J., Ed., and P. Hoffman, Ed., "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS", RFC 9539, DOI 10.17487/RFC9539, February 2024, . Acknowledgments TODO acknowledge. Fernandez & Gosu Expires 6 May 2027 [Page 11] Internet-Draft Client-side ADoX Signal November 2026 Authors' Addresses Leon Fernandez The Swedish Internet Foundation Email: leon.fernandez@internetstiftelsen.se Valentin Gosu Mozilla Email: ietf.valentin@gosu.se Fernandez & Gosu Expires 6 May 2027 [Page 12]