<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 03-Aug-22 09:27, Bob Harold wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+nkc8CaXpPFDGqz3JY-v-LoamXYW4M4=MYymH80_YNq=caEHw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">I think the best way to soften the effect, and
          make DNSSEC much less brittle, without losing any of the
          security, is to reduce the TTL of the DS record in the parent
          zone (usually TLD's) drastically - from 2 days to like 30
          minutes.  That allows quick recovery from a failure.  I
          realize that will cause an increase in DNS traffic, and I
          don't know how much of an increase, but the 24-48 hour TTL of
          the DS record is the real down-side of DNSSEC, and why it is
          taking me so long to try to develop a bullet-proof process
          before signing my zones.<br clear="all">
          <div>
            <div dir="ltr" class="gmail_signature"
              data-smartmail="gmail_signature">
              <div dir="ltr">
                <div>
                  <div dir="ltr">
                    <div><br>
                      -- <br>
                      Bob Harold</div>
                    <div>University of Michigan</div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <p>Yes, in planning for DNSSEC changes it's a good idea to include
      reducing TTLs, verifying the change, then increasing the TTLs.</p>
    <p>That means keeping track of important (I'd say non-automated)
      events, and reducing TTL a few days in advance.</p>
    <p>If you do that, you get the benefit of long TTLs most of the
      time.  KSK rollover - probably the most common cause of errors -
      is not a frequent event.<br>
    </p>
    <p>Then again, with proper planning, you don't make nearly as many
      mistakes.</p>
    <p>Also, while I haven't gotten around to migrating, for a new setup
      I'd look at the dnssec-policy in 9.16+, which appears to do most
      of the automation for you.  All of it if you have a registrar who
      supports CDS/CDNSKEY, in which the parent zone pulls the new DS
      into itself.  <a
        href="https://kb.isc.org/docs/dnssec-key-and-signing-policy"
        class="moz-txt-link-freetext">https://kb.isc.org/docs/dnssec-key-and-signing-policy</a><br>
    </p>
    <p>Some issues have been reported on this mailing list, but from a
      distance it seems to be a great improvement and doing well.</p>
    <p>At this point, creating a new process doesn't seem like a great
      use of time...at least unless you've identified issues with the
      tools that you can't get fixed... The ISC folks working on
      dnssec-policy seem to have been responsive.</p>
    <p>FWIW<br>
    </p>
    <pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 
</pre>
  </body>
</html>