<div dir="auto">Hola Tomás,</div><div dir="auto"><br></div><div dir="auto">Hay varias razones para no “bajar” una firma y “subir” la otra en forma instantánea… una de ellas son los tiempos de propagación y los TTL. Imagínate que vos tenés cacheada la anterior y yo la quito antes de que consultes nuevamente? En ese caso te quedarías sin resolución.</div><div dir="auto">Por la forma en que funciona el protocolo, basta con tener una firma válida para que funcione. De esa forma evitas problemas con la resolución.</div><div dir="auto">Empezar a preocuparse yo creo que nadie, pero si verificar que están al día con las actualizaciones del software que utilicen y cuando la nueva firma esté publicada verificar al menos una vez que mi resolver la utiliza correctamente.</div><div dir="auto">También  puede ser que algunos tengan configurado “manualmente” la clave y en forma estática, En ese caso la recomendación sería pasarlo a automático y porsupuesto si no, hacer el cambio manual una vez que la nueva esté publicada. </div><div dir="auto">Como es una “transición” hay tiempo más que suficiente para que todos puedan hacerlo tranquilamente creo yo.</div><div dir="auto"><br></div><div dir="auto">Saludos,</div><div dir="auto">Nico</div><div dir="auto"><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El El mié, feb 4, 2026 a la(s) 08:02, Tomas Lynch <<a href="mailto:tomas.lynch@gmail.com">tomas.lynch@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Carlos,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">¿Por qué se hace una transición y no una migración completa? Me debo imaginar que es porque hay gente que no se va a enterar que se cambia el protocolo que genera la clave hasta el último día. Si esto es así, ¿quiénes deberían comenzar a preocuparse en este momento?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Otra pregunta. Como todo en la vida hay fanáticos, ¿los hay de RSA vs. ECDSA?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Saludos,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Tomás</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 3, 2026 at 4:57 PM Carlos Martinez-Cagnazzo <<a href="mailto:carlos@lacnic.net" target="_blank">carlos@lacnic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><u></u>

  

    
  
  <div>
    <p>Hola a todos!</p>
    <p>En ICANN están considerando realizar un "algorithm rollover" de
      la KSK de la raiz, es decir cambiar el _algoritmo_ que se utiliza
      para generar el par de claves que se utiliza para firmar la zona
      raiz del DNS.</p>
    <p>Les envio la consulta publica ya que puede ser de interes de
      ustedes operadores. </p>
    <p>s2</p>
    <p>/Carlos</p>
    <div><br>
      <br>
      -------- Forwarded Message --------
      <table cellpadding="0" cellspacing="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" align="RIGHT" nowrap>Subject:
            </th>
            <td>Proposal for Root Zone KSK Algorithm Rollover</td>
          </tr>
          <tr>
            <th valign="BASELINE" align="RIGHT" nowrap>Date: </th>
            <td>Tue, 3 Feb 2026 21:06:14 +0000</td>
          </tr>
          <tr>
            <th valign="BASELINE" align="RIGHT" nowrap>From: </th>
            <td>Andres Pavez via root-dnssec-announce
              <a href="mailto:root-dnssec-announce@icann.org" target="_blank"><root-dnssec-announce@icann.org></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" align="RIGHT" nowrap>Reply-To:
            </th>
            <td>Andres Pavez <a href="mailto:andres.pavez@iana.org" target="_blank"><andres.pavez@iana.org></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" align="RIGHT" nowrap>To: </th>
            <td><a href="mailto:root-dnssec-announce@icann.org" target="_blank">root-dnssec-announce@icann.org</a>
              <a href="mailto:root-dnssec-announce@icann.org" target="_blank"><root-dnssec-announce@icann.org></a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      We would like to announce that the Proposal for Root Zone KSK
      Algorithm Rollover has been released for public comment and is
      available for review on the ICANN website:<br>
      <br>
<a href="https://www.icann.org/en/public-comment/proceeding/proposed-root-ksk-algorithm-rollover-03-02-2026" target="_blank">https://www.icann.org/en/public-comment/proceeding/proposed-root-ksk-algorithm-rollover-03-02-2026</a>
      <br>
      The proposal describes a multi-year plan to generate a new ECDSA
      Root KSK in 2027 and retire the RSA Root KSK by 2030. It includes:<br>
      <br>
      * Transitioning the DNS root KSK from RSA/SHA-256 to ECDSA
      P-256/SHA-256<br>
      * Following a traditional double-signing approach, with both
      algorithms running in parallel during the transition<br>
      * Adjusting the RSA ZSK size from 2048 to 1536 bits prior to the
      transition, to reduce the possible need to truncation and
      retransmission over TCP.<br>
      <br>
      Community feedback on the methodology, timeline, operational
      readiness, and any additional risks is encouraged. <br>
      The public comment period is open through 6 April 2026.<br>
      <br>
      Thanks,<br>
      <pre style="font-family:monospace">-- 
Andres Pavez Cryptographic Key Manager 


</pre>
    </div>
  </div>

_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div>