* John Levine: > In article <87h8kp7sqf....@mid.deneb.enyo.de> you write: >>The ZONEMD record should contain a size indicator for the zone, >>something that allows a receiver to stop downloading if it is clear >>that the served zone is too large. Otherwise, the receiver has to >>download the entire zone before it can determine that the hash does >>not match. > > I don't understand why this is a problem that needs solving. Are we > really attacked by broken zone files with large amounts of added junk, > that are so large that reading them through before discarding them is > a practical performance problem?
It's a practical problem if you want to update the zone from a completely untrusted source. I assumed that was in scope for ZONEMD. On the other hand, clients will likely have a pretty good idea for the size of the zone, so they could transfer it twice: Once for computing the authenticated size, in hashing-only mode, once they realize that the size of the new version exceeds the current version by 15% (or so). And after the authenticated size is known, they download the new version for real. This complexity could be avoided if the server simply told how many bytes have been hashed in the digest. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
