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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
