DNSSEC de Doble Firma Fragmentado para Contrarrestar la Amenaza Cuántica

Información Básica

• ID del Artículo: 2411.07535
• Título: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• Autores: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• Instituciones: Deakin Cyber Research and Innovation Centre (Australia), Cyber Security Cooperative Research Centre (Australia), Quintessence Labs (Canberra), Tata Consultancy Services (Brisbane)
• Clasificación: cs.CR (Criptografía y Seguridad)
• Conferencia de Publicación: C'25, Noviembre 2025 (versión preliminar aceptada en ITNAC 2025)
• Enlace del Artículo: https://arxiv.org/abs/2411.07535

Resumen

DNSSEC, como extensión de seguridad de DNS, es crucial para traducir con precisión nombres de dominio en direcciones IP. Las firmas digitales proporcionan la base para esta traducción confiable; sin embargo, el desarrollo de computadoras cuánticas hace que las firmas digitales tradicionales sean vulnerables. NIST ha seleccionado recientemente firmas digitales postcuánticas que funcionan en computadoras clásicas y resisten ataques de computadoras cuánticas. Dado que estas firmas digitales postcuánticas aún se encuentran en etapas tempranas de desarrollo, existe riesgo en reemplazar las firmas digitales precuánticas en DNSSEC con candidatos postcuánticos antes de un análisis de seguridad exhaustivo. Esta investigación explora la viabilidad de adoptar "doble firma" en DNSSEC, combinando firmas digitales postcuánticas y clásicas. La doble firma proporcionará simultáneamente protección contra amenazas cuánticas y ataques no cuánticos desconocidos. Sin embargo, la inclusión de dos firmas entra en conflicto con el tamaño máximo permitido de respuestas DNSSEC (1232B, limitado por MTU de enlace físico). Para resolver este problema, este artículo adopta un método de fragmentación a nivel de aplicación para manejar respuestas DNSSEC con doble firma. La solución implementada en OQS-BIND demuestra que la doble firma y la fragmentación a nivel de aplicación tienen un impacto mínimo en la eficiencia del proceso de resolución, siendo adecuadas para su uso durante el período de transición antes de la implementación completa de computadoras cuánticas.

Antecedentes de Investigación y Motivación

1. Problema Central

DNSSEC asegura la autenticidad e integridad de respuestas DNS mediante firmas digitales, pero enfrenta un triple dilema en la era cuántica:

• Amenaza Cuántica: Las computadoras cuánticas relacionadas con criptografía (CRQC) pueden romper firmas tradicionales basadas en factorización de enteros y logaritmos discretos en tiempo polinomial mediante el algoritmo de Shor
• Inmadurez Postcuántica: Las firmas postcuánticas seleccionadas por NIST (FALCON, DILITHIUM, SPHINCS+) aún no han sido sometidas a análisis criptográfico suficiente y pueden contener defectos de diseño explotables por computadoras clásicas
• Riesgo del Período de Transición: Durante el "período de transición" desde ahora hasta la implementación completa de CRQC, depender únicamente de firmas tradicionales o postcuánticas presenta riesgos de seguridad

2. Importancia del Problema

• DNS es el núcleo de la infraestructura de Internet; cualquier vulnerabilidad de seguridad podría dirigir a los usuarios a servidores maliciosos
• Según las recomendaciones de ENISA, el simple reemplazo de algoritmos criptográficos durante el período de transición podría reducir la seguridad general
• Tanto los avances no divulgados en CRQC como las vulnerabilidades en algoritmos postcuánticos podrían invalidar DNSSEC

3. Limitaciones de Métodos Existentes

• Solo Firma Tradicional: No puede resistir ataques cuánticos futuros
• Solo Firma Postcuántica: Puede contener vectores de ataque clásicos desconocidos
• Esquemas de Fragmentación Existentes: ARRF utiliza RR no estándar que pueden causar problemas de compatibilidad con middleboxes; QBF no considera escenarios de doble firma
• Mecanismo de Retorno a TCP: Muchos servidores de nombres carecen de soporte TCP, y TCP no es tan ligero como UDP

4. Motivación de la Investigación

Adoptar una estrategia de "doble firma" (interfaz de mensaje separado):

• Mientras un firma sea segura, el sistema general permanece seguro
• Proporciona protección máxima de seguridad durante el período de transición
• Requiere resolver el problema de tamaño de mensaje excesivo causado por doble firma (>1232B desencadena fragmentación a nivel IP)

