Support for nothing-new notifications in the DNS
draft-hardaker-dnsop-nothing-new-00

Domain Name System Operations                                W. Hardaker
Internet-Draft                                              Google, Inc.
Intended status: Standards Track                             2 July 2026
Expires: 3 January 2027

            Support for nothing-new notifications in the DNS
                  draft-hardaker-dnsop-nothing-new-00

Abstract

   The DNS protocol has increasingly needed to carry larger records than
   it was originally designed to carry.  This has resulted in
   performance impacts due to both the size increases and requiring TCP
   instead of only UDP.  Of particular note is the expected large
   increase in records relating to post-quantum signing algorithms.  To
   help mitigate, but not entirely prevent, these impacts, this document
   proposes a new "nothing new" NN flag, a LARGE Redirection Resource
   record type, and how these can integrate with current and future
   DNSSEC DNSKEY and RRSIG records.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nothing-new/.

   Discussion of this document takes place on the Domain Name System
   Operations 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/https://github.com/hardaker/draft-hardaker-dnsop-
   nothing-new.

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

Hardaker                 Expires 3 January 2027                 [Page 1]
Internet-Draft           Nothing-new in the DNS                July 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 3 January 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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Technique Overview  . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  The Nothing New flag  . . . . . . . . . . . . . . . . . . . .   5
   4.  The LARGE Resource Record . . . . . . . . . . . . . . . . . .   5
     4.1.  Selecting serial numbers  . . . . . . . . . . . . . . . .   5
     4.2.  Discussion: Alternative LARGE formats . . . . . . . . . .   6
     4.3.  Discussion: Alternative LARGE record placement  . . . . .   6
     4.4.  Discussion: Signaling to the parent with a LARGE
           record  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Use with DNSSEC . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

Hardaker                 Expires 3 January 2027                 [Page 2]
Internet-Draft           Nothing-new in the DNS                July 2026

1.  Introduction

   (Ed: this is very much a work in progress and is not a fully
   specified specification at this point, and as such is not
   implementable.  It is designed to promote thought and discussion
   about how to handle large requests within the DNS using new
   mechanisms.)

1.1.  Background

   The DNS protocol has increasingly needed to carry larger records than
   it was originally designed to carry.  This has resulted in
   performance impacts due to both the size increases and requiring TCP
   instead of only UDP.  Of particular note is the expected large
   increase in records relating to Post-Quantum-Computing (PQC) signing
   algorithms.  Note that while this draft concentrates on PQC
   algorithms, the techniques proposed should help mitigate other large
   packet size issues with any types of DNS data.

   With the increase in size requirements being transmitted over DNS, we
   have but a few options to address the need for large RRsets and/or
   mitigate the burden on authoritative servers.  These are at least
   some of the options available:

   1.  Encourage the switch to TCP for requests which are known to
       generate large responses.  Especially those performing DNSSEC (DO
       bit) queries.

   2.  Investigate and deploy DNSSEC signing algorithms and deploy that
       minimize the packet size impacts.  We have already done this
       recently, to some extent, with the shift to elliptic curve based
       algorithms in DNSSEC

       But PQC algorithms will be significantly larger, even if we
       standardize on an algorithms with the smallest key and signature
       sizes.

   3.  Reduce the need for sending large responses in the first place.
       The most obvious solution to this is to increase TTL values.
       However, that is not always possible.

   This draft explores an additional mechanism to solve #3 by further
   reducing the quantity of large packets needed to be sent.  It does
   this by indicating that no changes have been made to DNS records,
   which would otherwise be large and a burden to transmit frequently.

Hardaker                 Expires 3 January 2027                 [Page 3]
Internet-Draft           Nothing-new in the DNS                July 2026

1.2.  Technique Overview

   This document proposes a new "nothing new" NN flag, a LARGE
   Redirection Resource record type, and describes how these can
   integrate with current and future DNSSEC DNSKEY and RRSIG records.

   This document proposes two technical mechanisms for signaling that
   resource records have not changed since a previously obtained set,
   and thus do not need to be re-fetched.  This potentially saves
   significant resources on both the client and server.  These
   optimizations include:

   *  A new Nothing New (NN) DNS bit, to be used in conjunction with the
      Truncated Response (TC) bit that indicates the requested records
      have not been changed recently, and thus cached data is sufficient
      fro use.  See Section 3 for details.

   *  A LARGE resource record (Section 4) that serves as a hint about
      what version of a record is current and whether or not a client
      needs to refetch its contents.

   The trustability of these unsigned signals is discussed in Section 6.

   The simple goal of these new features is to reduce the necessary
   number of large responses from authoritative servers when
   communicating with conforming resolver clients.  Effectively, these
   mechanisms allow for signaling both:

   1.  If a recursive resolver has data in its cache, it may keep using
       it (assuming the cached DNSSEC signatures are still valid if it
       is validating).

   2.  A version number of the data requested to check against a
       resolver's cache, providing a hint about whether the data in a
       resolvers cache is actually old or the same.

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

Hardaker                 Expires 3 January 2027                 [Page 4]
Internet-Draft           Nothing-new in the DNS                July 2026

