Updating a DNSSEC config to use a different algorithm

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Updating a DNSSEC config to use a different algorithm

@lbutlr
I've been using alg-7 for DNS, but that is no longer recommended. How difficult is it to change the signing algorithm and what is the process (Bind 9.16.11)?


--
"He raised his hammer defiantly and opened his mouth to say, "Oh,
        yeah?" but stopped, because just by his ear he heard a growl. It
        was quite low and soft, but it had a complex little waveform
        which went straight down into a little knobbly bit in his spinal
        column where it pressed an ancient button marked Primal Terror."

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

Matthijs Mekking
Hi,

Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?

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

Algorithm rollover with dnssec-policy will gracefully transition to the
keys with the new algorithms, so during the rollover period you should
see your zone being signed with two algorithms.

Best regards,

Matthijs


*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]


On 01-02-2021 14:40, @lbutlr wrote:
> I've been using alg-7 for DNS, but that is no longer recommended. How difficult is it to change the signing algorithm and what is the process (Bind 9.16.11)?
>
>
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

@lbutlr
On 01 Feb 2021, at 07:14, Matthijs Mekking <[hidden email]> 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 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.

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

--
'I don't see why everyone depends on me. I'm not dependable. Even I
        don't depend on me, and I'm me.'

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

Bind-Users forum mailing list
In reply to this post by @lbutlr

On 02/02/2021 12:10 am, @lbutlr wrote:
> I've been using alg-7 for DNS, but that is no longer recommended. How difficult is it to change the signing algorithm and what is the process (Bind 9.16.11)?


I migrated recently from Alg8 to Alg13, no drama..  My registry does not
have a user portal for passing the new DS records, so the only risk was
making sure the operation took place when the registry had their DNS
support troops on deck.

My simple notes, including updating TLSA (DANE) AND DKIM keys at the end
of the process.  Hope it helps..




I have all of my zone files (db.*domain*) in /etc/bind.  Reflect your
path used when including the keys in your zone.

1.  Generate new ZSK & KSK, Alg 13
==================================

dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -r /dev/random yourdomain.com

dnssec-keygen -3 -a ECDSAP256SHA256 -r /dev/random yourdomain.com


Check for your 4 new key files:

ls -lt k*

-rw-r--r-- 1 xxxx bind    345 Jan 15 10:10 Kyourdomain.com.+013+34567.key
-rw------- 1 xxxx bind    186 Jan 15 10:10
Kyourdomain.com.+013+34567.private
-rw-r--r-- 1 xxxx bind    344 Jan 15 10:10 Kyourdomain.com.+013+42793.key
-rw------- 1 xxxx bind    186 Jan 15 10:10
Kyourdomain.com.+013+42793.private



2.  Include the new public keys in the Zone file & Increment zone serial
========================================================================

; yourdomain.com
$TTL 1200
yourdomain.com. IN          SOA   host01.yourdomain.com.
postmaster.yourdomain.com. (
                                2021020101    ; Serial.
                                12000         ; refresh
                                120           ; retry
                                14D           ; expire
                                24H           ; TTL
                                )

                        IN TXT "v=spf1 a mx ip4:77.123.45.67
ip6:2424:ae00:123:6::/64"
                       
                        ; Name Servers
                        IN      NS      host01.yourdomain.com.      ; ns
                        IN      NS      host02.yourdomain.com.      ; ns
                        IN      NS      host03.yourdomain.com.      ; ns

                        ; Mail Exchanger
                        IN      MX      10 bigmx.yourdomain.com.    ; mail

yourdomain.com.                     IN      AAAA    2424:ae00:123:6::7
yourdomain.com.                     IN      A       77.123.45.67

_25._tcp.host01.yourdomain.com.     IN      TLSA 3 1 1     
53xxxxxx..xxxx33f1b8cf81e37c2e212b
_443._tcp.host01.yourdomain.com.    IN      TLSA 3 1 1     
53xxxxxx..xxxx33f1b8cf81e37c2e212b

mail._domainkey IN      TXT     ( "v=DKIM1; h=sha256; k=rsa; s=email; "
        "p=MIIxxxxxxxxxxxxxxxx...xxxxxxdu"
        "axxxxxxxxxxxxxxxxxxxx....xxxxxAB" )