Contribuciones Principales

1. Implementación Completa de DNSSEC con Doble Firma: Desarrollo de una plataforma de prueba DNSSEC basada en Docker, utilizando software BIND9 de nivel comercial, capaz de manejar simultáneamente firmas y claves públicas precuánticas y postcuánticas en un único mensaje de respuesta UDP
2. Mecanismo de Fragmentación y Reagrupamiento a Nivel de Aplicación: Para el escenario de doble firma, se diseñó un esquema de fragmentación QBF mejorado:
   • Utiliza z-bits para identificar el tipo de algoritmo postcuántico
   • Utiliza desplazamiento de TTL para mantener el orden original de RR y evitar errores de puntero de compresión
   • Soporta todas las combinaciones de precuántico (ECDSA256, RSASHA256) y postcuántico (FALCON512, DILITHIUM2, SPHINCS+)
3. Modificación del Código Fuente de BIND9: Investigación profunda y modificación del componente resolvedor de BIND9 para permitir la verificación de dos firmas antes de marcar la respuesta como autenticada
4. Evaluación de Desempeño: Análisis empírico que demuestra que la doble firma tiene un impacto negligible en el tiempo de resolución DNSSEC (<9% de aumento), confirmando su aplicabilidad durante el período de transición

Explicación Detallada del Método

Definición de Tareas

Entrada: Consulta DNS (por ejemplo, registro A de test.example.com)
Salida: Dirección IP con verificación de doble firma
Restricciones:

• Tamaño de mensaje UDP ≤1232B (evitar fragmentación a nivel IP)
• Verificar simultáneamente firmas precuánticas y postcuánticas
• Mantener compatibilidad con infraestructura DNS existente

Diseño de Arquitectura de Doble Firma

1. Generación de Firma (Lado del Servidor de Nombres)

Adopta interfaz de mensaje separado (detached-message interface):

• Utiliza herramientas BIND9 para generar dos pares de claves (ZSK y KSK)
• Genera independientemente dos firmas para el mismo RRSet:
  • Firma precuántica X (ECDSA256 o RSASHA256)
  • Firma postcuántica Y (FALCON512/DILITHIUM2/SPHINCS+)
• Ambos RRSIG y DNSKEY se almacenan en el archivo de zona firmado

Ejemplo (Figura 13):
test0.socratescrc. 3600 IN RRSIG A 13 ... (firma ECDSA)
test0.socratescrc. 3600 IN RRSIG A 249 ... (firma postcuántica)

2. Estrategia de Verificación (Lado del Resolvedor)

Modificación de la lógica de verificación de BIND9:

• Verifica independientemente dos firmas
• Solo acepta la respuesta cuando ambas firmas pasan la verificación
• Proporciona protección dual contra ataques cuánticos y clásicos

Mecanismo de Fragmentación a Nivel de Aplicación

Desafío Central

Tamaño típico de respuesta con doble firma:

• Respuesta de registro A: ~2500B (combinación mínima ECDSA+FALCON512)
• Respuesta de DNSKEY: 4462B (RSASHA256+FALCON512)
• Muy por encima del umbral de 1232B

Estrategia de Fragmentación

Principios Básicos:

• RRSIG y DNSKEY precuánticos siempre se envían completos en el primer fragmento (tamaño más pequeño)
• Firmas/claves postcuánticas se fragmentan según sea necesario

Fragmentación de Respuesta de Registro A (Figura 8a):

1. El primer fragmento contiene: Header + Question + RRSIG/DNSKEY precuántico completo + parte de RRSIG postcuántico
2. El resolvedor deduce el número total de fragmentos del primer fragmento
3. Solicita en paralelo los fragmentos restantes (formato: ?n?domain_name)

Fragmentación de Respuesta de DNSKEY (Figura 8b):

• Algunas combinaciones (como RSASHA256) hacen que el primer fragmento no pueda contener ningún dato postcuántico
• Solución Innovadora:

Método de Identificación Z-bits:

Utiliza z-bits (3 bits) en RFC 1035:
- Codifica el tipo de algoritmo postcuántico (FALCON/DILITHIUM/SPHINCS+)
- El resolvedor deduce el tamaño total basándose en z-bits y RR precuántico ya recibido

