Hi, > Subject: Call for adoption: draft-johani-dnsop-delegation-mgmt-via-ddns-06 > (Ends 2025-12-18) > > This message starts a 2-week Call for Adoption for this document. > > Abstract: > Delegation information (i.e. the NS RRset, possible glue, possible DS > records) should always be kept in sync between child zone and parent > zone. However, in practice that is not always the case. > > When the delegation information is not in sync the child zone is > usually working fine, but without the amount of redundancy that the > zone owner likely expects to have. Hence, should any further > problems ensue it could have catastropic consequences. > > The DNS name space has lived with this problem for decades and it > never goes away. Or, rather, it will never go away until a fully > automated mechanism for how to keep the information in sync > automatically is deployed.
Yes please.
It should not surprise anyone that I, being one of the authors, am strongly in
favor of adoption of this draft.
Among the reasons:
* I am not aware of *any* other proposal that would provide automatic
synchronization of delegation information for *any* child zone, signed or
unsigned. That by itself makes this highly relevant.
* While the DNS protocol has supported the suggested mechanism for 20 years it
has not previously been of general practical use (primarily not knowing where
the child should send the update and specifically not sending the update
directly to a parent nameserver). Both of these problems are solved by the
DSYNC record (RFC 9859).
* Other advances in recent years have led to multiple standardized methods for
automatic bootstrapping of DNSSEC-signed delegations (RFC 8078 and RFC 9615).
It is almost like we have a small jigsaw puzzle of the three things that I list
above and when you look at the puzzle there is one, single, piece missing and
it is shaped like:
“automatic synchronization of delegation information via DDNS, using
keys automatically bootstrapped a la RFC 8078/9615 and the signed
update sent to the designated parent side
receiver as announced a la RFC 9859”.
And that’s the missing piece that this draft aims to fill.
Regards,
Johan Stenstam
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
