Well, OK, here's a concrete example. I download the COM zone every day from Verisign, and also a separate file with an MD5 hash of the main file. Using RFC 2119 language, what do I do if the hash I get doesn't match their hash? ...
Ok - you've described half of this - the download and the validation. Let's move on to the use. E.g. you now have a zone with a good ZONEMD - you throw it into what application? Or you now have a zone with a bad (unable to validate) ZONEMD, do you still throw it into the application. Does the application check the ZONEMD or did you do that manually? If you throw the zone into the application without validation then what? Do you retry to download it? How often and how long between tries?
No matter how many times you ask, the answer is the same: it depends on the application.
If it's an AXFR to a secondary authoritative server you might do one thing, if it's someone collecting stats on TLD zone files, they might do something else.
I don't see any benefit to anyone to try to guess how people we don't know will use this in applications we don't know about at unknown times in the future. Not only are we not the DNS Police, we're not the Omniscient DNS Experts either.
Please provide a general rule for automated handling of failed validations.
"Do the same thing you do now when a zone is invalid." Do the same thing you do now when a name is more than 255 octets. Do the same thing you do now when a RR has an RRTYPE of 252 or 255.Do the same thing you do now when an SOA isn't long enough to include all seven fields, or the SOAs at the beginning and end of an AXFR don't match.
Do the same thing you do now when a TXT character string is longer than the RR's RDLENGTH.
Do the same thing you do now when the offset in a compressed name points past tne end of the packet, or the pointers create a loop.
I'm sure you can come up with others. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
