]> Google, Inc.

warren@kumari.net

APNIC

gih@apnic.net

deSEC, SSE

peter@desec.io

OPS DNSOP Working Group DNSSEC PQC large signatures { 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction 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.

Detail and implications 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.

IANA Considerations This document has no IANA actions.

Normative References This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

Acknowledgments 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.