Hi,
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed to overloading).
A note on where to send CDS and CSYNC notifications. I sort of
understand why the NOTIFY record includes a RRtype field, but will
parental entities really have a different target for receiving notifies
for CDS and CSYNC?
For the sender of the notifies, this may be cumbersome to do different
lookups that probably end up being the same target.
Related to this, when it comes to the multi-signer model, you do not
only need to send DNSKEY notifications, but also CDS and CSYNC
notifications to the other signers, especially if you want these RRsets
to be consistent with each other. Follwing up on the example in Section
5.1 that would mean we need additional NOTIFY records:
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.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerA.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerB.
child.parent. IN NOTIFY CDS 1 5361 ctrl.multi-signer.example.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerA.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerB.
child.parent. IN NOTIFY CSYNC 1 5361 ctrl.multi-signer.example.
That becomes quite a set already.
Perhaps we should differentiate on type of server (parent, signer, ...)
rather than RRtype?
Finally, about the open question for DNSKEY notifications. You say: As
the number of signers for a particular zone is low, there is no major
problem caused by not knowing which signer sent the notification and
instead always check all the signers for updates to the DNSKEY RRset.
How would you identify which is the newer DNSKEY RRset? If the
multi-signer controller checks two signers and receives the following
RRsets:
example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...
example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...
example.nl. 3600 IN DNSKEY 257 3 13 1Wut...
How would it know if a DNSKEY was added or removed from the RRset. This
obviously requires some state. And I suspect it works slightly different
again in a decentralized model.
This likely can all be solved, but it needs to be specified, and cannot
be dismissed as "probably not a major problem".
Best regards,
Matthijs
On 2/20/23 13:20, Peter Thomassen wrote:
Dear DNSOP,
Thank you for the very helpful feedback provided by several people on
the -00 revision back in November.
Johan and I made changes to the document that incorporate the insights
from the crowd, and resolved some other issues. The result is -01,
attached below. If you are interested, please take a read.
We're looking forward to further feedback here and/or at IETF 116. Thanks!
Best,
Peter
-------- Forwarded Message --------
Subject: New Version Notification for
draft-thomassen-dnsop-generalized-dns-notify-01.txt
Date: Fri, 10 Feb 2023 08:25:23 -0800
From: internet-dra...@ietf.org
To: Johan Stenstam <johan.stens...@internetstiftelsen.se>, Peter
Thomassen <pe...@desec.io>
A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.
Name: draft-thomassen-dnsop-generalized-dns-notify
Revision: 01
Title: Generalized DNS Notifications
Document date: 2023-02-10
Group: Individual Submission
Pages: 16
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt
Status:
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
Html:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-01
Abstract:
Changes in CDS/CDNSKEY, CSYNC, and other records related to
delegation maintenance are usually detected through scheduled scans
run by the consuming party (e.g. top-level domain registry),
incurring an uncomfortable trade-off between scanning cost and update
latency.
A similar problem exists when scheduling zone transfers, and has been
solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This
mechanism enables a primary nameserver to proactively inform
secondaries about zone changes, allowing the secondary to initiate an
ad-hoc transfer independently of when the next SOA check would be
due.
This document extends the use of DNS NOTIFY beyond conventional zone
transfer hints, bringing the benefits of ad-hoc notifications to DNS
delegation maintenance in general. Use cases include DNSSEC key
rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY) messages, and
quicker changes to a delegation's NS record set via NOTIFY(CSYNC)
messages.
Furthermore, this document proposes a new DNS record type,
tentatively referred to as "NOTIFY record", which is used to publish
details about where generalized notifications should be sent.
TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-
dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop-
generalized-dns-notify). The most recent working version of the
document, open issues, etc. should all be available there. The
authors (gratefully) accept pull requests.
The IETF Secretariat
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
