I agree: the "validate everything" knob seems like a win/win. I would also like the option of verifying a DNSSEC domain when I do a zone transfer, because that might be more efficient.
-- Bob Harold University of Michigan On 11/17/14 3:39 PM, Doug Barton wrote: > >> On 11/17/14 2:50 PM, Evan Hunt wrote: >> >>> On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote: >>> >>>> That seems like something that should be fixable in BIND, yes? (And >>>> thanks for doing that testing, btw) >>>> >>> >>> Yes, by using two views and slaving the root in one of them and >>> validating >>> in the other one, like it recommends in the draft. :) >>> >> >> :) >> >> With a single view, if you're authoritative for a zone, then you're >>> the authority, period. You *know* the corect answer. Validating >>> yourself >>> to find out whether you're lying to yourself would be somewhat silly. >>> >> >> ... except in the case where you're an authoritative slave, not the >> authoritative master. >> >> But even as the master, let's say you do off-line signing, and now the >> file is sitting on the name server. I would still like to see a knob >> that says "validate everything, even if I'm authoritative for it" since >> that data file may have been tampered with. Perhaps that's needlessly >> paranoid (if they can attack the file they can probably attack other >> things as well), but in the case of a validating resolver that is also >> slaving signed data, "validate everything just in case" makes a lot of >> sense to me. >> >> I would even go so far as to argue that the fact this isn't done is an >> oversight, since even if you're authoritative for a given strata there >> is always a signer a level above you. In the case of the root zone >> that's the root KSK, so even if I'm "authoritative" for the root zone I >> would still want the data in it to be validated when it's used. >> >> ... and yes, I realize that the different views (or different instances) >> trick will work, but now you're doing more work than you would have to >> do if there was a "validate everything" knob, PLUS you have the >> disadvantage of your resolving view caching data for long periods even >> though that data has changed in the slave view. So to me the "validate >> everything" knob seems like a win/win. Am I missing something? >> > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
