DNSSEC upgrade

[Edwardo Garcia]

Halo all,

Many year ago we set up DNSSEC, our key were generated with sha1 as was
recommended way back all them years. We too are not DNSSEC guru, so some
answer may be simple

Now we want to upsecure this to sha256.

Also we use ZSK -b 1024 and KSK -b 4096
even modern google from apnic show example ZSK of only 1024? is this still
secure?

Is best practise for doing this, replacing the keys completely, more or
less like start fresh again?

We do use inline signing and automatic maintain.

I see 9.16 make it easy by not needing do anything but set policy, but we
are stuck on 9.14 for time being.

I am ok with wiping DS, keys everything and start fresh if that is easiest,
unless there is another simple way?

[Tony Finch]

Post by Edwardo Garcia
Many year ago we set up DNSSEC, our key were generated with sha1 as was
recommended way back all them years. We too are not DNSSEC guru, so some
answer may be simple

Well, you are going to do an algorithm rollover, which is one of the more
tricky things you can do with DNSSEC. So, plan to do some testing, a trial
run, with a spare zone that you can break without worrying.

If you like to understand things by getting an idea of the wider context
then there are a couple of RFCs on the general subject of key rollovers.
The parts that are most relevant are the algorithm rollover section in RFC
6781 and the double-KSK section in RFC 7583.

https://tools.ietf.org/html/rfc6781
https://tools.ietf.org/html/rfc7583

DNSSEC has got easier since those RFCs were written, so you might as well
just skip to the howto bits below :-) It turns out, I wrote most of this
reply over a year ago...

Post by Edwardo Garcia
Also we use ZSK -b 1024 and KSK -b 4096
even modern google from apnic show example ZSK of only 1024? is this still
secure?

The current recommendation for DNSSEC algorithms is:

* you already know you want to choose something based on sha256 - it's
secure enough, so there's no need for bigger hashes

* ecdsa-p256-sha256 (13) is the best choice, because it is widely
supported and produces small signatures

* if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits
is not secure; 2048 has a roughly comparable security level to sha256
(112ish bits vs 128 bits); 4096 is big and slow and probably not worth
the cost

* I would like to be able to deploy ed25519 (a better elliptic curve
than p256) but it is not yet supported well enough

Post by Edwardo Garcia
Is best practise for doing this, replacing the keys completely, more or
less like start fresh again?
We do use inline signing and automatic maintain.

I did a wholesale algorithm rollover from RSASHA1 to p256 around the end
of 2019 and I wrote an algorithm rollover guide for colleagues in other
parts of our university who run their own DNS. It's basically three steps
with lots of waiting in between:

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

The "Semi-automated DS updates" section probably isn't relevant to you,
and the "Future" section has been made obsolete by dnssec-policy. But the
rest of it should guide you through the essentials.

(Also, the RIPE NCC does now support CDS records.)

And use these DNS checking services to verify that it is working as
expected:

https://dnsviz.net/

https://zonemaster.net/

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
occasionally 3 later. Slight or moderate. Showers. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Edwardo Garcia]

Halo Tony,
Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the size of rsa,
strange how this better but we have made change as
from your howto, thank you, now 24 hour and all seems ok from what we tell,
and the test site says all good.

One question however it talk about longest TTL, does this mean also root
TLD zones (.com, .net) which from memory are 48 hours, so before we delete
old keys we need wait 48 hours, even though our zone TTL was 24 ?

Thank you, wow much much easy than I hoped for :-)

Post by Tony Finch

Post by Edwardo Garcia
Many year ago we set up DNSSEC, our key were generated with sha1 as was
recommended way back all them years. We too are not DNSSEC guru, so some
answer may be simple

Well, you are going to do an algorithm rollover, which is one of the more
tricky things you can do with DNSSEC. So, plan to do some testing, a trial
run, with a spare zone that you can break without worrying.
If you like to understand things by getting an idea of the wider context
then there are a couple of RFCs on the general subject of key rollovers.
The parts that are most relevant are the algorithm rollover section in RFC
6781 and the double-KSK section in RFC 7583.
https://tools.ietf.org/html/rfc6781
https://tools.ietf.org/html/rfc7583
DNSSEC has got easier since those RFCs were written, so you might as well
just skip to the howto bits below :-) It turns out, I wrote most of this
reply over a year ago...

Post by Edwardo Garcia
Also we use ZSK -b 1024 and KSK -b 4096
even modern google from apnic show example ZSK of only 1024? is this

still

Post by Edwardo Garcia
secure?

* you already know you want to choose something based on sha256 - it's
secure enough, so there's no need for bigger hashes
* ecdsa-p256-sha256 (13) is the best choice, because it is widely
supported and produces small signatures
* if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits
is not secure; 2048 has a roughly comparable security level to sha256
(112ish bits vs 128 bits); 4096 is big and slow and probably not worth
the cost
* I would like to be able to deploy ed25519 (a better elliptic curve
than p256) but it is not yet supported well enough