$INCLUDE        Kyourdomain.com.+013+34567.key
$INCLUDE        Kyourdomain.com.+013+42793.key

; EOF


save it right :)



3.  Sign your Zone
==================

dnssec-signzone -S -K /etc/bind/ -g -a -r /dev/random -o yourdomain.com
db.yourdomain-com


xxxx@host01:/etc/bind# dnssec-signzone -S -K /etc/bind/ -g -a -r
/dev/random -o yourdomain.com db.yourdomain-com
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
db.yourdomain-com.signed

xxxx@host01:/etc/bind#



4.  Collect your DS record HASH for the domain registry
=======================================================

Depending if you use a domain registry that you pass the DS record data
to OR a customer portal you enter this hash data yourself.  Essentially,
remove existing entries (IF you have a previous Alg8 etc in place) and
install the new DS HASH Alg13.
You will need to provide the Alg type (13) & Digest (SHA256) either
way.  "Algorithm 13, ECDSAP256SHA256" usually does the trick.

xxxx@host01:/etc/bind# ls -lt dsset*

-rw-r--r-- 1 xxxx bind    172 Jan 15 dsset-yourdomain.com.

xxxx@host01:/etc/bind# more dsset-yourdomain.com.
yourdomain.com.         IN DS 42793 13 1
42YC45643B1EF30E42BBBBA9D73BDD4EBD8B02222
yourdomain.com.         IN DS 42793 13 2
7A5A1408995DBBBBBBA92E8B575B30DC9BDD109999992F90C48C21B9A3 9A348929


Now get this record data to the registry via your registry method. 
Kettle on.



5.  Wait for Registry to complete entry & TXFR
==============================================

Check DNSVIZ for new key key ID and Alg displayed..  we all love DNSVIZ !


OR simply pass a query via DIG directly and review output:

xxxx@host01:/etc/bind# dig yourdomain.com dnskey +noall +answer +multiline

; <<>> DiG 9.9.5-9+debxxx <<>> yourdomain.com dnskey +noall +answer
+multiline
;; global options: +cmd
yourdomain.com.         1200 IN DNSKEY 257 3 13 (
                                ur4UnMMi4bDNfUEbJfRMlVQ/mxLSMF4quoPrCUopUp94
                                R9HEG6Sl9gIU9Nl73uRktnUxJspUjqrmOaWsUBcNXA==
                                ) ; KSK; alg = ECDSAP256SHA256; key id =
42793
yourdomain.com.         1200 IN DNSKEY 256 3 13 (
                               
w4SA1p/BBBrfs3216YNkQ6+xyoPkttXQNCHhoaNbPl4lI
                                l0PDL9REtOhjo54p943UNFWXg/ZHUqzZzzu321Ztgw==
                                ) ; ZSK; alg = ECDSAP256SHA256; key id =
34567
xxxx@host01:/etc/bind#



6. Update your TLSA & DKIM records
==================================

Hopefully you are using DANE with Postfix, update your host TLSA entry
for your zone:


Update TLSA:

tlsa --create --selector 1 --certificate host01.yourdomain.com.pem 
host01.yourdomain.com

xxxx@host01:/xx/xxxx# tlsa --create --selector 1 --certificate
host01.yourdomain.com.pem  host01.yourdomain.com
Got a certificate with Subject: /CN=host01.yourdomain.com
_443._tcp.host01.yourdomain.com. IN TLSA 3 1 1
FF774433KK5cdbccb18f278fccfdb833f1b8cf81e37c2e212b147D88vBBns632


Update DKIM:

cd /etc/opendkim/keys/yourdomain.com
opendkim-genkey -r -h sha256 -d yourdomain.com -s mail -b 2048

root@host01:/etc/opendkim/keys/yourdomain.com# ls -lt
-rw------- 1 opendkim opendkim 1456 Jan 5  11:05 mail.private
-rw------- 1 opendkim opendkim  502 Jan 5  11:05 mail.txt

