On Wed, Jan 8, 2020 at 12:20 PM Paul Vixie <p...@redbarn.org> wrote: > [thread fork; subject changed] > > i've brought this up several times including in response to the very first > draft version. i'd like to be sure it's been considered and rejected by > the > dns technical community, rather than merely forgotten. > > ZONEMD as drafted is not incremental. so to compute it, the primary server > and > each secondary server must iterate over the entire zone contents. no > partial > products are produced that would make it cheap to simply update the MD > when > some small change to a zone has occurred. in other words ZONEMD is AXFR > optimized, and roughly ignores the various benefits of IXFR. > > some day we will fix this, so that a primary server can update an IXFR > optimized MD as a result of changes -- either by computing differences > between > an old and new zone, and BIND9 does with "ixfr-from-differences", or by > using > in-band UPDATE. this would look more like a block hash, because each new > MD > would be computed from (previous MD) + (zone change). > > i am not asking that we fix this today. what i am asking for is future- > proofing. > > can we please not put the ZONEMD RR at the apex, or else, can we please > add an > ALG-ID to its rdata. because some day we're going to ship different kinds > of > MD's, one of which is today's full-zone traversal-required version that > optimizes for AXFR, and another will be tomorrow's block hash that > optimizes > for IXFR. > > so either: > > $ORIGIN verisign.com. > @ SOA ... > @ NS ... > @ ZONEMD 1 ... ;; computed by full zone traversal only > @ ZONEMD 2 ... ;; computed by full traversal or incremental block hash > > or else: > > $ORIGIN verisign.com. > @ SOA ... > @ NS ... > _axfr ZONEMD ... > _ixfr ZONEMD ... > > I like the general format of the second one, as it is easy to tease out only the current stuff. It also avoids the issues with internal structure that has been recommended against.
The specifics of the "_ixfr" label would be an interesting area to think about in terms of owner name scheme, at some later time. (E.g. <new-SN>.<old-SN>._ixfr, possibly in their own NSEC zone hierarchies for easy enumeration, as this is one case where enumeration is good.) Brian > or something else that accomplishes the same goal, which is that today's > and > tomorrow's MD can coexist, and be used opportunistically by dev or ops > policy. > > vixie > > > _______________________________________________ > 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
