> On Jul 24, 2018, at 7:32 AM, John Levine <jo...@taugh.com> wrote: > > 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? > > I'd think that more likely problems would be that a file was > truncated, or that it was the right size but some entries are > corrupted.
I agree with John. ZONEMD is not about securing any particular transport, AXFR or what-have-you. While I wouldn't necessarily be opposed to having an RR count field of some kind if there is good reason to have it, my preference would be to omit it and keep the record simpler. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