Mecanismo de Desplazamiento de TTL:

Problema: Los punteros de compresión DNS dependen del orden de RR
Solución: Agrega desplazamiento de cantidad en el campo TTL de respuesta DNSKEY
Función: Restaura la posición original de RR durante el reagrupamiento, evitando errores de "bad compression pointer"

Flujo de Trabajo (Figura 10)

Daemon del Servidor de Nombres:

1. Intercepta respuesta DNS, verifica si el tamaño >1232B
2. Calcula el número de fragmentos requeridos
3. Establece z-bits (si es necesario) y desplazamiento de TTL
4. Establece bandera TC=1, envía primer fragmento
5. Almacena en caché los fragmentos restantes

Daemon del Resolvedor:

1. Recibe primer fragmento, verifica bandera TC
2. Analiza z-bits para determinar algoritmo postcuántico
3. Utiliza información de RR precuántico para deducir número total de fragmentos
4. Solicita en paralelo todos los fragmentos restantes (?2?test.socrates, ?3?test.socrates...)
5. Después de recopilar todos los fragmentos, reagrupa:
   • Utiliza desplazamiento de TTL para restaurar orden original de RR
   • Restablece bandera TC y otros valores de header
6. Pasa mensaje completo al verificador OQS-BIND

Puntos de Innovación Técnica

1. Compatibilidad con RR Estándar: A diferencia de ARRF con RR personalizado, utiliza formato DNS estándar para garantizar compatibilidad con middleboxes
2. Reutilización de Z-bits: Utiliza de manera innovadora bits de header subutilizados para resolver el problema de información insuficiente en respuestas DNSKEY
3. Esquema de Desplazamiento de TTL: Resuelve el conflicto entre el mecanismo de compresión DNS y el reagrupamiento de fragmentos, un problema único del escenario de doble firma
4. Solicitudes de Fragmentos en Paralelo: El resolvedor obtiene todos los fragmentos en paralelo, minimizando la latencia
5. Independencia de Algoritmo: Soporta cualquier combinación de algoritmos postcuánticos seleccionados por NIST y algoritmos precuánticos comunes

Configuración Experimental

Arquitectura de Plataforma de Prueba

Infraestructura:

• Instancia Amazon EC2 t2.xlarge (4 núcleos Intel Xeon 2.3GHz, 16GB RAM)
• Implementación containerizada con Docker (Docker 25.0.3)
• Componentes: Client, Resolver, Root Server, Authoritative Server

Stack de Software:

• OQS-BIND: Versión mejorada postcuántica basada en BIND9
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • Soporta FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S (nivel de seguridad de 128 bits)
• Daemon QBF Modificado: Implementa lógica de fragmentación/reagrupamiento de doble firma

Topología de Red (Figura 11):

Client → Resolver → Root Server → Authoritative Server
        ↑                            ↓
        └────────────────────────────┘

Configuración de Conjunto de Datos

• Nombres de Dominio de Prueba: 10 registros A (test0.socratescrc - test9.socratescrc)
• Combinaciones de Firma: 6 configuraciones de doble firma
  • Precuántico: ECDSA256, RSASHA256
  • Postcuántico: FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• Cadena de Confianza: Registros DS configurados correctamente, estableciendo cadena de confianza completa

Métricas de Evaluación

1. Tiempo de Resolución: Latencia de extremo a extremo desde el envío de consulta hasta la recepción de respuesta verificada
2. Cantidad de Fragmentos: Número de fragmentos requeridos para respuestas de registro A y DNSKEY
3. Sobrecarga de Desempeño: Porcentaje de aumento de tiempo de doble firma en relación con firma postcuántica única

Simulación de Condiciones de Red

Utiliza herramienta Linux tc para simular:

• Ancho de Banda: 50 Mbps
• Latencia: 10 ms
• Simula condiciones de Internet real

Metodología Experimental

1. Itera consultas de resolución para cada nombre de dominio
2. Registra tiempo de resolución para cada consulta
3. Calcula tiempo de resolución promedio de 10 consultas
4. Compara desempeño de doble firma con firma postcuántica única

Resultados Experimentales

Análisis de Cantidad de Fragmentos (Tabla 1)

Hallazgos Clave:

