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.
p vixie
On Nov 8, 2023 12:06, Peter Thomassen <pe...@desec.io> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
