<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <div class="moz-cite-prefix">On 27/02/2024 13:22, Michael Sinatra

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:62742549-6a2e-4f87-8974-2a3fbbfb9197@brokendns.net">On

      2/26/24 13:41, Al Whaley wrote:

      <br>

      <blockquote type="cite" style="color: #007cff;">Originally (under

        the above command) RR records for DNSSEC were maintained by

        bind, but the ZSK and KSK keys were maintained by me.  This

        command is being discarded.  I understand that bind "sort of"

        supports this feature in 9.18 by allowing the DNSSEC policy

        statement to declare unlimited lifetime, but after careful

        reading of the documentation and reading a number of complaints,

        it turns out that bind may under various circumstances decide

        that it is appropriate not to use existing keys and decide that

        it knows best, and then it makes new ones.  This potential

        instability of course would be disastrous, and completely

        unnecessary.

        <br>

      </blockquote>

      <br>

      I have never experienced this, in either BIND 9.16 or BIND 9.18

      (including the latter with KASP set to not rotate any keys).  Can

      you elaborate as to where in the documentation and/or what

      complaints you have seen where correctly configured KASPs in

      9.18.24+ decide to roll keys?  I'd certainly like to know if

      that's the case, for reasons described below.

    </blockquote>

    <p>The only example that I can recall (from this list) where this

      type of thing happened was where someone specified a different

      algorithm when transitioning to dnssec-policy. The advice for this

      type of situation is to transition to dnssec-policy with the same

      algorithm first, and make sure everything in your state files is

      "omnipresent", and only then update the dnssec-policy to use a

      different algorithm.</p>

    <p>My (somewhat uneducated) advice would also be to avoid

      implementing dnssec-policy if you were in the middle of a key

      roll-over. Not because I think it would necessarily create a

      problem, but more to reduce risk and make it easier to verify that

      nothing untoward has happened.<br>

    </p>

    <p>In other words, if you aren't in the middle of a roll-over, and

      your current keys don't have any expiration set, then you can

      reconfigure your zone to use a dnssec-policy that specifies the

      same algorithm as what you previously had, and BIND should be

      happy to carry on using the existing keys -- indefinitely if

      you've specified an unlimited lifetime. The only difference you

      should notice is that after implementing dnssec-policy there are

      additional *.state files in your keys directory.</p>

    <p>The only other thing I'd add is that if (after transitioning

      to dnssec-policy) you do initiate a manual roll-over, keep an eye

      on your state files to verify that the new key becomes

      "omnipresent". This can take much longer than you might expect!

      For ZSK roll-overs don't be surprised if it takes 9-10 days. Also

      FYI for KSK (and CSK) roll-overs, you may need to run rndc

      commands to tell BIND when DS records are added/removed -- but

      that is possibly what you already do with auto-dnssec?<br>

    </p>

    <p>Of course in life there are no absolute guarantees, so you should

      back up your configuration and make a plan to mitigate the impacts

      in the event that everything turns pear-shaped?<br>

    </p>

    Nick.

  </body>

</html>