I got quite used to being told "stop inventing things" and as a general principle, its not such a bad thing to be told.
But it occurs to me, inventing a way to be told authoritatively where the zone cut should be might not be such a bad idea, if it was useful. If the alternative is to have to look for it, thats just a cost, I admit. But the question would stand: if we had a way to tell the delegate where the zone cut was above them, would it be useful? I think it has to be authoritative: it has to be signed so it can't be lied about. cheers -G On Thu, Dec 1, 2022 at 3:34 PM Shreyas Zare <shreyas=40technitium....@dmarc.ietf.org> wrote: > > > On 11/30/2022 6:16 AM, Mark Andrews wrote: > > 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. > > For a signed zone, finding the parent can be done by resolving for DS with > DNSSEC validation. The name server that returns DS is one of the > authoritative servers for the parent and the RRSIG in the response tells the > parent zone in the Signer's Name. The same name server can then be queried > for SOA to find MNAME for the parent zone. > > Regards, > Shreyas Zare > Technitium > > _______________________________________________ > 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
