En esta nota discutiremos estas nuevas propuestas, así como los registros ZONEMD. Compartiremos los planes de despliegue, cómo estos pueden afectar a ciertos usuarios y todo lo que los operadores de DNS deben tener en cuenta de antemano para garantizar que las interrupciones sean mínimas o inexistentes.
La zona raíz del DNS es el punto de partida para la mayoría de las búsquedas de nombres de dominio en Internet. La zona raíz contiene delegaciones de casi 1500 dominios de nivel superior, entre ellos .com, .net, .org y muchos otros. Desde su creación en 1984, diferentes organizaciones conocidas colectivamente como operadores de servidores raíz han brindado el servicio para lo que ahora denominamos el sistema de servidores raíz (Root Server System, RSS). En este sistema, un sinfín de servidores responden diariamente a alrededor de 80 mil millones de consultas a la zona raíz.
Aunque el RSS sigue desempeñando esta función con un alto grado de confiabilidad, existen propuestas recientes para usar la zona raíz de una manera ligeramente diferente. Si bien estas propuestas generan algunas eficiencias para los operadores de DNS, también introducen nuevos desafíos.
NUEVAS PROPUESTAS
En 2020, el Grupo de Trabajo en Ingeniería de Internet (IETF) publicó la RFC 8806, Running a Root Server Local to a Resolver. En la misma línea, en 2021 la Oficina del Director de Tecnología de la Corporación de Internet para la Asignación de Nombres y Números (ICANN OCTO, por sus siglas en inglés) publicó el documento OCTO-027, Hyperlocal Root Zone Technical Analysis. Ambas propuestas comparten la idea de que los servidores de nombres recursivos pueden recibir y cargar localmente toda la zona raíz y responder directamente a las consultas a la zona raíz.
Pero en un escenario en el que toda la zona raíz está disponible para millones de servidores de nombres recursivos, surge una nueva pregunta: ¿cómo pueden los consumidores de datos de una zona verificar que el contenido de la zona no se haya modificado antes de llegar a sus sistemas?
Se podría pensar que las extensiones de seguridad para el DNS (DNSSEC) serían de ayuda. Sin embargo, si bien la zona raíz sí está firmada con DNSSEC, la mayoría de los registros de la zona se consideran no autoritativos (es decir, todos los registros NS y glue) y, por lo tanto, no tienen firmas. ¿Qué pasa con algo como una firma Pretty Good Privacy (PGP) en el archivo de la zona raíz? Esto presenta su propio desafío: en PGP, una firma separada se separa fácilmente de los datos. Por ejemplo, no hay manera de incluir una firma PGP sobre una transferencia de zona DNS, y no existe una manera fácil de saber qué versión de la zona va con la firma.
ZONEMD
La RFC 8976 proporciona una solución a este problema. Impulsado por Verisign y titulado Message Digest for DNS Zones (habitualmente conocido como ZONEMD), este protocolo exige que se embeba un hash criptográfico de los datos de la zona en la propia zona. Luego los consumidores de los datos de la zona pueden firmar y verificar este registro ZONEMD. A continuación se describe cómo funciona.
Cada vez que se actualiza una zona, el editor de la zona calcula el registro ZONEMD previamente al ordenar y canonicalizar todos los registros en la zona y proporcionarlos como entrada para una función hash de mensaje. En este caso, las acciones de ordenar y canonicalizar son las mismas que para DNSSEC. De hecho, el cálculo de ZONEMD se puede realizar al mismo tiempo que se firma la zona. El cálculo del hash necesariamente excluye al propio registro ZONEMD, por lo que el paso final consiste en actualizar el registro ZONEMD y sus firmas.
Un destinatario de una transferencia de zona que incluye un registro ZONEMD repite el mismo cálculo y compara el valor del hash calculado con el hash publicado. Si la zona está firmada, el destinatario también puede validar si el hash publicado es correcto. Así, los destinatarios pueden verificar la autenticidad de los datos de la zona antes de usarlos.
Hoy existe —o pronto existirá— una serie de productos de software de DNS de código abierto que soportan la verificación de zona mediante ZONEMD. Estos incluyen Unbound (versión 1.13.2), NSD (versión 4.3.4), Knot DNS (versión 3.1.0), PowerDNS Recursor (versión 4.7.0) y BIND (versión 9.19).
¿QUIÉN SE VE AFECTADO?
Verisign, la ICANN y los operadores de servidores raíz están tomando medidas para garantizar que la adición del registro ZONEMD no afecte de ninguna manera la capacidad del sistema de servidores raíz para recibir actualizaciones de las zonas y para responder consultas. Es por ello que la mayoría de los usuarios de Internet no se ven afectados por este cambio.
Tampoco es probable que resulte afectado alguien que utilice la RFC 8806 o una técnica similar para cargar datos de la zona raíz en su resolvedor local. Los productos de software que implementan estas características deberían poder procesar completamente una zona que incluya el nuevo tipo de registro, en especial por las razones que se describen a continuación. Una vez que se ha agregado el registro, los usuarios pueden aprovechar la verificación de datos transferidos mediante ZONEMD para garantizar que los datos de la zona raíz sean auténticos.
Los usuarios con mayor probabilidad de verse afectados son los que reciben datos de la zona raíz de los servidores de internic.net (o de alguna otra fuente) y usan software personalizado para analizar el archivo de zona. Según cómo se diseñe este software personalizado, existe la posibilidad de que trate el nuevo registro ZONEMD como inesperado y genere una condición de error. Esta publicación tiene como objetivos clave generar conciencia sobre este cambio, dar tiempo suficiente para abordar los problemas de software y minimizar la probabilidad de interrupciones para estos usuarios.
PLAN DE DESPLIEGUE
En 2020, Verisign le pidió al Comité de Revisión de la Evolución de la Zona Raíz (RZERC) que considerara una propuesta para agregar protecciones de datos a la zona raíz mediante ZONEMD. En 2021, el RZERC publicó sus recomendaciones en la resolución RZERC003. Una de estas recomendaciones fue que Verisign y la ICANN desarrollaran un plan de despliegue y concientizaran a la comunidad sobre los detalles del plan. El resto de este artículo resume este plan.
DESPLIEGUE POR FASES
Uno de los atributos de un registro ZONEMD es la elección del algoritmo hash utilizado para crear el hash. La RFC 8976 define dos algoritmos hash estándar —SHA-384 y SHA-512— y una gama de algoritmos de “uso privado”.
Inicialmente, el registro ZONEMD de la zona raíz tendrá un algoritmo hash de uso privado. Esto nos permite primero incluir el registro en la zona sin que nadie se preocupe por la validez de los valores hash. Dado que el algoritmo hash es del rango de uso privado, un consumidor de los datos de la zona no sabrá cómo calcular el valor hash. Cuando se agregó DNSSEC a la zona raíz en 2010 se utilizó una técnica similar conocida como “Zona raíz deliberadamente no validable”.
Después de un período de más de dos meses, el registro ZONEMD pasará a un algoritmo hash estándar.
ALGORITMO HASH
Por razones de compatibilidad, para la implementación inicial se seleccionó el algoritmo SHA-384.
Los desarrolladores de BIND implementaron el protocolo ZONEMD sobre la base de un borrador de Internet anterior, antes de que este se publicara como RFC. Lamentablemente, la implementación inicial de BIND solo acepta registros ZONEMD con una longitud hash de 48 bytes (es decir, la longitud de SHA-384). Dado que hoy en día se utilizan mucho las versiones de BIND que tienen este comportamiento, el uso del algoritmo hash SHA-512 probablemente generaría problemas para muchas instalaciones de BIND, quizás incluso para algunos operadores de servidores raíz.
FORMATO DE PRESENTACIÓN
La distribución de la zona entre el mantenedor de la zona raíz y los operadores de servidores raíz se realiza principalmente a través del protocolo de transferencia de zona DNS. En este protocolo, los datos de zona se transmiten en “formato de red”.
La zona raíz también se almacena y se sirve como un archivo en los servidores web y FTP de internic.net. Aquí, los datos de la zona están en “formato de presentación”. En estos archivos, el registro ZONEMD aparecerá utilizando su formato de presentación nativo. Por ejemplo:
. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )
Puede que actualmente algunos usuarios de los datos de zona recibidos de los servidores web y FTP estén utilizando software que no reconoce el formato de presentación de ZONEMD. Estos usuarios podrían experimentar algunos inconvenientes cuando el registro ZONEMD aparezca por primera vez. De hecho, consideramos la posibilidad de usar un formato de registro genérico; sin embargo, en consulta con la ICANN, creemos que el formato nativo es una mejor solución a largo plazo.
CRONOGRAMA
Actualmente, nuestro objetivo es el despliegue inicial de ZONEMD en la zona raíz para el 13 de septiembre de 2023. Como ya se indicó, el registro ZONEMD se publicará primero con un número de algoritmo hash de uso privado. Nuestro objetivo es comenzar a usar el algoritmo hash SHA-384 el 6 de diciembre de 2023. A partir de ese momento, el registro ZONEMD de la zona raíz será verificable.
CONCLUSIÓN
Desplegar ZONEMD en la zona raíz ayuda a aumentar la seguridad, la estabilidad y la resiliencia del DNS. Pronto, los servidores de nombres recursivos que opten por servir datos de la zona raíz de forma local tendrán mayores garantías en cuanto a la validez de la zona.
Si te interesa seguir el avance del despliegue de ZONEMD, busca nuestros anuncios en la lista de correo DNS Operations.
