Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

[Doug Barton <[e-mail]>]

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?

Doug