xxxx@host01:/etc/opendkim/keys/yourdomain.com#  more mail.txt
mail._domainkey IN      TXT     ( "v=DKIM1; h=sha256; k=rsa; s=email; "
          "p=MIIxxxxxxxxxxxxxxxx...etc.. xxxxxxw22"
          "89uADXXUC/5BugylW8327dDQA18m1X...etc..F893P99xaAB )  ; -----
DKIM key mail for yourdomain.com



Place the new TLSA and DKIM records in your zone, inc Serial, re-sign. 
Job done.

Mal


_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

Matthijs Mekking
In reply to this post by @lbutlr


On 01-02-2021 17:34, @lbutlr wrote:

> On 01 Feb 2021, at 07:14, Matthijs Mekking <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

@lbutlr
On 02 Feb 2021, at 02:23, Matthijs Mekking <[hidden email]> 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).

(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).

> 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;
    };
};
#v-

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

--
I want a refund, I want a light, I want a reason for all this night
        after night after night after night

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

Matthijs Mekking


On 02-02-2021 14:40, @lbutlr wrote:

> On 02 Feb 2021, at 02:23, Matthijs Mekking <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

@lbutlr
On 02 Feb 2021, at 07:36, Matthijs Mekking <[hidden email]> wrote:
> If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits you better?

The PDF works fine, and I can search for "dnssec" and "policy" but it is using some emdash or similar character for the - in between which makes searching an issue (even if I copy the text from the PDF and then search for what.I copied).

>> (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".

Yes. I still think of them as domains (because they are all domains in my case).

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

OK, now I am a bit confused.

In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { …

Then in the zone currently I have:

zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; allow-update { key "rndc-key"; }; }

Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 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?

I did this with a domain that does not get email as a test:

#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
        keys {
           ksk key-directory lifetime unlimited algorithm 7 2048;
           zsk key-directory lifetime P60D algorithm 7 1024 ;
        };
};

zone "example.com" { type primary; file "example.com.signed"; dnssec-policy default; allow-update { key "rndc-key";}; };

; This is the state of key 2611, for mrsbutler.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
#v-

I also have new key and private and state files for the alg 7 KSK and ZSK files for the zone I am testing with, and the old files are gone, so I think it migrated correctly?

But I guess that is what you meant by it using a single key for KSK and ZSK?

Is there a reason NOT to use default? If I use default can I then eliminiate the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the new keys and state files are created?

