[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 ... 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
