On 01-02-2021 17:34, @lbutlr wrote:
On 01 Feb 2021, at 07:14, Matthijs Mekking <matth...@isc.org> wrote:
Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?
These are all good questions, and when I set this up I could have
answered with some degree of confidence.
What I have in named.conf is simply dnssec-validation auto; and
domains have auto-dnssec maintain, so I guess that answers that
question.
Yes there are a lot of ways to maintain DNSSEC in BIND. The
recommended way forward is to use dnssec-policy. Migrating to it
may still be a bit tricky*, but once you use it, changing a new
signing algorithm is pretty simple:
1. Update your dnssec-policy, reload config.
Assuming there is no dnssec-policy (there is not) what would I update
it to?
This did give me enough to DDG on, does this link look reasonable?
<https://serverfault.com/questions/1007899/how-to-migrate-bind-configuration-to-dnssec-policy-from-auto-dnssec-maintain-wit>
#v+ dnssec-policy alg13-ksk-unlimited-zsk-60day { keys { ksk
key-directory lifetime unlimited algorithm ECDSAP256SHA256; zsk
key-directory lifetime P60D algorithm ECDSAP256SHA256; }; }; #v-
If you switch to dnssec-policy, before you change your algorithm you
have to migrate the old keys.
You can use two methods:
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.
2. You can also initialize the key states manually with dnssec-settime:
Key state options:
-s: update key state file (default no)
-g state: set the goal state for this key
-d state date/[+-]offset: set the DS state
-k state date/[+-]offset: set the DNSKEY state
-r state date/[+-]offset: set the RRSIG (KSK) state
-z state date/[+-]offset: set the RRSIG (ZSK) state
dnssec-settime -s -g OMNIPRESENT now -d OMNIPRESENT now \
-k OMNIPRESENT now -r OMNIPRESENT now <kskfile>
dnssec-settime -s -g OMNIPRESENT now -k OMNIPRESENT now \
-z OMNIPRESENT now <zskfile>
It is a bit technical, but this would make your existing key files ready
to for dnssec-policy. Use this if your zone is correctly signed at the
moment, and the DS is in the parent for some time.
Algorithm rollover:
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.
If so, what are the possible values for the algorithm? And for the
actual policy (alg13-…)? I also see mention of a dissed-policy
default but that is out of context so I don't know if that is simply
telling the domain to use the policy defined separately in the the
named.conf as above. Alg13-ksk gives two hits on DDG, and the second
one is in Japanese.
Algorithm 13 (ECDSAP256SHA256) is a good choice. It is becoming best
practice, it is as popular as algorithm 8 (RSASHA256)*, and the majority
of resolvers can validate with this algorithm**
* https://stats.dnssec-tools.org/
** https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-an-update/
2. Wait a little bit. 3. When the new DS is in the parent, run
"rndc dnssec -checkds published on the right key id." 4. Also run
"rndc dnssec -checkds withdrawn" on the id of the key that has its
DS removed from the parent. 5. Have a celebratory drink.
Way ahead of you there! 🥃
*In principal you can just switch to dnssec-policy with your
existing key files and BIND will initialize key state files for
those keys. But there is at least one known bug that deleted keys
may be used again for signing (those deleted keys still have their
key files in the key directory). [GL #2406]
Hopefully that will not be an issue as there are no old key files. Or
rather they are all about the same age of Jan-Feb of 2019,
This bug affects key files that exist but have their "Inactive" and/or
"Delete" timing metadata in the past.
Best regards,
Matthijs
_______________________________________________
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
