Generalized DNS Notifications
draft-ietf-dnsop-generalized-notify-09

[Ballot comment]
Thanks for the revised version. It addresses my previous blocking DISCUSS points (kept below for archive)

Email thread:
https://mailarchive.ietf.org/arch/msg/dnsop/Zgc5Q9c2ZAPXi9pJC6zfl2Copoo/

# ALL BELOW IS FOR ARCHIVE ONLY

## DISCUSS (previously blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 4.1

Deeply sorry, but please use only the example domains in this document rather than `mie.jp`, which is not an example/documentation domain name if not mistaken.

### Section 4.3

Where is a 'valid NOTIFY' defined in `Upon receipt of a (potentially forwarded) valid NOTIFY(CDS) `? This is also related to section 2.1 where the behavior for unknown/unspecified RRtype/scheme is not defined.

## COMMENTS (non-blocking)

### Intended status and section 7

The intended status is "proposed standard" for a rather important change (albeit if only for optimization, i.e., can fail) but there are no real live deployments yet. Did the WG consider using an experimental status first, and proposed standard after 1 year of experimentation ?

### Section 1.1

This section would be more palatable for non-DNS expert by adding some examples.

s/design requirements/design goals/ (as this is not real hard requirements)

### Section 2.3

All text is normative in a PS, but why not stressing the "should" by using a "SHOULD" in `message should be sent to the address and port listed` ?

Please explain also why some DNS servers could bypass this "should".

### Section 3

s/for discovering that notification target./for discovering that notification target(s)./ ?

### Section 3.1

Suggest instantiating all fields (scheme/port/target) of the example as done in other examples.

Should there be an informative reference for `in ICANN's model` ?

[Ballot comment]
I support John's DISCUSS.  As presented, if the expert's only instructions are to make sure the registration request has the right fields populated, could we not just use First Come First Served here?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-generalized-notify-07
CC @evyncke

Thank you for the work put into this document; even with my DISCUSS ballot, I think that this document adds value by speeding up DNS.

Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tim Wicinski for the shepherd's detailed write-up including the WG consensus *but* it lacks the important justification of the intended status (moreover, see below, I am not so sure about a "proposed standard" intended status).

Other thanks to Peter van Dijk, the DNS directorate reviewer, please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-generalized-notify-07-dnsdir-telechat-van-dijk-2025-03-03/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 4.1

Deeply sorry, but please use only the example domains in this document rather than `mie.jp`, which is not an example/documentation domain name if not mistaken.

### Section 4.3

Where is a 'valid NOTIFY' defined in `Upon receipt of a (potentially forwarded) valid NOTIFY(CDS) `? This is also related to section 2.1 where the behavior for unknown/unspecified RRtype/scheme is not defined.

[Ballot comment]

## COMMENTS (non-blocking)

### Intended status and section 7

The intended status is "proposed standard" for a rather important change (albeit if only for optimization, i.e., can fail) but there are no real live deployments yet. Did the WG consider using an experimental status first, and proposed standard after 1 year of experimentation ?

### Section 1.1

This section would be more palatable for non-DNS expert by adding some examples.

s/design requirements/design goals/ (as this is not real hard requirements)

### Section 2.3

All text is normative in a PS, but why not stressing the "should" by using a "SHOULD" in `message should be sent to the address and port listed` ?

Please explain also why some DNS servers could bypass this "should".

### Section 3

s/for discovering that notification target./for discovering that notification target(s)./ ?

### Section 3.1

Suggest instantiating all fields (scheme/port/target) of the example as done in other examples.

Should there be an informative reference for `in ICANN's model` ?

[Ballot discuss]
Thanks for this document. While my knowledge of the subject area is limited, it seems clear and well-written.

I have one point to DISCUSS. Actually, we already are discussing it, in my follow-up to Roman's ballot, https://mailarchive.ietf.org/arch/msg/dnsop/0T2AHx1K8M8U0tc7Ec0AIoEphoo/ et seq. (we wandered off of the public mailing list archive after that one though). The reason I'm capturing this as a DISCUSS point is that I think, as we discussed, what's in 07 isn't OK -- either there needs to be some kind of guidance to the Designated Expert(s), or the policy needs to be changed to one that doesn't require such guidance. I don't mind what solution is chosen, as long as there is one.

[Ballot comment]
I have only one other point to raise -- In Section 4.3 you have "NOTIFY(CDS) messages carrying notification payloads (records) for several child zones MUST be discarded, as sending them is an error." Shouldn't that be "more than one child zone" instead of "several" (which my dictionary defines as "more than two but not many")?

[Ballot comment]
Thank you to Peter E. Yee for the GENART Review.

** Section 6.2.

  The expert review should validate that the RRtype and
  Scheme do not conflict with any existing allocations.

Is this the totality of the guidance for the expert reviewer, lack of duplication?

Is more detail required given the size of the code point space?

[Ballot discuss]
I have a few questions and suggestions I'd like to DISCUSS. Part of
these might be answered by the emails on the dnsop list, but I have
not been able to follow all email there.

1) Why not use an SVCB RRtype ?

It would have more flexibility, avoid the SCHEME registry, properly
decouple CDS and CDNSKEY, and would not require a new RRTYPE.

2) Why use a numbered Scheme?

These are not very friendly to DNS admins.  I'm a semi-advanced DNS person
and still have to look up the numbers around NSEC, RRSIG, etc. If I look
at the Scheme table introduced:

CDS    1      Delegation management  (this document)
CSYNC  1      Delegation management  (this document)

