Hi,
i think this issue shall be considered in two split cases:
a) when the *registry* is to be notified. I think this can be achieved
easily, the registry only creates a single target for child notifies.
I'm not sure if current specs allow to do it safely (so that that target
is separated enough from the rest of registry infrastructure) or any new
(but single!) record is needed for the target signalling.
b) when the *registrar* is to be notified. AFAIK registrars are so far
not at all represented anywhere in the DNS tree. I assume that the
notify target has to be settled somehow in the contract between the
registrant and the registrar.
The "alternative #2" would demand creating a new zone with as many
records (mostly CNAMEs?) as there are delegations in the registry. I'd
expect this would be operationally difficult at least from the point of
adding/removing records for the zones that are added/removed from the
registry. Aesthetically speaking, I don't like this idea.
Libor
Dne 08. 11. 23 v 18:05 Peter Thomassen napsal(a):
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