• Las combinaciones FALCON y DILITHIUM solo aumentan 1 fragmento
• Las combinaciones SPHINCS+ no aumentan fragmentos adicionales (optimización daemon elimina RR no críticos)
• El incremento de fragmentación es controlable, sin crecimiento exponencial

Tiempo Promedio de Resolución

Combinaciones FALCON (Tabla 2):

Combinaciones DILITHIUM (Tabla 3):

Combinaciones SPHINCS+ (Tabla 4):

Resultados Principales

1. Sobrecarga de Desempeño Aceptable:
   • Todas las combinaciones de doble firma tienen sobrecarga <9%
   • Significativamente menor que la sobrecarga de retorno a TCP (típicamente >50%)
2. Configuración Óptima:
   • FALCON+RSASHA: 204.5ms (doble firma más rápida)
   • DILITHIUM+RSASHA: 220.7ms
   • 14-22% más rápido que firma única SPHINCS+ (245.6ms)
3. RSA Superior a ECDSA:
   • En todas las combinaciones, la verificación RSA es más rápida
   • Ejemplo: DILITHIUM+RSA (220.7ms) vs DILITHIUM+ECDSA (225.6ms)
4. Tasa de Éxito de Verificación de Firma:
   • Todas las combinaciones verifican correctamente la doble firma
   • El resolvedor BIND9 modificado verifica exitosamente ambas firmas (Figura 14)

Hallazgos Experimentales

1. Ventaja de Algoritmos Basados en Retículos:
   • FALCON y DILITHIUM (basados en retículos) tienen tamaños de firma más pequeños
   • Tiempo de resolución significativamente mejor que SPHINCS+ (basado en hash)
2. Desventaja de SPHINCS+:
   • Tamaño de firma más grande (23 fragmentos para registro A)
   • NIST lo selecciona principalmente para evitar dependencia excesiva de algoritmos basados en retículos
   • No es la opción óptima en escenarios de doble firma
3. Confiabilidad de Reagrupamiento de Fragmentos:
   • El mecanismo de desplazamiento de TTL resuelve efectivamente el problema de puntero de compresión
   • El esquema z-bits transmite información de algoritmo con precisión
   • Sin pérdida de mensajes ni fallos de verificación
4. Ganancia de Seguridad:
   • La doble firma proporciona mecanismo "fail-safe"
   • Incluso si los algoritmos basados en retículos se rompen, RSA/ECDSA aún proporciona seguridad clásica
   • Incluso si se implementa computadora cuántica, algoritmos postcuánticos proporcionan protección

Trabajo Relacionado

Investigación DNSSEC Postcuántica

1. Müller et al. (2020):
   • Analiza requisitos de algoritmos candidatos de tercera ronda NIST para DNSSEC
   • No considera esquema de doble firma
2. Beernink (2022):
   • Propone método de entrega fuera de banda para claves grandes
   • No resuelve problema de tamaño de mensaje de doble firma
3. Goertzen & Stebila (2022) - ARRF:
   • Fragmentación a nivel de aplicación basada en solicitud
   • Introduce pseudo RR RRFRAGS (no estándar)
   • Riesgo de ataque de agotamiento de memoria
4. Rawat & Jhanwar (2024) - QBF:
   • Fragmentación basada en QName, utiliza RR estándar
   • Solicitudes de fragmentos en paralelo mejoran eficiencia
   • No soporta doble firma

Comparación de Contribuciones

Investigación de Combinadores Criptográficos

• ENISA (2022) recomienda uso de sistemas criptográficos híbridos durante período de transición
• Este artículo es el primero en implementar y evaluar doble firma en DNSSEC
• Adopta interfaz de mensaje separado (más fácil de integrar)

Conclusiones y Discusión

Conclusiones Principales

1. Viabilidad Técnica: La doble firma DNSSEC es completamente viable en infraestructura existente, sin requerir modificaciones a nivel de protocolo
2. Desempeño Aceptable: Sobrecarga de desempeño <9%, significativamente menor que retorno a TCP, no afectará notablemente la experiencia del usuario
3. Mejora de Seguridad: Proporciona protección dual contra ataques cuánticos y clásicos, adecuada para implementación durante período de transición
4. Mejores Prácticas: Se recomienda usar combinación de FALCON o DILITHIUM con RSA, equilibrando seguridad y desempeño

Limitaciones

