<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I generally agree with you - comments in line<br>
    </p>
    <div class="moz-cite-prefix">On 8/3/22 5:56 PM, Peter wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:YuqauegTGeSjJhjD@gate.intra.daemon.contact">
      <pre class="moz-quote-pre" wrap="">I see a two-fold issue with DNSSEC:

1. The wide-spread tutorials seem to explain a key rollover as an
   exceptional activity, a *change* that is infrequently done. And
   changes, specifically the infrequent ones, bring along the
   possibility of failure, mostly due to human error.</pre>
    </blockquote>
    <p>Domains with Cloudflare seem to get Signed once -(KSK/DS - etc)
      and that's it!</p>
    <p><br>
    </p>
    <p>
    </p>
    <blockquote type="cite"
      cite="mid:YuqauegTGeSjJhjD@gate.intra.daemon.contact">
      <pre class="moz-quote-pre" wrap="">   I don't see reason why this is so. DNSSEC can be fully
   automated (mine is), and then it can be done frequently, and the
   human factor is out of the loop. It is then no longer a change,
   but a regular operation that happens every <week/month/quarter>
   without anybody even need noticing it.
   (Let'sEncrypt did the same for certificates, and that also works
   well.)</pre>
    </blockquote>
    <p>Both my DNSSEC and Let's Encrypt are totally automated as well. I
      usually run two KSK's overlapping by 6 months - so plenty of
      "rollover" time. Other domains, there is only a second KSK for a
      week or so.</p>
    <p><br>
    </p>
    <p>
    </p>
    <blockquote type="cite"
      cite="mid:YuqauegTGeSjJhjD@gate.intra.daemon.contact">
      <pre class="moz-quote-pre" wrap="">
2. TCP seems still to be considered a second-class-citizen in the
   DNS world. (If I got the details right, TCP is only "optional",</pre>
    </blockquote>
    <p>Agh! No. NOT OPTIONAL. One might see it as a fall-back for when
      UDP fails (Truncated) but it is completely necessary!</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:YuqauegTGeSjJhjD@gate.intra.daemon.contact">
      <pre class="moz-quote-pre" wrap="">
   and must only be tried as a second choice after receiving TC.)
   So people may be induced to try and squeeze replies into whatever
   512 or 1280 or 1500 bytes. Which means, they probably cannot use
   more than one key, and so take possible redundancy out of the game.

   I do not currently know about how or where this issue could be
   tackled appropriately; I for my part have decided to happily ignore
   it, and am using *four* KSK, thereby supporting RFC 5011 and RFC
   7344, all with one simple script - and anyway now I have the longest;
   here you can see it in action: <a class="moz-txt-link-freetext" href="https://dnsviz.net/d/daemon.contact/dnssec/">https://dnsviz.net/d/daemon.contact/dnssec/</a>
   Let's see where this leads into problems; for now it appears not to.

-- PMc</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Fair enough. And Elliptical Curve (Algo 13 ???) - so much
      shorter.</p>
    <p>ps - Algorithm rollovers can be fun!!!<br>
    </p>
    <blockquote type="cite"
      cite="mid:YuqauegTGeSjJhjD@gate.intra.daemon.contact">
    </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>
        <br>
        <br>
        <br>
      </p>
    </div>
  </body>
</html>