DNSSEC, views & trusted keys...

[Cathy Almond]

Phil Mayers wrote:
> On 09/10/2010 03:05 AM, Mark Andrews wrote:
>>
>> In message<4C891404.3000203 at imperial.ac.uk>, Phil Mayers writes:
>>> On 09/09/2010 03:45 PM, Timothe Litt wrote:
>>>
>>>>
>>>> There is other advice in the ARM that says to put 'your organization's
>>>> public keys in the trusted-keys list'.  That doesn't help - and in
>>>> fact,
>>>> confuses me even more since example.net has TWO different public
>>>> keys - one
>>>> for each view.  And trusted-keys is a global server option...
>>>>
>>>> I must be missing something.
>>>
>>> I don't think so. Currently AFAICT bind will not set AD on authoritative
>>> zones, with any combination of options.
> 
>> Add a match-recursion-only view;
> 
> Sure; that's the "right" thing, but then bind will presumably consume
> more RAM - RAM to load the authoritative zones in the internal/external
> views, and RAM to cache them in the recursive view? The OP was
> explicitly unwilling to suffer this penalty as I understood it.
> 
> TBH I have some sympathy with the OPs issue; we like to slave our zones
> to our recursive resolvers, so that when we make updates to our zones
> (via DDNS, every few minutes) IXFR will keep them in-sync without
> waiting for TTLs to expire. But then we can't get the "ad" bit.
> 
> It would be nice if there were a feature sort of like attach-cache, but
> for master zones, so that a recursive view could be told to a) skip the
> network lookup, and fetch the data direct from view N and b) never cache
> the result.

The point of the ad bit is for a validating recursive server to say 'yes
I fetched this data from somewhere else to give you, plus I used DNSSEC
to confirm that what I got was genuine, it hadn't been tampered with etc.".

You either trust the server that you just queried to send you
authoritative data (AA bit), or you trust it to validate data that it
resolved recursively for you (AD bit).  It doesn't make sense to attempt
to validate authoritative data in this scenario.

Cathy