1. Escala de Prueba Limitada:
   • Solo pruebas en instancia EC2 única
   • Sin simulación de escenarios de implementación a gran escala en Internet
   • Falta pruebas con tráfico de red real
2. Condiciones de Red Simplificadas:
   • Solo simula ancho de banda de 50Mbps y latencia de 10ms
   • No considera pérdida de paquetes, jitter y otras complejidades
   • Sin pruebas en diferentes entornos MTU
3. Sobrecarga de Daemon:
   • Lógica de fragmentación/reagrupamiento implementada en daemon independiente
   • Comunicación entre procesos puede introducir latencia adicional
   • No integrado directamente en núcleo BIND9
4. Compatibilidad con Middleboxes:
   • Sin pruebas exhaustivas de comportamiento de firewalls, NAT y otros middleboxes
   • La reutilización de z-bits puede causar problemas en algunas implementaciones
5. Impacto en Caché:
   • Sin análisis del impacto de fragmentación en eficiencia de caché DNS
   • Múltiples fragmentos pueden aumentar complejidad de caché
6. Análisis de Seguridad Insuficiente:
   • Sin prueba de seguridad formal
   • Sin evaluación de robustez contra ataques DoS
   • Sin análisis de riesgos de canal lateral en reagrupamiento de fragmentos

Direcciones Futuras

1. Integración Directa en BIND9:
   • Integrar lógica de fragmentación directamente en núcleo BIND9
   • Se espera reducción adicional en tiempo de resolución
2. Pruebas de Implementación a Gran Escala:
   • Pruebas piloto en infraestructura DNS real
   • Evaluación de compatibilidad con diversos tipos de middleboxes
3. Optimización de Selección de Algoritmo:
   • Selección dinámica de combinación de algoritmos basada en tipo de consulta
   • Exploración de estrategias de fragmentación adaptativa
4. Avance de Estandarización:
   • Envío de borrador a IETF
   • Promoción de doble firma como práctica estándar durante período de transición
5. Mejora de Seguridad:
   • Adición de mecanismos de protección DoS
   • Investigación de defensa contra ataques de temporización en reagrupamiento de fragmentos

Evaluación Profunda

Fortalezas

1. Identificación Precisa del Problema:
   • Identifica claramente el dilema de seguridad del período de transición
   • La estrategia de doble firma se alinea con recomendaciones de autoridades como ENISA
   • Resuelve obstáculos técnicos clave para implementación práctica
2. Solución Técnica Completa:
   • Z-bits y desplazamiento de TTL son soluciones innovadoras de ingeniería
   • Equilibra desempeño, compatibilidad y seguridad
   • Detalles de implementación suficientes (modificaciones de código fuente, diseño de daemon)
3. Diseño Experimental Razonable:
   • Uso de software BIND9 de nivel comercial aumenta aplicabilidad práctica
   • Pruebas de todas las combinaciones principales de algoritmos
   • Simulación de condiciones de red acorde con escenarios reales
4. Resultados Convincentes:
   • Datos de desempeño claros (<9% sobrecarga)
   • Verifica corrección de todas las combinaciones
   • Proporciona recomendaciones claras de implementación (FALCON/DILITHIUM+RSA)
5. Alto Valor de Ingeniería:
   • Basado en OQS-BIND de código abierto, buena reproducibilidad
   • Implementación containerizada con Docker facilita promoción
   • Proporciona ruta viable para implementación práctica

Insuficiencias

1. Falta de Análisis Teórico:
   • Carece de prueba de seguridad formal del esquema de doble firma
   • No discute fortaleza criptográfica de combinación de firmas
   • Falta argumentación rigurosa de la suposición "una firma falla, otra permanece segura"
2. Alcance de Evaluación Limitado:
   • Solo 10 nombres de dominio de prueba, tamaño de muestra pequeño
   • Sin pruebas de escenarios de alta carga y alta concurrencia
   • Falta pruebas de estabilidad a largo plazo
3. Comparación Insuficiente con Métodos Existentes:
   • Sin comparación directa de desempeño con retorno a TCP
   • Sin evaluación de ventajas relativas a esquemas alternativos como EDNS(0) padding
   • Falta análisis comparativo de seguridad con implementación pura FALCON, DILITHIUM
4. Consideraciones de Practicidad Incompletas:
   • No discute complejidad de gestión de claves (dos conjuntos de claves)
   • Sin análisis de costo de actualización de infraestructura DNSSEC existente
   • Falta pruebas de compatibilidad hacia atrás (resolvedor antiguo)
