Hi,
On 6/20/23 17:37, Matthijs Mekking wrote:
A note on where to send CDS and CSYNC notifications. I sort of
understand why the NOTIFY record includes a RRtype field, but will
parental entities really have a different target for receiving notifies
for CDS and CSYNC?
I've talked to Peter at some length. The problem is that you will often have
different targets for different children of the same parent, i.e., registrars
rather than registries, and I don't see any good way of putting per-child
info in the parent, particularly a large parent like .ORG or .COM.
If there are different targets for different children of the same parent, then
a generic NOTIFY record like below won't work anyway.
parent. IN NOTIFY CDS scheme port scanner.parent.
My take is that the parent should create a _signal subdomain (preferably as a
delegation). The per-child target can be queried by prepending, e.g.
_notify.example._signal.parent. IN NOTIFY CDS scheme port
scanner.registrar.example.
This way, the parent can announce the registrar's NOTIFY endpoint. This can be
synthesized dynamically, no need to maintain a large zone. As _signal can be
delegated, only one (rather normal) NS RRset is required in the parent, and the
magic can be done on a different nameserver.
Alternatively, the parent can deploy a static wildcard:
*._signal.parent. IN NOTIFY CDS scheme scanner.parent.
That would be a very small, static zone. This applies when the parent does the
scanning themself, or when they want to forward the NOTIFY to the registrar
behind the scenes. (I'm not saying this should be done; I'm saying that this
method is suitable for all kinds of scenarios.)
The existing NOTIFY for AXFR is perfectly usable without a mechanical
way to say where to send the notifications, so my proposal is to
continue not to have one. All of the existing AXFR NOTIFY receivers I
know have ACLs to only accept notifications from relevant primary
servers, often hidden ones not visible in the DNS, so even if the
proposal in 5.1 didn't have scaling problems, it only addresses half
the problem. So take it out.
I guess if the targets are fairly static, then putting it in the configuration
rather than sticking it in the DNS will be good enough.
How would a random DNS operator know the registrar of their customer zones? How
would they learn when it changes?
Cheers,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
