Hi Libor,
On 11/9/23 12:12, libor.peltan wrote:
i think this issue shall be considered in two split cases:
a) when the *registry* is to be notified. [...]
b) when the *registrar* is to be notified. [...]
The sender of the NOTIFY does not know whether, for this particular parent, the
registry or the registrar is in charge of processing. They could keep some ugly
list about this, but then also that list could get outdated.
In my view, it is therefore a requirement for the discovery method to cover
both cases (so, the solution can't be derived from considering them
independently).
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.
The zone doesn't need to be statically populated. It may be a service that
looks in the registry database and returns the corresponding data.
This is not unlike the bootstrapping signaling, which people don't statically
provision: If you query CDS _dsboot.thomassen.io._signal.ns1.desec.io, you get
a synthesized and dynamically signed answer with thomassen.io's CDS record
data. Cloudflare does the same.
Perhaps we should let go of the mental model of statically configured zones.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
