You might want to dig into the ancient discussion thread of “timers vs triggers”.
The main concern at the time was they TLDs didn’t want any kind of triggers hitting their production nameservers. Paul Sent using a virtual keyboard on a phone > On Nov 29, 2022, at 08:08, Joe Abley <jab...@hopcount.ca> wrote: > > On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen <pe...@desec.io> > wrote: > >> At the IETF a few weeks back, Johan and I felt a sudden >> enlightenment when it occurred to us that the same approach >> could be used to reduce scanning cost for CDS/CSYNC scans and >> the like, while maintaining low update latency. In fact, the >> NOTIFY spec already does allow sending NOTIFY message of other >> types. So, we not use that for hinting beyond SOA? > > I have wondered aloud about reusing NOTIFY for other purposes in the past > too. In fact I seem to remember a certain tall Swede referring to > draft-jabley-dnsop-dns-flush as abolutely the worst idea he had ever heard > of, a review which I continue to wear as a badge of pride. > > One question occurs to me after reading your draft: you suggest in a couple > of places that it's easy for a nameserver that is authoritative for a child > zone to know the name of the parent zone. How? > > For example, if a nameserver serves the zone a.b.c.d.child, how does it > determine whether the parent zone is the root, a, a.b, a.b.c or a.b.c.d? It > needs to know in order to find the SRV (or whatever) records that point to > the appropriate NOTIFY targets in the case where the parent zone operator > signals the target. Does it send multiple queries? Does it confirm the > existence of a zone cut in each case by looking for secure delegations or SOA > RRs or both? It seems important to get this right. > > Separately, it might be worth specifying that all NOTIFY targets obtained > through the DNS MUST be subject to DNSSEC validation and that the DNS > responses involved must be verifiably secure. I can't immediately think of an > exploit that would derive from the ability for a third party to receive such > NOTIFY messages but it seems entirely plausible that there is one. > > In the case of conventional use of NOTIFY it's common for the NOTIFY/*XFR > graph to involve servers other than those published in NS sets. In some cases > it is desirable for the identity of those NOTIFY targets not to be published, > e.g. since they refer to internal infrastructure and are not intended to be > used/abused by others. Have you thought about whether there are any similar > considerations for these new uses of NOTIFY? I guess one answer is that (just > like conventional NOTIFY) local policy could override the SRV-published > (NS-published) targets. > > > Joe > > _______________________________________________ > 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
