It appears that Peter Thomassen <pe...@desec.io> said: >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.
While I can see how that might work in principle, I find it hard to imagine registries and registrars making it work. At the least it'd need new EPP stuff to tell the registry what signal records to add or delete. >> 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? They'd ask the customer "who's your registrar" when they set up the zone. This still misses the hard part about how the notify knows where to expect the notifies from. I suppose by default it could be the delegated NS, but in interestingly large setups, that's not likely to be adequate. If the customer changes registrars, they have to tell the DNS operator but that's easier than the current hacks to try and move DS records from one registrar to another. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
