☰

¿DNSSEC es tan común que no funciona o la resolución de systemd es demasiado entusiasta?

tag-icon • tag-icon dns systemd
¿DNSSEC es tan común que no funciona o la resolución de systemd es demasiado entusiasta?

Recientemente cambié mi solucionador de DNS para systemd-resolvedcomenzar a aprovechar DNSSEC donde esté disponible. Mi configuración es:

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

(incluido el valor predeterminado comentado de DNSSEC=allow-downgrade)

Todo parece funcionar muy bien para la mayoría de los sitios, tanto habilitados para DNSSEC como no. Sin embargo, de vez en cuando llego a un sitio que no resuelve:

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

Intenté verificar esto a través deAnalizador DNSSEC (para savannah.gnu.org). Sin embargo, me cuesta entender el resultado. Realmente no veo en qué se diferencia de cualquier otro dominio que no permita DNSSEC.

Mi pregunta es: ¿DNSSEC suele estar roto o systemd-resolve está haciendo algo mal aquí?

Respuesta1

Probablemente sean ambas cosas. En general, según informes anteriores, me inclinaría por lo último (systemd-resolved es demasiado estricto en algunos casos). Sin embargo,según DNSViz, la configuración de los dominios tampoco pasa todas las comprobaciones.

Tampoco estoy 100% seguro acerca de ciertos mecanismos DNSSEC, pero esta es mi opinión:

savannah.gnu.org

Es un desastre enorme. Systemd-resolved detecta correctamente un problema con el dominio... pero lo rechaza incorrectamente basándose en información en la que no debería confiar.

  1. La gnu.org.zona tiene firmas, pero su delegación org.no incluye ninguna clave para validarlas, por lo que se supone que el solucionador ni siquiera debe mirar esas firmas; ya no son parte de la cadena de confianza. Sin embargo, systemd-resolve los analiza de todos modos.

  2. El savannah.gnu.org.nombre existe en dos lugares y no concuerdan entre sí. Este problema pasaría desapercibido sin DNSSEC, pero siempre fallaría la validación con DNSSEC. Sin embargo, debido al problema número 1, falla la validación a pesar de que se supone que systemd-resolved lo ignora silenciosamente.

Más detalles sobre el n.° 2:

Los mismos servidores de nombres alojan tanto la zona principal firmada gnu.org.como la zona secundaria no firmada savannah.gnu.org.. El problema es que el primero carece de una delegación real de la Sociedad Nacional en el segundo; en cambio, simplemente tiene registros simples de no delegación con este nombre.

Las cosas solo funcionan porque ambas zonas están alojadas en los mismos servidores de nombres, por lo que al principio, cuando consulta registros A o AAAA en "savannah.gnu.org", la respuesta se entrega automáticamente desde la zona secundaria sin firmar.

Está claro que es el comienzo de una zona aparte porque tiene registro SOA. Pero el validador DNSSEC necesita saber si esta zona debe estar firmada o no, por lo que intenta consultar los registros DS (o la falta de ellos) y esta vez la respuesta siempre proviene de la zona principal.

Una subzona sin firmar está bien si la zona principal no tiene ningún registro DS, lo que se demuestra al devolver un registro NSEC firmado en lugar de la respuesta; La "prueba de inexistencia" de la NSEC indicatodotipos de registros que están presentes o ausentes para este nombre.

Entonces, la zona principal "gnu.org" afirma correctamente que los registros DS para "savannah.gnu.org" no existen... pero también afirma queLos registros NS tampoco existen,es decir, el nombre no se delega en absoluto a una zona secundaria.(Aparentemente hay un registro SSHFP...)

Dado que el validador tiene la respuesta original sin firmar que indica que proviene de una subzona y una prueba firmada que indica que hayNodelegación a una subzona, la validación debe fallar.

...Pero, como se mencionó en el punto 1, ninguna de esas comprobaciones debe realizarse en primer lugar, porque la org.zona padre-padretambiéndemuestra que su delegación gnu.org.no está firmada, lo que significa que cualquier registro NSEC proveniente de gnu.org es discutible. Systemd-resolved no debería mirarlos, debería tratar toda la zona gnu.org como si no tuviera ningún DNSSEC.

información relacionada