<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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...<br>
Quite easy to do from a script.</p>
<p>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. <br>
</p>
<div class="moz-cite-prefix">On 4/30/21 3:05 AM, Edwardo Garcia
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANso6eFZ+j6zxtEiA19W+Yi8cTJ4x2MpKQmWRfn74wphHtHLoA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Halo Tony,</div>
<div>Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the
size of rsa, strange how this better but we have made change
as</div>
<div>from your howto, thank you, now 24 hour and all seems ok
from what we tell, and the test site says all good.</div>
<div><br>
</div>
<div>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 ?</div>
<div><br>
</div>
<div>Thank you, wow much much easy than I hoped for :-)<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Apr 28, 2021 at 12:08
PM Tony Finch <<a href="mailto:dot@dotat.at"
moz-do-not-send="true">dot@dotat.at</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Edwardo
Garcia <<a href="mailto:wdgarc88@gmail.com" target="_blank"
moz-do-not-send="true">wdgarc88@gmail.com</a>> wrote:<br>
><br>
> Many year ago we set up DNSSEC, our key were generated
with sha1 as was<br>
> recommended way back all them years. We too are not
DNSSEC guru, so some<br>
> answer may be simple<br>
<br>
Well, you are going to do an algorithm rollover, which is one
of the more<br>
tricky things you can do with DNSSEC. So, plan to do some
testing, a trial<br>
run, with a spare zone that you can break without worrying.<br>
<br>
If you like to understand things by getting an idea of the
wider context<br>
then there are a couple of RFCs on the general subject of key
rollovers.<br>
The parts that are most relevant are the algorithm rollover
section in RFC<br>
6781 and the double-KSK section in RFC 7583.<br>
<br>
<a href="https://tools.ietf.org/html/rfc6781" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/rfc6781</a><br>
<a href="https://tools.ietf.org/html/rfc7583" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/rfc7583</a><br>
<br>
DNSSEC has got easier since those RFCs were written, so you
might as well<br>
just skip to the howto bits below :-) It turns out, I wrote
most of this<br>
reply over a year ago...<br>
<br>
> Also we use ZSK -b 1024 and KSK -b 4096<br>
> even modern google from apnic show example ZSK of only
1024? is this still<br>
> secure?<br>
<br>
The current recommendation for DNSSEC algorithms is:<br>
<br>
* you already know you want to choose something based on
sha256 - it's<br>
secure enough, so there's no need for bigger hashes<br>
<br>
* ecdsa-p256-sha256 (13) is the best choice, because it is
widely<br>
supported and produces small signatures<br>
<br>
* if you must use RSA, use 2048 bit keys for both zsk and
ksk. 1024 bits<br>
is not secure; 2048 has a roughly comparable security
level to sha256<br>
(112ish bits vs 128 bits); 4096 is big and slow and
probably not worth<br>
the cost<br>
<br>
* I would like to be able to deploy ed25519 (a better
elliptic curve<br>
than p256) but it is not yet supported well enough<br>
<br>
> Is best practise for doing this, replacing the keys
completely, more or<br>
> less like start fresh again?<br>
><br>
> We do use inline signing and automatic maintain.<br>
<br>
I did a wholesale algorithm rollover from RSASHA1 to p256
around the end<br>
of 2019 and I wrote an algorithm rollover guide for colleagues
in other<br>
parts of our university who run their own DNS. It's basically
three steps<br>
with lots of waiting in between:<br>
<br>
<a
href="https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html</a><br>
<br>
The "Semi-automated DS updates" section probably isn't
relevant to you,<br>
and the "Future" section has been made obsolete by
dnssec-policy. But the<br>
rest of it should guide you through the essentials.<br>
<br>
(Also, the RIPE NCC does now support CDS records.)<br>
<br>
And use these DNS checking services to verify that it is
working as<br>
expected:<br>
<br>
<a href="https://dnsviz.net/" rel="noreferrer" target="_blank"
moz-do-not-send="true">https://dnsviz.net/</a><br>
<br>
<a href="https://zonemaster.net/" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://zonemaster.net/</a><br>
<br>
Tony.<br>
-- <br>
f.anthony.n.finch <<a href="mailto:dot@dotat.at"
target="_blank" moz-do-not-send="true">dot@dotat.at</a>>
<a href="https://dotat.at/" rel="noreferrer" target="_blank"
moz-do-not-send="true">https://dotat.at/</a><br>
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,<br>
occasionally 3 later. Slight or moderate. Showers. Good.<br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<p>Mark James ELKINS - Posix Systems - (South) Africa<br>
<a class="moz-txt-link-abbreviated" href="mailto:mje@posix.co.za">mje@posix.co.za</a> Tel: <a href="tel:+27826010496">+27.826010496</a><br>
For fast, reliable, low cost Internet in ZA: <a
href="https://ftth.posix.co.za">https://ftth.posix.co.za</a><br>
<br>
<img moz-do-not-send="false"
src="cid:part12.26F1F78F.B9461F47@posix.co.za" alt="Posix
Systems" width="250" height="165"><img moz-do-not-send="false"
src="cid:part13.B512035A.24E31488@posix.co.za" alt="VCARD for
MJ Elkins" title="VCARD, Scan me please!" width="164"
height="164"><br>
</p>
</div>
</body>
</html>