Scheme value 1 seems to be "CSTYLE" sync ? Why not give it such a
name for the presentation format? Let's not make the same mistake
as with TLSA Usage that had to issue RFC7218 to introduce names for
numbers because people just never got the numbers right.

2) Why is CDNSKEY lumped in with CDS and why re-use an RRtype as signal?

I see this is explained later on in the document. It reveals that using
a single RRtype is perhaps not the best signal at all. If we are doing
a notify, why not contain the bits the child actually needs (eg which
child-side RRtypes can be consumed by the parent)

Why not instead of reusing a RRtype, use an NSEC-style bitmap value. This
way, the parent can say which RRtypes it can consume and receive notifies
for (eg CDS+CDNSKEY, or even CDS+CDNSKEY+CSYNC). This has an additional
advantage that the child can pick their preferred method in order, eg CDS,
then CDNSKEY then CSYNC, because they can determine which types the parent
supports (without lumping CDS and CDNSKEY together). It also reduces the
RRset to 1 entry per scheme at most, and doesn't weirdly munge CDS with
CDNSKEY.

Another consideration to ponder is about adding a "weight" like MX
records, so parents can convey a preference for a scheme+rrtype, which
would even allow them to signal a migration of their scanner capabilities.
This would require CDS/CDNSKEY to be split properly.

3) bootstrap ?

The document does not mention that using this mechanism to bootstrap is
not allowed. Eg if the child zone was unsigned, and it adds DNSSEC, I
don't see where this document states it CANNOT do a NOTIFY(CDS) to get
an initial DS record published. Is this intentional? 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)

Or even the case when there is no DNSSEC at the child at all, can it ask
for a CSYNC to update NS records while there is no possible authentication
of child records via DNSSEC?

It would be good to make this more clear in the protocol specification.

[Ballot comment]
Note with my old-man-hat on, I am kinda amused it took like 15 years for the
huge "triggers vs timers" discussion to come up with a solution for both timers
and triggers after all :P



        All other values are currently unspecified.

Did you mean unassigned instead of unspecified ?

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

Maybe say "if 0, ignore this DSYNC RR" ?

        Target
        [...]
        This name MUST resolve to one or more address records.

Maybe more explicitly say this can be A, AAAA, CNAME or DNAME. And
then discuss the disadvantage of indirection records?
(this is assuming that "resolve to" is meant here to allow CNAMEs? If not,
then I would like to discuss that as well :)


        If for some reason the parent operator cannot publish wildcard records,

Why accomodate for a case that should not apply anywhere. Wildcards are a core
part of the DNS protocol. Can someone explain to me why this protocol exception
is made?


        Construct the lookup name, by injecting

"injecting" seems a weird term here. We are "constructing" a QNAME.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-generalized-notify-05. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

the existing early registration will have its reference updated as follows:

TYPE: DSYNC
Value: 66
Reference: [ RFC-to-be ]
Template:
Registration Date: [ TBD-at-registration ]

Second, a new registry will be created called the DSYNC: Location of Synchronization Endpoints registry. The new registry will be located in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

The new registry will be managed via Expert Review for values 0-127 and Private Use for values 128-255 as defined in [RFC8126]. The reference for the new registry will be [ RFC-to-be ].

There are initial registrations in the new registry as follows:

RRtype Scheme Purpose Reference
0 Null scheme (no-op) [ RFC-to-be ]
CDS 1 Delegation management [ RFC-to-be ]
CSYNC 1 Delegation management [ RFC-to-be ]
2-127 Unassigned
128-255 Reserved (private use) [ RFC-to-be ]

Third, in the Underscored and Globally Scoped DNS Node Names also in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

a single new registration will be made as follows:

RR Type: DSYNC
_NODE NAME: _dsync
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that these three actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-02-06):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-generalized-notify@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Generalized DNS Notifications) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Generalized DNS Notifications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.

  To enable this functionality, a method for discovering the receiver
  endpoint for such notification message is introduced, via the new
  DSYNC record type.

  TO BE REMOVED: This document is being collaborated on in Github at:
  https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify
  (https://github.com/peterthomassen/draft-ietf-dnsop-generalized-
  notify).  The most recent working version of the document, open
  issues, etc. should all be available there.  The authors (gratefully)
  accept pull requests.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/



No IPR declarations have been submitted directly on this I-D.

(1) The RFC being requested in Proposed Standard, and this is correct.

(2)

Technical Summary:

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.

Working Group Summary:

Initially there were two different drafts discussing possible solutions. The
Working Group suggested the authors combine their work into one document, which
they did.  Consensus has been very solid.

Document Quality:

Section 7 lists an example implementation, and the authors have been working
with others to deploy this.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) no broader review needed besides the DNS directorate reviews.

(6) There are no concerns from the document shepherd.

(7) No IPR

(8) No IPR

(9) WG Consensus was solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16)  This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) There is a new registry "DSYNC Scheme Registration" which requires Expert Review.
Document has suggested procedures for Expert Review

(19) N/A

(20) No Yang

(1) The RFC being requested in Proposed Standard, and this is correct.

(2)

Technical Summary:

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.

Working Group Summary:

Initially there were two different drafts discussing possible solutions. The
Working Group suggested the authors combine their work into one document, which
they did.  Consensus has been very solid.

Document Quality:

Section 7 lists an example implementation, and the authors have been working
with others to deploy this.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) no broader review needed besides the DNS directorate reviews.

(6) There are no concerns from the document shepherd.

(7) No IPR

(8) No IPR

(9) WG Consensus was solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16)  This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate.

(18) There is a new registry "DSYNC Scheme Registration" which requires Expert Review.
Document has suggested procedures for Expert Review

(19) N/A

(20) No Yang