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

[Bob Harold <[e-mail]>]

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?
>>
>
>