Post by Edwardo Garcia
Is best practise for doing this, replacing the keys completely, more or
less like start fresh again?
We do use inline signing and automatic maintain.

I did a wholesale algorithm rollover from RSASHA1 to p256 around the end
of 2019 and I wrote an algorithm rollover guide for colleagues in other
parts of our university who run their own DNS. It's basically three steps
https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
The "Semi-automated DS updates" section probably isn't relevant to you,
and the "Future" section has been made obsolete by dnssec-policy. But the
rest of it should guide you through the essentials.
(Also, the RIPE NCC does now support CDS records.)
And use these DNS checking services to verify that it is working as
https://dnsviz.net/
https://zonemaster.net/
Tony.
--
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
occasionally 3 later. Slight or moderate. Showers. Good.

[Mark Elkins]

Waiting twice the TTL is the safe option. Start counting from when you
see the new DS record in the parent. To be even more pedantic, start
counting after all authoritative Nameservers have the new DS record...
Quite easy to do from a script.

And the recommendation to move to ecdsa-p256-sha256 is a good one -
makes you a lot less appetising to be used in a DNS amplification attack.

Post by Edwardo Garcia
Halo Tony,
Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the size of rsa,
strange how this better but we have made change as
from your howto, thank you, now 24 hour and all seems ok from what we
tell, and the test site says all good.
One question however it talk about longest TTL, does this mean also
root TLD zones (.com, .net) which from memory are 48 hours, so before
we delete old keys we need wait 48 hours, even though our zone TTL was
24 ?
Thank you, wow much much easy than I hoped for :-)

Post by Edwardo Garcia
Many year ago we set up DNSSEC, our key were generated with sha1

as was

Post by Edwardo Garcia
recommended way back all them years. We too are not DNSSEC guru,

so some

Post by Edwardo Garcia
answer may be simple

Well, you are going to do an algorithm rollover, which is one of the more
tricky things you can do with DNSSEC. So, plan to do some testing, a trial
run, with a spare zone that you can break without worrying.
If you like to understand things by getting an idea of the wider context
then there are a couple of RFCs on the general subject of key rollovers.
The parts that are most relevant are the algorithm rollover section in RFC
6781 and the double-KSK section in RFC 7583.
https://tools.ietf.org/html/rfc6781
<https://tools.ietf.org/html/rfc6781>
https://tools.ietf.org/html/rfc7583
<https://tools.ietf.org/html/rfc7583>
DNSSEC has got easier since those RFCs were written, so you might as well
just skip to the howto bits below :-) It turns out, I wrote most of this
reply over a year ago...

Post by Edwardo Garcia
Also we use ZSK -b 1024 and KSK -b 4096
even modern google from apnic show example  ZSK of only 1024? is

this still

Post by Edwardo Garcia
secure?

  * you already know you want to choose something based on sha256
- it's
    secure enough, so there's no need for bigger hashes
  * ecdsa-p256-sha256 (13) is the best choice, because it is widely
    supported and produces small signatures
  * if you must use RSA, use 2048 bit keys for both zsk and ksk.
1024 bits
    is not secure; 2048 has a roughly comparable security level to
sha256
    (112ish bits vs 128 bits); 4096 is big and slow and probably
not worth
    the cost
  * I would like to be able to deploy ed25519 (a better elliptic curve
    than p256) but it is not yet supported well enough

Post by Edwardo Garcia
Is best practise for doing this, replacing the keys completely,

more or

Post by Edwardo Garcia
less like start fresh again?
We do use inline signing and automatic maintain.

I did a wholesale algorithm rollover from RSASHA1 to p256 around the end
of 2019 and I wrote an algorithm rollover guide for colleagues in other
parts of our university who run their own DNS. It's basically three steps
https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
<https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html>
The "Semi-automated DS updates" section probably isn't relevant to you,
and the "Future" section has been made obsolete by dnssec-policy. But the
rest of it should guide you through the essentials.
(Also, the RIPE NCC does now support CDS records.)
And use these DNS checking services to verify that it is working as
https://dnsviz.net/ <https://dnsviz.net/>
https://zonemaster.net/ <https://zonemaster.net/>
Tony.
--
https://dotat.at/ <https://dotat.at/>
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
occasionally 3 later. Slight or moderate. Showers. Good.
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

Post by Edwardo Garcia
One question however it talk about longest TTL, does this mean also root
TLD zones (.com, .net) which from memory are 48 hours, so before we delete
old keys we need wait 48 hours, even though our zone TTL was 24 ?

