> On 30 Nov 2022, at 00:07, 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.
Remove the left most label and query for the SOA record. If you get a SOA record back in the answer you have the parent zone. If you get a CNAME back remove one more label and repeat. If you get a NODATA response look in the authority section for the negative cache SOA record. If it is not present remove one label and repeat. nsupdate has been doing this for 2 decades now to determine the enclosing zone for UPDATE requests. There is absolutely no reason why authoritative servers can’t make such queries all by themselves. They already make queries to obtain the address of nameservers to determine where to send NOTIFY messages. > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
