Reflexionando sobre “Calling time on DNSSEC?” de Geoff Huston, es innegable que la economía está en contra de la adopción de las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC).
Aunque la DNSSEC se ha desplegado en la mayoría de los dominios de nivel superior (TLD) del espacio de nombres del Sistema de Nombres de Dominio (DNS) público mundial (Figura 1), y a pesar de los incentivos económicos proporcionados por los registros y la disponibilidad de bases de código y conjuntos de herramientas gratuitos y de código abierto, los beneficios económicos no han sido favorables. El problema con DNSSEC es algo más que económico; quizás el diseño de DNSSEC va en contra de su adopción.
La arquitectura de DNSSEC se estableció inicialmente en los años 90. Internet estaba todavía en su era de “mejor esfuerzo”; los hosts y protocolos conectados eran inseguros, y había pocas prácticas recomendadas para contrarrestar y recuperarse de la actividad maliciosa. Aunque el espacio de nombres DNS había empezado a tomar forma, en aquel momento no existía un alojamiento o aprovisionamiento comercial significativo. En cuanto a las herramientas, sólo había una plataforma de código abierto dominante.
DNSSEC comenzó con tres objetivos técnicos para proteger los datos a medida que fluían por el sistema DNS:
- Autenticación de los datos: los datos son lo que está configurado.
- La integridad de los datos: los datos están completos.
- Autenticación de las respuestas negativas: garantizar la “no respuesta”.
Se utilizaron algunos principios rectores y observaciones de este primer entorno para debatir cómo se cumplirían los objetivos y cómo las decisiones tomadas influyeron en el diseño de DNSSEC.
No podemos confiar en los anfitriones con claves privadas
Se eligieron las firmas digitales para proporcionar autenticación e integridad para DNSSEC. En el momento de este diseño, la seguridad del host era inaceptablemente pobre. La clave privada (o las claves) utilizadas para generar las firmas debían mantenerse en ordenadores fuera de la red, confiando en medios extraíbles para salvar la brecha de aire.
Por tanto, el diseño del protocolo requería que todas las respuestas fueran precalculadas, sin que se generaran datos de respuesta basados en una consulta. Esto es aceptable para los resultados positivos en los que hay una coincidencia directa, pero hay otros tres tipos de respuestas en el DNS: respuestas negativas, respuestas sintetizadas y respuestas redirigidas.
Una respuesta negativa precalculada y universal parecía un enfoque probable, pero está sujeta a un ataque de repetición. DNSSEC optó por un enfoque que requería ordenar los datos en una zona y luego revelar rangos de datos para que el consultor pudiera determinar que lo que quería no existía. Las desventajas de esto son respuestas más amplias y revelar más información de la necesaria. Esto por sí solo es lo suficientemente significativo como para haber impulsado un enfoque actualizado de las respuestas negativas que incluya respuestas más amplias y confusas.
Las respuestas precalculadas para consultas sintetizadas, comúnmente llamadas comodines en DNS, y las respuestas redirigidas que implican registros de recursos CNAME y DNAME requieren DNSSEC para revelar el trabajo realizado por el respondedor al consultante. Esto se suma a los problemas relacionados con las respuestas negativas precalculadas.
Una alternativa a esto es la firma sobre la marcha, confiando a servidores en línea claves privadas para generar firmas. Aunque no es una solución automática, se hace en la práctica y ha demostrado ser factible, pero requiere que todos los servidores de nombres estén bajo el control de un operador. En la práctica, integrar un enfoque de firma sobre la marcha en un protocolo que presupone respuestas precalculadas es complicado. Esta complejidad sugiere que está justificado algún rediseño del protocolo.
El trabajo de un administrador de zona
El RFC 1034 se refiere a un “administrador de zona”, lo que lleva a pensar en una entidad singular responsable de una zona. Junto con un mantra general de “mi red, mis normas” al operar una red, este enfoque creó la idea de que la zona era una entidad autónoma, singularmente responsable de su seguridad. A lo largo de todo el protocolo hay menciones a la “política local” cada vez que había que tomar decisiones operativas.
Esto dificultó el papel de la relación de delegación padre-hijo en el diseño de DNSSEC. Cuando el DNS simplificó la estructura de delegación, el DNSSEC siguió su ejemplo. El resultado es un diseño que no ha funcionado en la práctica.
Se preveía que la adopción de DNSSEC se produciría de abajo arriba, a medida que los administradores de zona reconocieran sus ventajas y actuaran en consecuencia. Se asumió que DNSSEC crecería hacia arriba en el espacio de nombres, con la raíz posiblemente firmada en último lugar, una vez que la tecnología se hubiera probado a fondo y hubiera alcanzado una alta fiabilidad. Un elemento importante fue el uso de Anclajes de Confianza (AT), sobre todo en los casos en que una zona estaba firmada pero su zona matriz no.
Hoy en día, la DNSSEC está experimentando exactamente lo contrario. Al principio, existían algunos TLD pioneros antes de que se firmara la zona raíz en 2010. Ahora, algunos estiman que más del 90% de las zonas raíz, TLD y otras zonas de infraestructura están firmadas, mientras que las estimaciones para firmar hacia abajo en el árbol rondan por debajo del 10%. Actualmente, la única AT ampliamente gestionada es la de la zona radicular.
Un vínculo más fuerte entre las zonas padre e hija podría resolver potencialmente muchos de los problemas a los que se enfrentan hoy en día el aprovisionamiento o registro de DNS. Esto incluye facilitar la actualización dinámica de las credenciales de seguridad (claves) y la transferencia fluida del control de un administrador de zona u operador de backend a otro, especialmente teniendo en cuenta cómo y por qué DNSSEC ha crecido de arriba abajo. Por esta razón, los esfuerzos del Grupo de Trabajo de Ingeniería de Internet (IETF) para desarrollar un registro llamado DELEG son importantes para DNSSEC.
El contacto con los padres debe reducirse al mínimo”.
Relacionado con el apartado anterior, este mantra se centra en el intercambio de información de claves criptográficas entre las zonas hija y padre. Esto ha llevado a la creación de la función criptográfica Punto de Entrada Seguro (SEP), que a su vez condujo a la noción de una función Clave de Firma (KSK) y una función Clave de Firma de Zona (ZSK).
La creación de las dos funciones clave se basó en observaciones realizadas en talleres; cuando DNSSEC requería que el padre cambiara los registros en función de los cambios de clave del hijo, el padre podía tardar en responder. Para permitir una mayor flexibilidad en la gestión de los cambios de clave, se introdujo una ZSK que podía cambiarse sin requerir actualizaciones del padre.
Sin embargo, tener dos llaves duplica instantáneamente la carga de trabajo del gestor de llaves. La introducción de estas dos funciones también ha hecho que explicar DNSSEC (mediante diapositivas o presentaciones) sea mucho más difícil. A pesar del algoritmo de validación establecido, hay pocas normas estrictas que regulen el uso de estas dos funciones, lo que puede complicar su aplicación. Aunque la mayoría de las operaciones se adhieren a prácticas específicas con estos roles, la definición del protocolo y el software que soporta DNSSEC no pueden asumir prácticas comunes de forma universal.
Es posible ejecutar DNSSEC con una sola clave en una zona, es decir, una Clave de Firma Común (CSK). Esta clave puede cambiarse con la frecuencia necesaria, lo que simplifica la gestión, especialmente con los avances en el aprovisionamiento automatizado. Este enfoque ha evolucionado después de que la DNSSEC se enfrentara inicialmente a retos con prácticas rígidas.
Todas las zonas son iguales
Cuando se estaba desarrollando el DNSSEC, .com era grande y estaba casi lleno, si no completamente, de delegaciones. Era tan grande que el primer firmante de DNSSEC tuvo que hacer algunos trucos para firmar la zona. Por muy tentador que pareciera tratar a .com y potencialmente a otras zonas grandes como “especiales” en el diseño de DNSSEC, el pensamiento predominante era que el objetivo debía ser un diseño de protocolo más sencillo, racionalizado, en el que todas las zonas fueran iguales.
Un aspecto crítico que inicialmente se pasó por alto en el diseño de DNSSEC fue la posición única de la zona raíz. A diferencia de otras zonas que tienen zonas padre para establecer la seguridad de las claves públicas, la zona raíz es independiente y no puede depender de una zona padre para su validación. Para ello es necesario utilizar TAs – claves preconfiguradas y de confianza disponibles en todos los validadores de DNSSEC. La gestión de las AT, especialmente para la zona radicular, sigue siendo un reto. En retrospectiva, garantizar una amplia distribución y gestión de las AT para la zona radicular debería haber sido una consideración primordial desde el principio.
Desarrollador vs Operador
Tras el desarrollo inicial, se celebraron una serie de pequeños talleres DNSSEC, invitando a participar a quienes dirigían servidores DNS. Durante cinco años, estos eventos se celebraron en muchas partes del mundo para atraer a expertos que ayudaran a dar forma al diseño de DNSSEC. Los resultados de esto informaron la definición actual de DNSSEC.
El plan inicial para el desarrollo de DNSSEC era sólido. Sin embargo, los participantes no representaban necesariamente el panorama operativo actual. Aunque tenían experiencia en la gestión de servicios DNS, muchos también eran expertos en la configuración de protocolos y poseían conocimientos de programación, lo que les permitía sortear complejidades sin depender únicamente de las herramientas disponibles. Esta dinámica ha llevado a un exceso de confianza en el diseño del protocolo, sugiriendo a menudo que la principal necesidad es mejorar la formación o el utillaje.
Es necesario reconocer las bajas estadísticas de adopción como una crítica al desarrollo de DNSSEC, en lugar de asumir que se trata de un caso de mayor promoción o educación. Aunque hay operadores que desconocen la DNSSEC o que la consideran demasiado desalentadora, hay muchos operadores que la conocen bien y tienen motivos para no implantarla. Esas razones deben recogerse, abordarse y utilizarse en cualquier camino que se siga.
Suposiciones sobre criptografía
Muchos de los escenarios previstos para utilizar la criptografía en DNSSEC se inspiraron en historias o leyendas de cómo se había empleado la criptografía en contextos militares o gubernamentales. En aquella época, el conocimiento público sobre criptografía era limitado, por lo que estas historias y leyendas sirvieron como fuentes cruciales de requisitos e inspiración para el desarrollo de DNSSEC.
A juzgar por esos primeros escenarios de casos de uso, los operadores actuales tienden a adoptar un enfoque minimalista, utilizando el menor número de claves que sea necesario, ciñéndose normalmente a un algoritmo cada vez. Este enfoque ayuda a minimizar la complejidad operativa y reduce el tamaño de las respuestas DNS, lo que es fundamental para optimizar el rendimiento de la red. Los operadores también dan prioridad a la configuración de los parámetros criptográficos por defecto que proporcionan los paquetes de software, equilibrando la necesidad de seguridad con las consideraciones prácticas de implementación. Estudiar cómo utiliza la criptografía el DNSSEC debería conducir a enfoques compatibles con el uso comercial de Internet, que garanticen tanto la seguridad como la eficacia.
¿Por qué revisar el pasado?
Puede que estas observaciones no alteren el camino hacia un DNS seguro; puede que sólo sirvan como lecciones históricas. También podrían orientar el diseño de futuros sustitutos de DNSSEC o inspirar enfoques para mejorar la seguridad dentro de los sistemas existentes. Sin embargo, ponen de manifiesto posibles escollos de diseño y podrían servir de base a los esfuerzos por hacer que la DNSSEC sea más fácil de usar para los operadores.
Adaptado del post original que apareció por primera vez en el Blog de APNIC.
Edward Lewis es conocido por su trabajo en DNS y DNSSEC, dominios de Internet, registros de números e investigación en seguridad de redes. Es miembro del equipo original que diseñó y creó el prototipo de DNSSEC. Participa activamente en foros del sector y es un ponente habitual.