<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Danilo,</p>
    <p>I think the way you have describe should work. But can I ask what
      source this recipe has? I have seen recently similar signing in
      one of our test. I guess this should be from public recipe. Would
      you share its origin, please?<br>
    </p>
    <p>I would recommend having DNS server do the job of maintaining
      signatures. If you do it this way manually, you have to resign
      your zone each time your signatures expire. Do you have set some
      kind of reminder to remind you?</p>
    <p>I would try DNSSEC guide [1] with bind 9.16 or more recent. It
      provides a policy inside named. It depends on what version do you
      have. Even 9.11 can maintain signatures [2] and resign them, but
      the process is more complicated. You would have to just regenerate
      keys, otherwise it will maintain your signatures. But yes, it
      won't be able to edit zone file by hand this way.</p>
    <p>Read dnssec-settime manual page and way to set times, when each
      key should be activated or deactivated. It should be more safe if
      done the right way. You can use dnssec-signzone -S to use smart
      signing and then omit step 2. Just provide correct directory to
      keys. But I admit it might be simpler to do it manually if you
      would upgrade just single zone, which has no high impact in case
      of error.</p>
    <p>Btw. it seems really clumsy to read 1000 characters from proper
      entropy source and then use just 16 hexcoded chars from it.
      /dev/urandom might be better source and 16 bytes should be enough.</p>
    <p>Regards,<br>
      Petr<br>
    </p>
    <p>1. <a class="moz-txt-link-freetext" href="https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html">https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html</a></p>
    <p>2.
<a class="moz-txt-link-freetext" href="https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones">https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones</a><br>
    </p>
    <div class="moz-cite-prefix">On 4/5/22 09:07, Danilo Godec via
      bind-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1899c1d9-9dd5-8607-c68f-044a23bc39f6@agenda.si">
      <p>Hello,</p>
      <p><br>
      </p>
      <p>I implemented DNSSEC for my personal domain a good while ago
        with an older Bind and back then, I used RSASHA1-NSEC3-SHA1
        algorithm, which by now is not recommended... So I'm going to
        change the algorithm, probably to ECDSAP256SHA256, which should
        also be NSEC3 capable.</p>
      <p>Since my domain is small and rarely changes, I'm not using any
        fancy updating features - I manage it manually, by editing the
        non-signed version of the zone file and then signing it to
        create a signed version.</p>
      <p><br>
      </p>
      <p>Here I'd like to verify that I understand the steps required to
        change DNSEC key / algorithm without disruption:</p>
      <p><br>
      </p>
      <p>1. create new keys for my zone</p>
      <ul>
        <li>dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain</li>
        <li>dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain</li>
      </ul>
      <p><br>
      </p>
      <p>2. include new keys in my zone while keeping old keys too:<br>
      </p>
      <p>    $INCLUDE Kmydomain.+008+14884.key         <- old key<br>
            $INCLUDE Kmydomain.+008+27618.key         <- old key<br>
            $INCLUDE Kmydomain.+013+10503.key         <- new key<br>
            $INCLUDE Kmydomain.+013+39532.key         <- new key</p>
      <p><br>
      </p>
      <p>3. sign the zone file</p>
      <p>    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random
        | sha1sum | cut -b 1-16) -e +3024000 -o mydomain -t
        mydomain.hosts</p>
      <p><br>
      </p>
      <p>4. ask the registrar to add new DS record to TLD (I have to do
        this by mail, there is no 'self-service' UI)</p>
      <p>5. wait at least one TTL (making sure to use the longest TTL in
        my zone)</p>
      <p>6. ask the registrar to remove old DS record(s) (I don't quite
        remember why, but I had two)</p>
      <p>7. wait another TTL period</p>
      <p>8. remove old keys from zone</p>
      <p>9. re-sign the zone<br>
      </p>
      <p><br>
      </p>
      <p>Will that be OK?</p>
      <p><br>
      </p>
      <p>   Best regards,</p>
      <p>     Danilo</p>
      <p><br>
      </p>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
  </body>
</html>