Hi Linda,
Thank you very much for your review! Comments below.
On 7/17/23 22:32, Linda Dunbar via Datatracker wrote:
Here are some minor issues with the draft:
- What kind of "arbitrary information about the zones"? any examples?
I'm not sure if the objective of your question is to have such examples here on
the list, or to have additional text included in the draft. I'll give some
answers here; if any of it should be included in the text, please let me know.
In general, <child domain>._signal.<other domain> is the "home" for whatever
the DNS operator wants to securely publish about the child, with the information living within a
signed zone under the operator's control (e.g. nameserver zone), and not in the customer's zone.
This signaling mechanism is specified in general terms (Section 2),
independently of its applications. The use case is then determined by the
prefix and the record type.
In the case of DNSSEC bootstrapping (specified in Section 3), the prefix
"_dsboot" is used together with CDS/CDNSKEY-type records.
Currently, no other use cases are defined, but future use cases can simply
reference the signaling mechanism from Section 2 if they use it.
One potential such use case is the key exchange that DNS providers need to perform
between each other when multiple DNS providers sign and serve the same zone
("multi-signer key exchange", see
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/).
Another one is the discovery of NOTIFY targets for generalized notifications,
https://mailarchive.ietf.org/arch/msg/dnsop/J9Ib8BhTHIwJByIA32O6i_jqDLY/ In the context discussed
there, the parent would use the mechanism to announce who is the child's registrar. For the domain
"example.org", this could be done at "_notify.example._signal.org" or similar.
- Section 3.2 (Page 6). The first step is not intuitive. does it mean nothing
needs to be performed if the child is "securely delegated"? How does the
"securely delegated" child publish information?
The protocol enables bootstrapping of secure delegations, that is, it allows
the parent to validate the child's CDS or CDNSKEY records at a time where the
child does not have a DNSSEC chain of trust yet.
When the child is already securely delegated, bootstrapping is no longer
necessary. To update the delegation's DS records, the parent can then simply
use the child's CDS/CDNSKEY records directly, as they will be accompanied by
signatures that can be validated using the already established chain of trust
(RFC 7344).
So, yes, if the child is securely delegated, nothing needs to be performed
because the delegation does not need bootstrapping anymore. -- If the operator
wants to publish information about the child in a signaling zone, that's still
possible, of course (see other use cases above). However, that doesn't concern
the steps described in Section 3.2, as those only relate to how the parent can
perform bootstrapping for the child domain.
If you have further questions, please let me know.
Thanks,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
