Generalized DNS Notifications

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

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 14 August 2023.¶

Copyright Notice

Copyright (c) 2023 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

This document introduces a generalization of the DNS NOTIFY mechanism described in [RFC1996].¶

Traditional DNS notifications, which are here referred to as "NOTIFY(SOA)", are sent from a primary server to a secondary server to minimize the latter's convergence time to a new version of the zone. This mechanism successfully addresses a significant inefficiency in the original protocol.¶

Today there are several new cases where similar inefficiencies cause significant problems. However, just as in the NOTIFY(SOA) case, a new set of notification types will have a major positive benefit by allowing the DNS infrastructure to completely sidestep these inefficiencies.¶

There are no DNS protocol changes introduced by this document.¶

There are, however, proposals for how to interpret a wider range of DNS messages that are already allowed (but not used) by the protocol.¶

Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], [RFC7477], [RFC7583], and [RFC8901].¶

2. Costs and Dangers of Slow Convergence

[RFC1996] introduced the concept of a DNS Notify message which was used to improve the convergence time for secondary servers when a DNS zone had been updated in the primary. The basic idea was to augment the traditional "pull" mechanism (a periodic SOA query) with a "push" mechanism (a Notify) for a common case that was otherwise very inefficient (due to either slow convergence or wasteful overly frequent scanning of the primary for changes).¶

Today we have similar issues with slow updates of DNS data in spite of the data having been published. The two most obvious cases are the scalability issues of modern CDS and CSYNC scanners that are beginning to be deployed in a growing number of TLD registries. Because of the large number of child delegations, scanning for CDS and CSYNC records is rather slow (as in infrequent).¶

Another use case is for so-called "multi-signer" setups where there are multiple, semi-independent, "signers" that each sign the same zone, but with individual sets of keys. One requirement for multi-signer setups to work is the ability to insert additional DNSKEY records in each signer's version of the zone. (This is not the only multi-signer requirement, but it is the one that matters here.) The problem here is that modern signers will commonly roll DNSSEC Zone Signing Keys automatically and without informing anyone, assuming a single-signer setup where ZSK rollovers are a local matter (as opposed to KSK rollovers that involve the parent). As a result, when the ZSKs of one signer are rolled, the other signers will be unaware of this event. However, to enable validation of signatures using a new ZSK, it needs to be announced by all nameservers that are authoritative for the child. To achieve this, it is therefore necessary to bring the signers' DNSKEY RRsets back in sync. Such re-synchronization can either happen based on a schedule, or on demand, given a suitable trigger.¶

3. Efficiency Issues with DNS Scanning vs. Notification

The original problem that [RFC1996] addressed was the problem of optimization between frequent checking for new versions of a zone by a secondary and infrequent checking. While it is possible to indicate how frequently checks should occur (via the SOA Refresh parameter), these checks did not allow catching zone changes that fall between checkpoints. NOTIFY replaces scheduled scanning with a more efficient mechanism.¶

In modern DNS infrastructure there are several new scanning-based inefficiencies that did not exist at the time of the writing of [RFC1996].¶

4. CDS/CDNSKEY and CSYNC Notifications

The [RFC1996] NOTIFY message sends a SOA record in the Query Section. We refer to this as a NOTIFY(SOA). By generalizing the concept of DNS NOTIFY it is possible to address not only the original inefficiency (primary name server to secondary nameserver convergence) but also the problems with CDS/CDNSKEY, CSYNC and Multi-Signer scanning for zone updates.¶

The CDS/CDNSKEY inefficiency may be addressed by the child sending a NOTIFY(CDS) to an address where the parent listens for such notifications.¶

While the receiving side will often be a scanning service provided by the registry itself, it is expected that in the ICANN RRR model, some registries will prefer registrars to conduct CDS/CDNSKEY scans. For such parents, the receiving service should notify the appropriate registrar, over any communication channel deemed suitable between registry and registrar (such as EPP, or possibly by forwarding the actual NOTIFY(CDS) or NOTIFY(CSYNC) directly). Such internal processing is inconsequential from the perspective of the child: the NOTIFY packet is simply sent to the notification address.¶

To address the CDS/CDNSKEY dichotomy, NOTIFY(CDS) is defined to indicate any child-side changes pertaining to a upcoming update of DS records. Upon receipt of NOTIFY(CDS), the parent SHOULD initiate the same scan that would otherwise be triggered based on a timer.¶

The CSYNC inefficiency may similarly be addressed by the child sending a NOTIFY(CSYNC) to an address where the parent is listening to CSYNC notifications.¶

In both cases the notification will speed up the CDS and CSYNC scanning by providing the parent with a hint that a particular child zone has published new CDS, CDNSKEY and/or CSYNC records.¶

The DNS protocol already allows these new notification types, so no protocol change is required. The only thing needed is specification of where to send the new types of Notifies and how to interpret them in the receiving end.¶

parent.   IN NOTIFY CDS   scheme port scanner.parent.
parent.   IN NOTIFY CSYNC scheme port scanner.parent.

parent.   IN NOTIFY CDS   1 5359 cds-scanner.parent.
parent.   IN NOTIFY CSYNC 1 5360 csync-scanner.parent.

5. DNSKEY Notifications

In the multi-signer case the problem is slightly different, because it is not the parent that should be notified, but rather a third party.¶

child.parent. IN NOTIFY DNSKEY scheme port scanner.signerA.
child.parent. IN NOTIFY DNSKEY scheme port scanner.signerB.

child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerA.
child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerB.
child.parent. IN NOTIFY DNSKEY 1 5361 ctrl.multi-signer.example.

6. Who Should Send the Notifications?

