Tengo curiosidad por saber cuáles son los efectos reales del servidor raíz L.publicando DURZ hoyserá. En la lista de correo de nanog,Alguien dijoEs importante evaluar los efectos sistémicos de los servidores de nombres raíz que publican zonas firmadas, incluso cuando no se utiliza DNSSEC. Mientras tanto, la propia información publicada por RIPE sobre sus cambios en el servidor raíz K dice que hayno hay problema si sus resolutores no usan DNSSEC. ¿Alguien puede aclarar esto? DNSSEC parece ser una red confusa y enredada.
Si no habilito DNSSEC en mis resolutores, ¿tengo algo de qué preocuparme con los próximos cambios en los servidores raíz?
Respuesta1
TúpuedeVerás algo, pero hasta cierto punto eso depende del software DNS que estés ejecutando.
En particular, BIND establece el DObit "DNSSEC OK" (también conocido como ) en consultas ascendentes incluso cuando no solicita específicamente registros DNSSEC ni realiza la validación de DNSSEC.
En esas circunstancias, los servidores raíz pueden enviar registros DNSSEC adicionales quepuedecausar problemas en el improbable caso de que tenga equipos de red rotos y/o cortafuegos mal configurados en el camino.
Esos problemas se relacionan principalmente con el tamaño del paquete. A algunos kits no les gustan los paquetes DNS UDP que superan los 512 bytes de longitud, ya sea por firmware defectuoso o configuraciones erróneas recomendadas por el proveedor. Mira miRFC 5625para más detalles. Sin embargo, tenga en cuenta que la mayoría de los problemas relacionados con DNSSEC que informo en ese RFC se relacionan con equipos de clase de consumo, y solo en configuraciones inusuales.
Tenga en cuenta que si su kit tiene problemas con paquetes UDP grandes, entonces la alternativa es utilizar TCP. Sin embargo, algunas personas de seguridad (equivocadas) configuran sus firewalls para deshabilitar el DNS saliente sobre TCP, lo que rompe el respaldo. VeresteBorrador del IETF para obtener más información sobre DNS sobre TCP.
Por cierto, para probar la configuración de su red en busca de posibles anomalías del DNS, le recomiendo encarecidamente elexcelente Netalyzrsitio web de ICSI en UC Berkeley.
Sin embargo, para ser claros, la mayoría de los expertos en DNS estánnoSe esperan problemas importantes debido a la introducción de DNSSEC. Ya se han firmado varios TLD (incluidos .org y .se) e Internet no colapsó por eso.
El DURZ es un intento deliberado de incorporar gradualmente las respuestas más amplias que inevitablemente produce DNSSEC para que esos raros sitios que tienen problemas de red puedan resolverlos antes de que toda la zona raíz pase a DNSSEC en el verano.
Respuesta2
Una explicación de lo que puede salir mal, en pseudocódigo, para aquellos que prefieren los lenguajes de programación imperativos :-)
-- Pseudocódigo (sintaxis más o menos parecida a la de Ada) para mostrar lo que sucede con
-- un solucionador de DNS cuando la raíz está firmada y las respuestas se vuelven
-- más grande.
-- Información de contexto:
-- https://www.dns-oarc.net/oarc/services/replysizetest
-- RFC 5625
-- Informe SSAC #35 http://www.icann.org/committees/security/sac035.pdf
-- Stéphane Bortzmeyer
-- Variables utilizadas:
-- EDNS0: booleano, indica si el solucionador envía solicitudes EDNS0
-- EDNS0_Size: entero positivo, el tamaño del búfer anunciado por EDNS0
-- DO_DNSSEC: booleano, el indicador DO que indica la compatibilidad con DNSSEC por parte del solucionador
-- Min_Response_Size: entero, el mínimo (después de eliminar
-- tamaño RR) innecesario de la respuesta DNS enviada por la autoridad
-- servidor
-- Clean_path_for_fragments: booleano, indica que los fragmentos UDP
-- puede viajar desde el servidor de nombres autorizado hasta el resolutor
-- Clean_Path_For_EDNS0: booleano, indica que las respuestas EDNS0
-- (que puede tener más de 512 bytes) puede viajar desde el
-- servidor de nombres autorizado para el solucionador
-- Can_TCP: booleano, indica que el solucionador puede preguntar a través de TCP
-- (lo que implica un parche TCP limpio y un servidor de nombres autorizado
-- que aceptan TCP)
-- El código se puede ejecutar varias veces para una solicitud, por ejemplo
-- instancia porque un solucionador intenta primero con UDP y luego lo vuelve a intentar
-- con TCP.
si es UDP, entonces: protocolo de transporte más común para DNS
si EDNS0 entonces
si EDNS0_Size > MTU entonces
-- BIND predeterminado, EDNS0_size = 4096 bytes
si DO_DNSSEC entonces
-- BIND predeterminado, incluso si no está configurado para validación
si Min_Response_Size > MTU entonces -- No es el caso hoy con la raíz
si Clean_Path_for_fragments entonces
DE ACUERDO;
demás
-- Después de un tiempo BIND cambiará a no-EDNS0, comenzará de nuevo
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
elsif Min_Response_Size > 512 entonces
-- No se producirá fragmentación
si Clean_Path_For_EDNS0 entonces
DE ACUERDO; -- Ese es el caso normal y típico de un BIND
-- resolver hoy, con la raíz firmada
demás
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
else -- No ocurrirá hoy, las respuestas de la raíz ya son > 512
DE ACUERDO;
terminara si;
demás
-- Sin DNSSEC, las respuestas serán más breves, pero algunas
-- las respuestas de la raíz ya son > 512
si Min_Response_Size > MTU entonces
-- Improbable, sin DNSSEC
si Clean_Path_for_fragments entonces
DE ACUERDO;
demás
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
elsif Min_Response_Size > 512 entonces
si Clean_Path_For_EDNS0 entonces
DE ACUERDO;
demás
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
else -- El caso más común hoy en día, el típico sin firmar
-- la respuesta es 100-200 bytes
DE ACUERDO;
terminara si;
terminara si;
elsif EDNS0_Size >= 512 entonces - Pero inferior a la MTU
si DO_DNSSEC entonces
si Min_Response_Size > EDNS0_Size entonces
-- Esto supone que llegan paquetes DNS con el bit TC configurado
-- con seguridad, no siempre es cierto
Reintentar("Truncado");
elsif Min_Response_Size >= 512 entonces
si Clean_Path_for_EDNS0 entonces
DE ACUERDO;
demás
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
else -- No ocurrirá frecuentemente hoy, algunas respuestas de la raíz ya son > 512
DE ACUERDO; -- No siempre, algunos middleboxes pueden bloquear EDNS0
-- respuestas, incluso con el tamaño 512 entonces
si Clean_Path_For_EDNS0 entonces
DE ACUERDO;
demás
Reintentar("Las respuestas no recibidas pueden deberse a EDNS0");
terminara si;
demás
DE ACUERDO;
terminara si;
terminara si;
else -- EDNS0 con tamaño 512 entonces
Reintentar("Truncado");
demás
DE ACUERDO;
terminara si;
terminara si;
más - TCP
si Can_TCP entonces
DE ACUERDO; -- Pero mayor latencia y mayor carga en servidores de nombres autorizados
demás
Error("Error al volver a TCP"); -- Fracaso completo y total
terminara si;
terminara si;
Respuesta3
Otra solución para probar su configuración, que encuentro mucho más simple que Netalyzr, esPrueba de tamaño de respuesta de OARC.