When you are waiting after adding and signing with the new keys and before
swapping the DS records, it's only the longest TTL in your own zone that
matters. In my notes I call this the "child TTL" because the root and TLD
etc. don't matter.

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

When you're waiting for the DS TTL it's only the TTL of that particular
record that matters. (It's in the parent zone so I called it the parent
TTL.) To be sure you are getting the right number you will need something
like:

dig +ttlunits example.com ds @$(dig +short com ns | head -1)

i.e. pick one of the nameservers of the parent zone and ask it for your
zone's DS record, so you don't get mislead by decremented cached TTLs.
Note the DS TTL is often not the same as the parent NS or glue TTL.

Post by Edwardo Garcia
Thank you, wow much much easy than I hoped for :-)

I'm happy it helped!

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Biscay: North, backing northwest later, 2 to 4, occasionally 5 later
in east. Slight. Showers. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[@lbutlr]

I update the last of my zones over a month ago and they are still showing alg-7. The longest TTL int e zone files is 2w, but we're 29 days in.

Te signed file has

RRSIG SOA 7 2 86400 (
20210509074649 20210425064649 45309 example.com.
Oj+ObzW/dle9fJHffNqNCVd9udd8AQwxRXcq/BF5+fUu
wyS5Gb0htl2hrwyAXK24sA4aZ4RUiwNoKwJTeOGZPWeC
O2Eb2PkjsNUmd9UaIWKYrFroI8FZsqh4g8lM/YEdnpAq
GeekIXFT4s6xE8lRC3Rcx88b8YBRNnSxiy/8xqI= )
RRSIG SOA 13 2 86400 (
20210509074649 20210425064649 11217 example.com.
yzrM5cWL6UYhzJ4cS+hMcZShBqwFZZR6LVRYntehHzVN
vBSzUBNNf6u6BdQSAyQFbjD5R9g5HEKtei1yIADx8g== )

I'm sure I missed a step on these specific domains, but there are only a handful that are still using alg-7 and many more that are now on alg-13 only. The +ttlunits from above show 1d for the answer sections and 2d in the authority (com.) section.

If I do a dig ds on the domain (at 8.8.8.8 or others, in addition to my own bind server), I only get the alg-13 key, but +dnssec shows both RRSIGs

Ideas?
--
'Somewhere, A Crime Is Happening,' said Dorfl. --Feet of Clay

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

Post by @lbutlr
I update the last of my zones over a month ago and they are still
showing alg-7.
I'm sure I missed a step on these specific domains, but there are only a
handful that are still using alg-7 and many more that are now on alg-13
only.

Hmm, curious!

If you have swapped the DS records already, then all that is left to do is
remove the remains of the old algorithm. Have a look at the keys for the
problem zones like this:

grep ^ Kexample.com.*.key

The algorithm 7 keys should all have inactive and delete times. If some of
the times are missing then you can fix it by re-doing the "decommission
old algorithm" step in my notes. It should get cleaned up immediately.

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

If that doesn't fix it, then the problem is elsewhere...

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Forties, Cromarty, Forth: North or northeast 2 to 4. Slight
occasionally moderate. Showers. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Edwardo Garcia]

One thing I note, all check say everything is good, but when using dnsviz,
it says secure, shows the ecd... but also puts up warnings that I am using
alg 13 but digest 1 (sha1), which is not allowed, I never use the setting
when create keys as the guide says not needed, if this a problem with them
or maybe the .com and .net zones having longer TTL than ours (4 hours),
confused, but I am happy enough since verisignlabs says all green ticks

Post by Edwardo Garcia

Post by Edwardo Garcia
One question however it talk about longest TTL, does this mean also root
TLD zones (.com, .net) which from memory are 48 hours, so before we

delete

Post by Edwardo Garcia
old keys we need wait 48 hours, even though our zone TTL was 24 ?

When you are waiting after adding and signing with the new keys and before
swapping the DS records, it's only the longest TTL in your own zone that
matters. In my notes I call this the "child TTL" because the root and TLD
etc. don't matter.
https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
When you're waiting for the DS TTL it's only the TTL of that particular
record that matters. (It's in the parent zone so I called it the parent
TTL.) To be sure you are getting the right number you will need something
i.e. pick one of the nameservers of the parent zone and ask it for your
zone's DS record, so you don't get mislead by decremented cached TTLs.
Note the DS TTL is often not the same as the parent NS or glue TTL.

Post by Edwardo Garcia
Thank you, wow much much easy than I hoped for :-)

I'm happy it helped!
Tony.
--
Biscay: North, backing northwest later, 2 to 4, occasionally 5 later
in east. Slight. Showers. Good.

[Tony Finch]

Post by Edwardo Garcia
One thing I note, all check say everything is good, but when using dnsviz,
it says secure, shows the ecd... but also puts up warnings that I am using
alg 13 but digest 1 (sha1), which is not allowed,