I tried to use `rndc dnssec -checkds published example.com" but it wants a -key and doesn't seem to want the name of the .key file, so not sure what the syntax is there and the man page on rndc isn't helping. Status, on the other hand:

# rndc dnssec -status example
dnssec-policy: default
current time:  Tue Feb  2 10:01:32 2021

key: 1058 (NSEC3RSASHA1), ZSK
  published:      no
  zone signing:   no

  Key has been removed from the zone
  - goal:           hidden
  - dnskey:         hidden
  - zone rrsig:     unretentive

key: 37515 (NSEC3RSASHA1), KSK
  published:      no
  key signing:    no

  Key has been removed from the zone
  - goal:           hidden
  - dnskey:         hidden
  - ds:             hidden
  - key rrsig:      hidden

key: 2611 (ECDSAP256SHA256), CSK
  published:      yes - since Tue Feb  2 06:46:27 2021
  key signing:    yes - since Tue Feb  2 06:46:27 2021
  zone signing:   yes - since Tue Feb  2 06:46:27 2021

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             hidden
  - zone rrsig:     rumoured
  - key rrsig:      omnipresent

Am I concerned about "No rollover scheduled"? O do noe that the removal of the alg 7 from the records is a problem as the registrar still has them listed and I do not know what the digest or "Key tag" are to update the record on the registrar, so yep, I obviously did something wrong here.

Good thing I am testing.


--
"Are you pondering what I'm pondering?"
"I think so, Brain, but why would anyone want a depressed tongue?"

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Updating a DNSSEC config to use a different algorithm

Matthijs Mekking
Hi,

On 02-02-2021 18:16, @lbutlr wrote:

> On 02 Feb 2021, at 07:36, Matthijs Mekking <[hidden email]> wrote:
>> If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits you better?
>
> The PDF works fine, and I can search for "dnssec" and "policy" but it is using some emdash or similar character for the - in between which makes searching an issue (even if I copy the text from the PDF and then search for what.I copied).
>
>>> (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".
>
> Yes. I still think of them as domains (because they are all domains in my case).
>
>> 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.
>
> OK, now I am a bit confused.
>
> In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { …
>
> Then in the zone currently I have:
>
> zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; allow-update { key "rndc-key"; }; }
>
> Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 13;"?

No, sorry. I was saying don't change to "dnssec-policy default;" (which
also uses 13). Change it to the dnssec-policy that you created that
match your existing keys (alg-7).


>> 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?
>
> I did this with a domain that does not get email as a test:
>
> #v+
> named.conf:
> dnssec-policy alg13-ksk-unlimited-zsk-60day {
>          keys {
>             ksk key-directory lifetime unlimited algorithm 7 2048;
>             zsk key-directory lifetime P60D algorithm 7 1024 ;
>          };
> };
>
> zone "example.com" { type primary; file "example.com.signed"; dnssec-policy default; allow-update { key "rndc-key";}; };
>
> ; This is the state of key 2611, for mrsbutler.com.
> Algorithm: 13
> Length: 256
> Lifetime: 0
> KSK: yes
> ZSK: yes
> Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
> Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
> Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
> PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
> DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
> ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
> KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
> DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
> DNSKEYState: omnipresent
> ZRRSIGState: rumoured
> KRRSIGState: omnipresent
> DSState: hidden
> GoalState: omnipresent
> #v-
>
> I also have new key and private and state files for the alg 7 KSK and ZSK files for the zone I am testing with, and the old files are gone, so I think it migrated correctly?

Check your zone and see if they still have the alg 7 keys. If so you
probably migrated correctly. You can use "rndc dnssec -status zone" to
see about all the keys available for this zone.

What old files are gone? Named doesn't remove key files (yet).


> But I guess that is what you meant by it using a single key for KSK and ZSK?

Yes, one key that has both the KSK and ZSK role.


> Is there a reason NOT to use default? If I use default can I then eliminiate the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the new keys and state files are created?

There could be reasons not to use the default, but we think the default
policy suits most people. It has a single key and does not do scheduled
rollovers.

If you want to have scheduled rollovers, different algorithm, prefer to
have a separate KSK, tweak the signature lifetimes, etc. Then you can
create your own dnssec-policy.


> I tried to use `rndc dnssec -checkds published example.com" but it wants a -key and doesn't seem to want the name of the .key file, so not sure what the syntax is there and the man page on rndc isn't helping. Status, on the other hand:

-key id (id is the 5 digit number).


> # rndc dnssec -status example
> dnssec-policy: default
> current time:  Tue Feb  2 10:01:32 2021
>
> key: 1058 (NSEC3RSASHA1), ZSK
>    published:      no
>    zone signing:   no
>
>    Key has been removed from the zone
>    - goal:           hidden
>    - dnskey:         hidden
>    - zone rrsig:     unretentive
>
> key: 37515 (NSEC3RSASHA1), KSK
>    published:      no
>    key signing:    no
>
>    Key has been removed from the zone
>    - goal:           hidden
>    - dnskey:         hidden
>    - ds:             hidden
>    - key rrsig:      hidden
>
> key: 2611 (ECDSAP256SHA256), CSK
>    published:      yes - since Tue Feb  2 06:46:27 2021
>    key signing:    yes - since Tue Feb  2 06:46:27 2021
>    zone signing:   yes - since Tue Feb  2 06:46:27 2021
>
>    No rollover scheduled
>    - goal:           omnipresent
>    - dnskey:         omnipresent
>    - ds:             hidden
>    - zone rrsig:     rumoured
>    - key rrsig:      omnipresent
>
> Am I concerned about "No rollover scheduled"? O do noe that the removal of the alg 7 from the records is a problem as the registrar still has them listed and I do not know what the digest or "Key tag" are to update the record on the registrar, so yep, I obviously did something wrong here.

"No rollover scheduled" is fine, the default policy doesn't do scheduled
rollovers.

But your NSEC3RSASHA1 keys being removed is a sign that migration was
not performed correctly.

Most likely you started named with a dnssec-policy that did not match
those keys, and those keys did not yet have state files yet.

But I do think this is an easily made mistake so perhaps named should be
more considerate here.


> Good thing I am testing.

Always a good idea :)

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users