The question at the end of this post was a serious one, FWIW.
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
