| Internet-Draft | No DO for you | October 2026 |
| Kumari, et al. | Expires 3 May 2027 | [Page] |
{ Editor note: THIS IS A WORKING IDEA FOR DISCUSSION.¶
It might be the best idea ever... or the worst idea ever. The authors really cannot decide (or even agree among themselves), but I have written this up as as an ID to share it with the WG. Please understand that we are simply floating the idea; if it turns out that it is the worse idea ever, we'll happily drop it and save ourselves a bunch of work! :-) }¶
The DNSSEC OK (DO) bit is an EDNS0 flag used in DNS queries to signal that the requestor wishes to receive DNSSEC resource records (such as RRSIG, DNSKEY, DS, and NSEC) in the response.¶
This bit is named DNSEC OK (DO) as an indication that the resolver implementation will not die if it receives DNSSEC records, not that it is actually performing DNSSEC validation.¶
It is important to note that clearing the DO bit means that the authoritative server will not include DNSSEC records in its response, even if they exist.¶
One of the concerns around Post Quantum Cryptography (PQC) is that the resulting DNSSEC signatures may be significantly larger than current signatures. This could exacerbate issues related to DNS message size and fragmentation, and cause many connections to fail back to TCP.Clearing the DO bit can help mitigate these issues by preventing the inclusion of potentially large DNSSEC records in responses, but it also means that resolvers will not have access to the DNSSEC proofs necessary for validation.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://kumari-net-org.github.io/draft-wagope-dnsop-do-bit/#go.draft-wagope-dnsop-do-bit.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wagope-dnsop-do-bit/.¶
Source for this draft and an issue tracker can be found at https://github.com/kumari-net-org/draft-wagope-dnsop-do-bit.¶
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 3 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.¶
One of the primary concerns around deploying Post Quantum Cryptography (PQC) algorithms in DNSSEC is that the resulting signatures will almost certainly exceed the size of UDP responses.¶
This document proposes that non-DNSEC validating resolvers clear the DO bit as they do not (necessarily) need the DNSSEC records.¶
This approach may help mitigate the number of TCP connections that authoritative servers need to handle, but at the cost of additional complexity and number of queries.¶
If a resolver is not performing DNSSEC validation, and the incoming query has the DO bit clear, the resolver SHOULD clear the DO bit in its outgoing queries. This signals to authoritative servers that DNSSEC records are not required in the response, reducing the size of the response and avoiding TCP fallback.¶
This does, however, mean that if the recursive resolver subsequently receives a query from a DNSSEC validating client (e.g a DNSSEC validating stub, or a forwarded query from a DNSSEC validating resolver), it will not be able to provide the necessary DNSSEC records for validation, which would cause validation to fail.¶
For this reason, resolvers following this behavior MUST keep track in their cache which responses were obtained without DNSSEC records. If a query for such a cached entry is received with the DO bit set, the resolver must then re-query the authoritative server with the DO bit set to obtain the necessary DNSSEC records for validation.¶
This document has no IANA actions.¶
The authors would like to thank the following individuals for their feedback and suggestions: Gautam Akiwate, Russ Housley, Barry Leiba, John Levine, Rod Rasmussen, Laurin Weissinger, Suzanne Woolf.¶
Unfortunately, at least one of the authors has a terrible memory, and has lost track of all those who have contributed to this topic over the years, and will be more than happy to acknowledge their input if reminded of this :-)¶
In addition, Warren would like to thank Infected Mushroom for once again providing a good soundtrack during the writing of this document.¶