3.  The Nothing New flag

   This document defines a Nothing New (NN) flag within the EDNS0 option
   header.  This flag SHOULD be set by recursive resolvers that support
   this specification.  This flag SHOULD be set by authoritative servers
   that support this specification and are returning a Truncation
   Response (TC) bit to indicate that nothing has changed recently in
   the requested resource record.  If the authoritative server is unable
   to determine that nothing new has changed with respect to that
   resource record, it MUST NOT set the NN bit in its response period.

   In short the NN flag is a signal that can be sent along with the
   Truncated Response (TC) flag to indicate both that data truncation
   has occurred to comply with packet size limits [RFC6891] and that any
   data with a still valid signature validity may be continued to use
   instead of refetching the data.

   This flag SHOULD be accompanied with a LARGE (Section 4) Resource
   Record as well.  If the DNSSEC signature on the LARGE RR can fit
   within the response, it MUST be included.  If the DNSSEC signature on
   the LARGE RR cannot fit within the response, the LARGE RR SHOULD be
   sent without it.

4.  The LARGE Resource Record

   The LARGE RR is a hint to the resolver about the freshness of the
   data at the server compared to the freshness of the data within the
   resolver's cache.

   The RR contains the following fields:

   *  IDENTIFIER: A 16-bit serial number field that must be unique
      within the signature lifetime of the data it represents.
      Resolvers can use this information to determine if the record they
      have available matches the value not sent by the upstream server.

   The name of this record MUST match the name of the record being
   requested in the query.

4.1.  Selecting serial numbers

   The identifier field MUST be selected from a unique set of values
   that will not duplicate during the lifetime of the DNSSEC signatures
   period.  Authoritative servers which auto-generate this field can use
   various forms of mechanisms, such as cryptographic hashes,
   incremental serial numbers, carefully constructed timestamps, fields
   and values from the data that it represents, as long as the
   uniqueness constraint is properly observed.

Hardaker                 Expires 3 January 2027                 [Page 5]
Internet-Draft           Nothing-new in the DNS                July 2026

   The SOA serial number of the zone SHOULD NOT be used as LARGE record
   serial numbers unless it is expected that all records in a zone are
   likely to change at the same time the SOA is ever changed.  EG,
   highly dynamic zones will have their SOA changing so frequently that
   it is pointless to use them to indicate changes relating to otherwise
   fairly static records, like DNSKEYs.

   Note: LARGE records and their serial numbers need only be generated
   and track for records which are expected to generate truncated
   responses.

4.2.  Discussion: Alternative LARGE formats

   Could be a TXT style record with the more modern key=value syntax, at
   the cost of a size increase.

4.3.  Discussion: Alternative LARGE record placement

   This could be done with an underbar label instead, with something
   like a _large.example.com record instead.  (this is more difficult
   than it sounds and probably won't work well in practice)

4.4.  Discussion: Signaling to the parent with a LARGE record

   Another option is to actually have the resolver send a signal to the
   parent about its cache using an embedded LARGE record within an EDNS0
   packet so that the parent knows whether or not something is new.

   Because the NN feature is only expected to be used in a truncated
   response, it does not help the authoritative server know the serial
   number that the client last saw.  Specifically, the authoritative
   server will have to return a truncated response (and a LARGE record
   anyway).  Thus, instead we place the burden on the resolver to figure
   out whether it needs to request the entire RRset (over TCP) or not.

5.  Use with DNSSEC

   The use of these techniques within DNSSEC is especially tricky even
   while other uses may be more straight forward, as RRSIG records
   themselves are frequently large but are needed to validate the data.
   For the average DNSSEC signed zone, it may be that only the DNSSEC
   records need to be tracked with serial numbers.

   (TBD: I have ideas about large RRSIGs associated with small records
   that I haven't written here yet -- but PQC RRSIGs are expected to be
   large as well)

Hardaker                 Expires 3 January 2027                 [Page 6]
Internet-Draft           Nothing-new in the DNS                July 2026

6.  Security Considerations

   Obviously, using unsigned data to decide whether or not to retrieve
   signed data is a security concern.  Having said that, there are
   already other specifications that show how to old data when the
   parental server cannot be contacted ([RFC8767]).

   This document merely provides a specification for the parental agent
   to deliberately say "nothing new".  If there is a machine in the
   middle spoofing this signal, it already has an attack vector to cause
   a resolver to use stale data by simply dropping query or response so
   the resolver falls back to its stale cache.  At most, with this
   proposal clients will end up using old data, which is already the
   case, albeit faster than waiting for a timeout.

7.  IANA Considerations

   TBD

8.  References

8.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6891>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [BCP237]   Best Current Practice 237,
              <https://www.rfc-editor.org/info/bcp237>.
              At the time of writing, this BCP comprises the following:

Hardaker                 Expires 3 January 2027                 [Page 7]
Internet-Draft           Nothing-new in the DNS                July 2026

              Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/info/rfc9364>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

Acknowledgments

   The bad-idea fairy contributed greatly to the ideas behind this
   document.

   Joe Ably had constructive advice to offer, even though he may not
   actually agree with the bad ideas in this document.

   TBD

Author's Address

   Wes Hardaker
   Google, Inc.
   Email: ietf@hardakers.net

Hardaker                 Expires 3 January 2027                 [Page 8]