Updating a DNSSEC config to use a different algorithm
Matthijs Mekking
matthijs at isc.org
Wed Feb 3 08:16:26 UTC 2021
Hi,
On 02-02-2021 18:16, @lbutlr wrote:
> On 02 Feb 2021, at 07:36, Matthijs Mekking <matthijs at isc.org> 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
More information about the bind-users
mailing list