On 8 Nov 2023, at 19:39, John R Levine <[email protected]> wrote: > >> >> >>> It appears that Paul Vixie <[email protected]> said: >>>> -=-=-=-=-=- >>>> None of the above. Do what RFC 2136 does to send updates to the primary >>>> authority, or do what RFC 1996 >>>> does to send notifications to all listed authorities. Any new signaling is >>>> effectively a way to go out >>>> of band. The system is complete as it is. >>> >>> Without manual configuration, how is the child supposed to know where to >>> find >>> the stealth parent to notify? >> >> Neither of the mechanisms Paul suggested require manual configuration. > > I am clearly missing something here. The child zone wants to notify the > parent to tell it to pick up some new DNSSEC keys or something. The parent's > NS are A, B, and C, but the notify needs to go to stealth server X or maybe > registrar server R.
In 2136, the UPDATE client wants to send a message to an UPDATE server without any manual configuration. It needs to know what server to use. It retrieves the zone's SOA RR and uses whatever it finds in SOA.MNAME, which could be X or R or A, B or C. In 1996, a NOTIFY client wants to send a message to a NOTIFY server without any manual configuration. It retrieves the zone's apex NS RRSet and uses whatever it finds in the NS targets, sending the same message to each of A, B or C. > How does the child know where to send the notification? I think the idea is that these two existing and well-implemented mechanisms should be considered first to see if they fit before anybody goes to the trouble of inventing new ones. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
