[DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

[Paul Vixie <[e-mail]>]

[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