Because of the security model where a notification by itself never causes a change (it can only speed up the time until the next check for the same thing), the sender's identity is not crucial.¶

This opens up the possibility of having the controller in a multi-signer setup send the CDS and CSYNC notifications to the parent, thereby enabling this new functionality even before the emergence of support for generalized DNS notifications in the name servers used for signing.¶

However, as multi-signer is strongly dependent on DNSKEY notifications (which, in case of an automatic ZSK rollover, can only be generated by the signing software), this does not alleviate the need for modifications also to signing software to support NOTIFY(DNSKEY).¶

7. Timing Considerations

When a primary name server publishes a new CDS RRset there will be a time delay until all copies of the zone world-wide will have been updated. Usually this delay is short (on the order of seconds), but it is larger than zero. If the primary sends a NOTIFY(CDS) at the exact time of publication of the new zone there is a potential for the parent to schedule the CDS check that the notification triggers faster than the zone propagates to all secondaries. In this case the parent may draw the wrong conclusion ("the CDS RRset has not been updated").¶

Having a delay between the publication of the new data and the check for the new data would alleviate this issue. However, as the parent has no way of knowing how quickly the child zone propagates, the appropriate amount of delay is uncertain. It is therefore RECOMMENDED that the child delays sending NOTIFY packets to the parent until a consistent public view of the pertinent records is ensured.¶

NOTIFY(CSYNC) has the same timing consideration as NOTIFY(CDS) while NOTIFY(DNSKEY) does not.¶

8. The Format of the NOTIFY Record

Here is the format of the NOTIFY RR, whose DNS type code is not yet defined.¶

    Name TTL Class NOTIFY RRtype Scheme Port Target

Name The zone this RR refers to. In the case of NOTIFY(CDS) and NOTIFY(CSYNC) this is the name of the parent zone. In the case of NOTIFY(DNSKEY) this is the name of the zone in which a change in the DNSKEY RRset is taking place.¶

TTL Standard DNS meaning [RFC 1035].¶

Class Standard DNS meaning [RFC 1035]. NOTIFY records occur in the IN Class.¶

RRtype The type of generalised NOTIFY that this NOTIFY RR defines the desired target address for. Currently only the types CDS, CSYNC and DNSKEY are suggested to be supported, but there is no protocol issue should a use case for additional types of notifications arise in the future.¶

Scheme The scheme for locating the desired notification address. The range is 0-255. This is a 16 bit unsigned integer in network byte order. The value 0 is an error. The value 1 is described in this document and all other values are currently unspecified.¶

Port The port on the target host of the notification service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.¶

Target The domain name of the target host providing the service of listening for generalised notifications of the specified type. This name MUST resolve to one or more address records.¶

9. Open Questions

parent.         IN NOTIFY  CDS     1  59   scanner.parent.
parent.         IN NOTIFY  CSYNC   1  59   scanner.parent.
child.parent.   IN NOTIFY  DNSKEY  1  5900 ctrl.multi-signer.example.

10. Out of Scope

To accommodate ICANN's RRR model, the parent's designated notification target may forward NOTIFY(CDS) messages to the registrar, e.g. via EPP or by forwarding the NOTIFY(CDS) message directly. The same is true also for NOTIFY(CSYNC).¶

From the perspective of this protocol, the NOTIFY(CDS) packet is simply sent to the parent's listener address. However, should this turn out not to be sufficient, it is possible to define a new "scheme" that specifies alternative logic for dealing with such requirements. Description of internal processing in the recipient end or for locating the recipient are out of scope of this document.¶

In the multi-signer case, where the same zone is signed by multiple semi-independent "signers" it is obviously necessary to devise means of keeping the non-DNSSEC contents of the zone in sync. That is out of scope of the multi-signer work and also out of scope of this document.¶

A corner case of this scoping regards making changes to the NS RRset. Individual signers (as in DNS service providers) may want to be able to make such changes independently of the other contents of the zone.¶

11. Security Considerations

The original NOTIFY specification ([RFC1996]) sidesteps most security issues by not relying on the information in the NOTIFY message in any way but instead only use it to set the timer until the next scheduled check (for the SOA record) to zero. Therefore it is impossible to affect the behaviour of the recipient of the NOTIFY other than by changing the timing for when different checks are initiated.¶

This mechanism and security model is reused for all the generalized NOTIFY messages.¶

Another consideration is whether generalized DNS Notifications can be used as an amplification attack. The answer seems to be "NO", because the size of the generalized NOTIFY messages is mostly equal to the size of the response and it is also mostly equal to the size of the resulting outbound query (for the child zone's CDS, CSYNC or DNSKEY RRset).¶

Hence the amplification attack potential of generalized Notifications is the same as for the original NOTIFY(SOA), which has never been found to be useful for amplification attacks.¶

In any case, NOTIFY consumers MAY configure rate limits to address concerns about the impact of unsolicited NOTIFY messages.¶

12. IANA Considerations

Per [RFC8552], IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" IANA web page as follows:¶

Name: Generalized DNS Notifications¶

Assignment Policy: Expert Review¶

Reference: [this document]¶

13. Acknowledgements

Joe Abley, Mark Andrews, Christian Elmerot, Olafur Gu[eth]mundsson, Paul Wouters, Brian Dickson¶

Appendix A. Change History (to be removed before publication)

• draft-thomassen-dnsop-generalized-dns-notify-01¶

• Mention Ry-to-Rr forwarding to accommodate RRR model¶

• Add port number flexiblity¶

• Add scheme parameter¶

• Drop SRV-based alternative in favour of new NOTIFY RR¶

• Editorial improvements¶

• draft-thomassen-dnsop-generalized-dns-notify-00¶

• Initial public draft.¶

Authors' Addresses