Hi Paul,
Thank you very much for your thorough review!
On 2/26/25 04:11, Paul Wouters via Datatracker wrote:
----------------------------------------------------------------------
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.
Indeed, some of the below has been discussed by the WG before. We'll put
pointers as appropriate.
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.
Regarding decoupling: a child DNS operator should not need to know whether the parent
prefers to ingest CDS- or CDNSKEY-style format. The child can choose to publish both, and
then only needs to send a hint meaning "go look for a DS update". This
observation is independent of whether SVCB or a new RRTYPE is used.
As for SVCB, the WG has discussed this on various occasions and rejected the idea. Ben
Schwartz first pointed out that SVCB would require a URI scheme like
"dns-notify://ns1.example.com/..." [1]. At the DNSOP session at IETF 118
(Prague), several people opposed SVCB and suggested using a new (possibly similar) type
[2]. SVCB was brought up again during Dnsdir review; it was subsequently observed that
SVCB increases complexity on the child DNS operator side, especially in AliasMode
(whereas CNAME is supported everywhere) [3]. In response to Dnsdir, the authors put the
question again in front of the WG at IETF 120 (Vancouver), where folks were once more in
favor of a new type [4].
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/Upx44ZrnPfA-zRSxUXN7lPiv-5M/
[2]: https://datatracker.ietf.org/doc/minutes-118-dnsop/
[3]: https://mailarchive.ietf.org/arch/msg/dnsop/LFsvddryRr-aYM3BTGyo7My1bD0/
[4]: https://datatracker.ietf.org/doc/minutes-120-dnsop/
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.
Good call!
Scheme value 1 is not "CSTYLE sync"; rather, the scheme is about how to contact
the endpoint (here: via DNS NOTIFY; another scheme could be: via DNS UPDATE, or via a
REST call).
But, of course it's indeed easier with a mnemonic. We've added this to the
draft.
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.
The NOTIFY message was re-used because the purpose of the notification is to tell the
parent registry/registrar: "please do now whatever you would do if your delegation
scanner had expired", in full analogy to a secondary doing an early XFR.
It is not in scope for the sender of this notification to know about the things
that the parent would do in response, or for the parent to somehow signal its
policy. While that is also conceivable, this protocol is designed to remove the
downsides of periodic scanning with minimal overhead.
The authors fail to see what a weight field would have to do with (not)
splitting the CDS/CDNSKEY signals. A weight field would certainly be
conceivable, but did not come up during consideration by the WG (probably
because it would be far more complex).
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?
Yes; in fact it is allowed, as noted in the abstract and in Section 4. Note
that the notification message does not carry any sensitive information; rather,
it's a hint for the parent to do whatever if would do later based on
CDS/CDNSKEY scanning. That is, if the parent does DS bootstrapping through
*some* mechanism, then the notification allows earlier execution. There's no
reason to disallow bootstrap triggering through NOTIFY.
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.
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?
No, because CSYNC requires DNSSEC (see last paragraph of RFC 7477 Section 2).
Again, a notification is just a nudge for the parent to look for CSYNC now (as
opposed to later); it does not change any of the CSYNC processing itself.
----------------------------------------------------------------------
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
:-) The young hats are amused about this as well.
All other values are currently unspecified.
Did you mean unassigned instead of unspecified ?
Yes, will fix.
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" ?
Sure; we added: "Records with value 0 are ignored by consumers." (reusing
language used for scheme=0)
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 :)
The authors believe that the concepts of different address families and CNAME/DNAME
indirection are included in the notion of "resolving", and that this document
is not the right place to discuss indirection. The authors also don't think it's clearly
a disadvantage for a registrar to put a CNAME on their endpoint target (for example).
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?
This provision was included to address concerns that gTLD operators would, for
policy reasons, not be allowed to include wildcards in their zones. Despite
attempting to clarify, there is no consensus about the conditions under which
this is (not) the case. Authors agree that if operators end up using wildcards,
that's even better.
Construct the lookup name, by injecting
"injecting" seems a weird term here. We are "constructing" a QNAME.
Yep, changed to "inserting".
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
Thanks again,
Johan, John, Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