I guess the "digest 1" is referring to your DS records. In my guide I
said, get the DS record for the new algorithm like this:

dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+YYYYY

The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash.

Old versions of BIND by default print both SHA1 and SHA2 DS records, and
it's relatively common for zones to have both kinds of DS record in their
delegation.

SHA1 DS records are now discouraged so it's best to replace them with
SHA2, or just delete them if you have both kinds of DS record.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
harness technological change to human advantage

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Edwardo Garcia]

OKi, I assume that was same as


dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -f - guiltyparty.net


Which is in our internals wiki for all these years (predate my employment
2012 )

So you mean to say when it print out

IN DS 45701 13 1 5422E9...
IN DS 45701 13 2 qwertyE9...

we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ?

and we only need run

dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net

and enter in just that one entry? 45701 13 2 qwertyE to the DS in domain
reg?




and we have been upload both all this years was wrong ?


way we been do it is instruction from wiki in full, more or less which I
guess
worked back in the day,

dnssec-keygen -r /dev/urandom -a rsasha1 -b 1024 -K keys/ -n ZONE foo.net
dnssec-keygen -r /dev/urandom -a rsasha1 -b 4096 -K keys/ -n ZONE -f KSK
foo.net

add into zone file

$INCLUDE keys/Kfoo.net.+005+6341.key
$INCLUDE keys/Kfoo.net.+005+9847.key

dnssec-signzone -a -e +9590400 -K keys/ -N INCREMENT foo.net
rndc stuff

then get DS and add both info registrar from dig (like above)

foo.net. IN DS 1234 5 1 .....
foo.net. IN DS 1234 5 2 .....

which stretch memory back to 2012 domain registrasr wanted both


hrmm, now I start to understand why not many use DNSSEC so confusing to
those who not
do this every day, or so many instructions around nobody knows what works

But we getting there :->

Post by Edwardo Garcia

Post by Edwardo Garcia
One thing I note, all check say everything is good, but when using

dnsviz,

Post by Edwardo Garcia
it says secure, shows the ecd... but also puts up warnings that I am

using

Post by Edwardo Garcia
alg 13 but digest 1 (sha1), which is not allowed,

I guess the "digest 1" is referring to your DS records. In my guide I
dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+YYYYY
The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash.
Old versions of BIND by default print both SHA1 and SHA2 DS records, and
it's relatively common for zones to have both kinds of DS record in their
delegation.
SHA1 DS records are now discouraged so it's best to replace them with
SHA2, or just delete them if you have both kinds of DS record.
Tony.
--
harness technological change to human advantage

[Tony Finch]

Post by Edwardo Garcia
So you mean to say when it print out
IN DS 45701 13 1 5422E9...
IN DS 45701 13 2 qwertyE9...
we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ?

Exactly, yes!

Post by Edwardo Garcia
and we only need run
and enter in just that one entry? 45701 13 2 qwertyE to the DS in domain
reg?

Correct!

Post by Edwardo Garcia
and we have been upload both all this years was wrong ?

Well, not wrong, but unnecessary. The tools generally encouraged everyone
to publish both SHA1 and SHA2 DS records even though just SHA2 has been
enough for more than 10 years and SHA1 has had known weaknesses for even
longer.

Post by Edwardo Garcia
hrmm, now I start to understand why not many use DNSSEC so confusing to
those who not do this every day, or so many instructions around nobody
knows what works
But we getting there :->

Yes, slowly...

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later.
Slight, occasionally moderate in Rockall and at first in Shannon.
Showers. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Edwardo Garcia]

Thank you! I have now corrected our ancient internal wiki so we now have
learned how it goes
Very much appreciate your patience and help, now I can start my weekend :->

Post by Tony Finch

Post by Edwardo Garcia
So you mean to say when it print out
IN DS 45701 13 1 5422E9...
IN DS 45701 13 2 qwertyE9...
we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ?

Exactly, yes!

Post by Edwardo Garcia
and we only need run

guiltyparty.net

Post by Edwardo Garcia
and enter in just that one entry? 45701 13 2 qwertyE to the DS in

domain

Post by Edwardo Garcia
reg?

Correct!

Post by Edwardo Garcia
and we have been upload both all this years was wrong ?

Well, not wrong, but unnecessary. The tools generally encouraged everyone
to publish both SHA1 and SHA2 DS records even though just SHA2 has been
enough for more than 10 years and SHA1 has had known weaknesses for even
longer.

Post by Edwardo Garcia
hrmm, now I start to understand why not many use DNSSEC so confusing to
those who not do this every day, or so many instructions around nobody
knows what works
But we getting there :->

Yes, slowly...
Tony.
--
Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later.
Slight, occasionally moderate in Rockall and at first in Shannon.
Showers. Good.