5. Escritura Mejorable:
   • Algunos detalles técnicos demasiado verbosos (como Sección 2 de fundamentos DNS)
   • Figuras podrían ser más claras (Figuras 8, 10 complejas)
   • Falta pseudocódigo de algoritmo

Impacto

Contribución al Campo:

• Pionera: Primer trabajo en implementar y evaluar doble firma DNSSEC
• Oportuna: Responde oportunamente al proceso de estandarización PQC de NIST
• Práctica: Proporciona solución de transición implementable inmediatamente

Valor Práctico:

• Corto Plazo: Proporciona a operadores DNS esquema de mejora de seguridad para período de transición
• Mediano Plazo: Proporciona datos empíricos para estandarización IETF
• Largo Plazo: Proporciona referencia para transición cuántica segura de otros protocolos

Reproducibilidad:

• ✓ Basado en software de código abierto (OQS-BIND)
• ✓ Descripción detallada de implementación
• ✗ Código no publicado públicamente (sin enlace GitHub mencionado en artículo)
• ✓ Implementación containerizada con Docker reduce dificultad de reproducción

Impacto Potencial:

• Puede promover adopción de estrategia de doble firma por comunidad DNS
• Proporciona referencia de estrategia de fragmentación para otros protocolos a nivel de aplicación (como TLS, SSH)
• Ayuda a acelerar implementación práctica de criptografía postcuántica

Escenarios de Aplicación

Escenarios de Aplicación Ideales:

1. DNS de Infraestructura Crítica: Dominios de finanzas, gobierno y otras organizaciones con requisitos de seguridad extremadamente altos
2. Implementación de Período de Transición: 2025-2030 cuando amenaza CRQC se acerca pero algoritmos postcuánticos aún requieren validación
3. Objetivos de Alto Valor: Organizaciones vulnerables a ataques de adversarios a nivel estatal

Escenarios No Aplicables:

1. Entornos con Recursos Limitados: Dispositivos IoT, sistemas embebidos (sobrecarga computacional y de almacenamiento)
2. Requisitos de Baja Latencia: Sistemas de comunicación en tiempo real (aumento de 8% en latencia puede ser inaceptable)
3. Era Postcuántica: Una vez que algoritmos postcuánticos maduran completamente, necesidad de doble firma disminuye

Recomendaciones de Implementación:

• Priorizar implementación en servidores raíz y servidores TLD
• Usar combinación FALCON+RSA o DILITHIUM+RSA
• Coexistir con infraestructura DNSSEC existente (actualización progresiva)
• Establecer mecanismos de monitoreo para rastrear desempeño y seguridad

Referencias Clave

1. Shor (1994): "Algorithms for quantum computation" - Base teórica de amenaza cuántica
2. Estandarización PQC NIST: Especificaciones de algoritmos FALCON, DILITHIUM, SPHINCS+
3. RFC 4034: Especificación de registros de recursos DNSSEC
4. RFC 6891: Mecanismo de extensión EDNS(0)
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" - Base de política para estrategia de doble firma
6. Goertzen & Stebila (2022): Esquema de fragmentación ARRF
7. Rawat & Jhanwar (2024): Esquema de fragmentación QBF (base directa de este artículo)

Resumen

Este artículo aborda el desafío único del período de transición de seguridad cuántica de DNSSEC, proponiendo una solución de doble firma viable desde el punto de vista de ingeniería. A través del diseño ingenioso de fragmentación a nivel de aplicación (identificación z-bits, desplazamiento de TTL), resuelve exitosamente el problema de exceso de tamaño de mensaje causado por doble firma. Los experimentos demuestran que la sobrecarga de desempeño es controlable (<9%), adecuada para implementación práctica. Este es un caso típico de "investigación impulsada por ingeniería", donde aunque la innovación teórica es limitada, el valor de ingeniería es significativo, proporcionando a la comunidad DNS una solución de transición oportuna y práctica. El valor principal del artículo radica en la primera implementación y validación, no en avances teóricos, lo cual es igualmente importante en el campo de la criptografía aplicada. Se recomienda que los autores en trabajos posteriores complementen con análisis de seguridad formal y pruebas de implementación a gran escala, y promuevan la publicación de código para aumentar el impacto.