Re: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

[Matthijs Mekking]

Hi Andrej,

While I am not 100% sure on your use case, let me at least respond to this:

 > But I’m starting to realize that I had misunderstood and
 > overcomplicated things; simply referencing the "standard" policy again
 > from equivalent zones in different views should (?) magically work (as
 > Nick Tait pointed out in another message). If that’s the case, then my
 > concerns around forcing exactly one instance of a zone to maintain the
 > keys and forcing all other instances to passively consume keys are
 > null and void.
...
 > So eventually it may be as simple as replacing “auto-dnssec maintain;”
 > with “dnssec-policy "standard";” and *not* worrying about having
 > exactly one “key producing” instance of each zone, because Bind can
 > handle this automatically. (?) I’ll give that a try.

That is correct: When you have the same zone (identical name) in 
multiple different views that refer to the same dnssec-policy, there 
will be only one set of keys maintained that is shared for that zone in 
all views.

Best regards,

Matthijs



On 4/17/23 13:03, Andrej Podzimek wrote:
> Hi Matthijs,
> 
> Thanks for your response.
> 
>>>           dnssec-policy "ReuseKeysFromTheMainView" {
>>>             keys {
>>>               ksk key-directory lifetime unlimited algorithm 
>>> ecdsap384sha384;
>>>               zsk key-directory lifetime unlimited algorithm     ;
>>>             };
>>>             nsec3param salt-length 16;
>>>             publish-safety P1D;
>>>             retire-safety P1D;
>>>           };
>>
>> When looking for the dnssec-policy equivalent of auto-dnssec, you will 
>> need to look at your current zone signing settings to determine the 
>> policy.
>>
>> Look at your current keys and check their algorithm and key length. 
>> From your policy excerpt from above it looks like you are using a 
>> KSK/ZSK strategy with algorithm ECDSAP384SHA384 (14).
>>
>> Key rollovers were done outside of BIND9, either manually or scripted. 
>> So "lifetime unlimited" makes sense here.
> 
> The dnssec-policy example above was meant to serve as an auto-dnssec 
> equivalent that passively consumes keys, not “the real thing”. That’s 
> why it’s called “ReuseKeysFromTheMainView”. The policy that actually 
> generates the key files looks like this (and has a finite lifetime):
> 
>           dnssec-policy "standard" {
>             keys {
>               ksk key-directory lifetime 361d algorithm ecdsap384sha384;
>               zsk key-directory lifetime 61d algorithm ecdsap384sha384;
>             };
>             nsec3param salt-length 16;
>             publish-safety P1D;
>             retire-safety P1D;
>           };
> 
>>> There are at least two concerns:
>>>
>>> (1) Will the dependent “unlimited lifetime” views automatically pick 
>>> up the key updates made by the main “limited lifetime” view (instead 
>>> of blindly expecting the key files to never change)?
>>
>> Sorry, I fail to understand what dependent "unlimited lifetime" views 
>> are, and what the main "limited lifetime" view is.
>>
>> Are you perhaps asking how to initiate a key rollover with dnssec-policy?
> 
> The “limited lifetime” view’s zones reference the "standard" policy 
> directly.
> An “unlimited lifetime” view’s zones reference keys generated by the 
> "standard" policy. This is currently achieved using “auto-dnssec 
> maintain”. Later, once auto-dnssec is gone, I thought that referencing 
> the fake "ReuseKeysFromTheMainView" policy would yield a similar behavior.
> 
>>> (2) Which of the additional parameters have to be repeated in 
>>> dependent “auto-dnssec-like”  zones that don’t generate their own keys?
>>>      * The salt-length seems irrelevant (set and fixed at key 
>>> generation time).
>>>      * But how (if at all) will publish-safety and retire-safety work 
>>> int his strange setup?
>>
>> What are "auto-dnssec-like" zones? Zones that don't use 
>> "dnssec-policy"? In that case, for such zones "publish-safety" and 
>> "retire-safety" have no effect.
> 
> IIUC, all my zones in all views will have to switch to dnssec-policy, 
> eventually, once auto-dnssec ceases to exist.
> 
> But I’m starting to realize that I had misunderstood and overcomplicated 
> things; simply referencing the "standard" policy again from equivalent 
> zones in different views should (?) magically work (as Nick Tait pointed 
> out in another message). If that’s the case, then my concerns around 
> forcing exactly one instance of a zone to maintain the keys and forcing 
> all other instances to passively consume keys are null and void.
> 
> (As a side note, the best zone sharing option (which already works for 
> me in some cases) is the “in-view” pointer, which automatically copies 
> all zone settings, including the "standard" DNSSEC policy. The reason 
> why certain zones are (re)defined in other views rather than linked 
> using “in-view” is a need for different zone data, different 
> “allow-query” settings etc.)
> 
> So eventually it may be as simple as replacing “auto-dnssec maintain;” 
> with “dnssec-policy "standard";” and *not* worrying about having exactly 
> one “key producing” instance of each zone, because Bind can handle this 
> automatically. (?) I’ll give that a try.
> 
> Cheers!
> Andrej