On 02-02-2021 14:40, @lbutlr wrote:
On 02 Feb 2021, at 02:23, Matthijs Mekking <matth...@isc.org> wrote:
1. Create a dnssec-policy that matches your current keys (so in your case 
algorithm 7, also make sure you use the same length).

So I guess something like:

    dnssec-policy alg13-ksk-unlimited-zsk-60day {
        keys {
            ksk key-directory lifetime unlimited algorithm 7 2048;
            zsk key-directory lifetime P60D algorithm 7 1024 ;
        };
    };

This is an assumption. Check the key length with your existing keys.

Yes, the current keys are alg 7 2048 bit. Is there a document on the various options here? I am 
plowing through the "BIND 9 Administrator Reference Manual, Release BIND 9.16.5 (Stable 
Release)" but it is slow going right now and "dnssec-policy" does not appear in the 
pdf in a searchable form, which makes things even more fun).

No, I could add them to the ARM. But it is the same as dnssec-signzone:

    -a <algorithm>:
        RSASHA1 | NSEC3RSASHA1 |
        RSASHA256 | RSASHA512 |
        ECDSAP256SHA256 | ECDSAP384SHA384 |
        ED25519 | ED448 | DH


If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits you better?


(This domain has a RRSIG range of 20210122220953 - 20210221230953)

I am guessing as soon as I add that DNSSEC-policy I also need to change each domain record from 
"auto-dnssec maintain;" to "dnssec-policy default;" or do I do that after the 
.state files have been created? (That doesn't sound right, but best to check).

I guess with "each domain record" you mean "each zone".

If you are migrating, don't change it to "dnssec-policy default;". This is a built-in policy that does not match your existing keys.

Instead, change it to "dnssec-policy alg13-ksk-unlimited-zsk-60day;"

Once you have .state files, you should be able to change to a different policy, including "default". Note that the default policy uses a single key (as both KSK and ZSK).


Now that you have migrated your existing key files (they will now have a .state 
file), you can reconfigure your dnssec-policy with a new algorithm,. The alg-7 
keys will be gracefully removed from the zone, while new keys with a new 
algorithm will be introduced.

So once all the domains have a .state file associated with them in the key 
directory I can change the dnssec-policy to the sample I had before and it will 
just migrate from the alg 7 keys above to alg ECDSAP256SHA256 (or I can just 
say alg 13 instead).

#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
     keys {
         ksk key-directory lifetime unlimited algorithm 13;
         zsk key-directory lifetime P60D algorithm 13;
     };
};

Yes, once all keys for the zones in question have a .state file associated with them, you should be able to change the dnssec-policy and start using ECDSA (you can use the string ECDSAP256SHA256 or the number 13).

I would recommend to first check if the .state files look correct before changing your dnssec-policy (do the keys in your zone match the .state file? Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?


- Matthijs



#v-

That seems very straightforward, there must be a catch somewhere.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to