Hi Paul,
Thank you for your suggestions, all of which are incorporated one way or
another. Details below.
On 2/28/25 17:38, Paul Wouters wrote:
I guess it wasn't as clear to me that this was really providing just a "hint for
action", as can also seen by my further comments below.
How about making this a little more clear in the Abstract? Feel free to take
the below text as a hint to use or ignore (eg it is not a blocking
DISCUSS issue anymore):
CURRENT:
This document extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone
transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation
maintenance in general. Use cases include DNSSEC bootstrapping and key
rollovers hints, and quicker changes to a delegation's NS record set.
PROPOSED:
The DNS NOTIFY (RFC 1996) defines a method for the child zone to notify a
secondary zone that it should initiate a zone transfer action from the primary.
This document generalizes and extends this concept of the DNS NOTIFY to allow
sending other type of notifications via the DNS protocol that were lacking a
trigger mechanusm. This document creates a registry for new notification types
and adds notifications for supporting parental NS and DS record updates,
including DNSSEC bootstrapping. While notifications can be secured via access
control mechanisms, this is not a requirement as the notifications merely
signal to the receiver that they can or should initiate their regular (secured
or not) actions as normal.
Or maybe some of this text can be put in the Security Considerations ?
Here's a hybrid between the current and your proposed abstract; it's a little shorter and
thus seems more "abstract-suited":
NEW
This document generalizes and extends the use of DNS NOTIFY (RFC
1996) beyond conventional zone transfer hints, to allow triggering
other types of actions via the DNS that were previously lacking a
trigger mechanism. Notifications merely nudge the receiver to
initiate the desired action promptly (instead of on a schedule); they
do not alter the action itself (including any security checks it
might employ).
To enable this functionality, a method for discovering the receiver
endpoint for such notification messages is introduced, via the new
DSYNC record type. Notification types are recorded in a new
registry, with initial support for parental NS and DS record updates
including DNSSEC bootstrapping.
I've also added your remaining point "While notifications can be secured via access
control mechanisms, this is not a requirement" do the Security Considerations.
> If so, there would
> have to be some talk in the Security Considerations on how to do this
> safely (I am not convinced this is possible, especially when allowing
> a reasonable short/instant trigger time where a temporary resource is
> maliciously acquired (eg root on nameserver or BGP route change through
> attacker)
Triggering DS bootstrapping using a notification reuses the same security
model that the parent registry/registrar has accepted for whatever
bootstrapping procedure they're using. The notification is merely a timing
hint. The parent is free to require authentication for bootstrapping, e.g., via
RFC 9615.
Please add this text to the Security Considerations! It's a good and helpful
reminder.
The above text might be considered a little too casual for a publication, but
here's what I came up with:
NEW
If an action is triggered by the receipt of a DNS NOTIFY, its
execution relies on the same security model which the receiving party
would apply if the action had been triggered by something else. This
is because the notification affects the action's timing alone. For
example, DS bootstrapping is expected to be always performed in the
same manner; this includes all applicable security and authentication
requirements (e.g., [RFC9615]) which the parent registry/registrar
has chosen to apply, independently of the type of trigger.
I've added this to the beginning of the Security Considerations.
A new revision will be submitted once other IESG feedback has been included.
Until then, you can preview changes here:
https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/pull/39/commits
<https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/pull/39/commits>
I have no blocking comments left, so once I see the new draft I will change my
DISCUSS to Yes.
Great! The above fixes are included in a fixup commit at the quoted URL. Will
submit on March 3 before the cut-off, including all other feedback that might
arrive by then.
Best,
Peter + co-authors
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
