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? R's, John >On Nov 8, 2023 12:06, Peter Thomassen <[email protected]> wrote: > >Dear DNSOP, > >As laid out at the DNSOP session on Tuesday, >draft-ietf-dnsop-generalized-notify (and also >draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the >parent-side endpoint >(target) where the child DNS operator can send a NOTIFY for DS update (or >other kind of signal). > >Locating the target via a DNS query needs a predictable qname and type. The >feeling from the room was >that for various reasons, a new rrtype with SVCB semantics should be used. > >As for the qname, the authors would like to gather some feedback from the list >regarding the preferred >approach. The below uses the domain "child.se" for illustration: > >Alternative #1(a): Look up record at se. (delegating parent's apex) >- Simple >- Clogs the apex with more records >- Likely does not cover all use cases (such as per-registrar target, when they >want to process the NOTIFY) > >Alternative #1(b): Look up record at _notify.se. (some underscore label below >parent) >- Slightly more complex than above >- Avoids clogging the apex, at the expense of some namespace pollution >- Covers same use cases > >Alternative #2: Look up record at child._notify.se. (or other magic label) >- Allows parent to publish per-child targets (e.g. the registrar's endpoint) > * Needs maintenance or synthesis >- Magic label could be considered namespace pollution >- Unneeded complexity if parent is not a registry (e.g. a university) > >Alternative #3: Try #2, and on failure fall back to #1(a) or #1(b) >- Combines simplicity and flexibility, but conceptually most complex >- Might cause two DNS queries > >Please weigh in on what you think is the best approach. > >Thanks, >Johan, John, Peter > >-- >https://desec.io/ > >_______________________________________________ >DNSOP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnsop > >-=-=-=-=-=- >[Alternative: text/html] >-=-=-=-=-=- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
