☰

¿Es útil DNSSEC?

tag-icon • tag-icon domain-name-system dns-zone dnssec
¿Es útil DNSSEC?

DNSSEC valida y autentica los datos de la zona con el propósito de garantizar que, cualesquiera que sean los resultados del DNS, sean genuinos.

  1. Incluso si un solucionador de DNS valida que un servidor de nombres autorizado ha enviado los datos correctos sin manipulación, ¿cómo evitamos que el solucionador de DNS envíe una respuesta DNS manipulada al cliente DNS?

  2. Si el solucionador de DNS no admite DNSSEC, ¿aún puede enviar consultas de DNS a un servidor de nombres autorizado que tenga DNSSEC habilitado para su zona?

Gracias

Respuesta1

¿Es útil DNSSEC?

Esto no se puede responder (para cualquier palabra que pongas en lugar de "DNSSEC" en esa oración) hasta que comiences a describir lo que quieres defender.

Cuando tenga la lista de riesgos/vulnerabilidades/amenazas contra las que desea defenderse, podrá averiguar qué soluciones existen y determinar para cada solución hasta qué punto es útil o no.

DNSSECes útil contra algunos tipos de problemas de DNS, pero no en todos ellos. Introduce nuevos problemas (mantenimiento continuo de firmas y claves para uno), pero también nuevas características (almacenamiento en caché agresivo de todo lo que se encuentra debajo de NXDOMAINsi DNSSEC lo valida adecuadamente).

Incluso si un solucionador de DNS valida que un servidor de nombres autorizado ha enviado los datos correctos sin manipulación, ¿cómo evitamos que el solucionador de DNS envíe una respuesta DNS manipulada al cliente DNS?

Esto no es nada diferente a hoy: si usa cualquier solucionador de DNS público ( ,, 8.8.8.8por nombrar algunos), por supuesto, corre COMPLETAMENTE el riesgo de que le envíe datos basura. Esa es una compensación. DoH/DoT no resuelve nada aquí porque protegerá solo la transmisión de contenido entre usted y este solucionador, no el contenido en sí. Qué contenido está "protegido" por DNSSEC siempre que el nombre de dominio para el que está realizando consultas esté protegido por DNSSEC (que es una parte que olvida en sus preguntas y que, de hecho, dificulta el DNSSEC: el propietario del nombre de dominio debe habilitarlo1.1.1.19.9.9.9YLos solucionadores de DNS tienen que utilizar las nuevas firmas y realizar la validación; si una parte de esta ecuación de 2 variables no está ahí, DNSSEC no es útil porque simplemente no puede funcionar)

Entonces, la pregunta gira más en torno a: qué servidor de nombres recursivo usar y dónde debería ejecutarse. Por supuesto, para obtener el máximo control, desea que el solucionador se ejecute en SUS máquinas. Todavía puede usar recursos externos y solucionadores de DNS allí, pero la validación final de DNSSEC debe realizarse en su servidor de nombres, no en otros. Por supuesto, esto supone más trabajo que simplemente depender de cualquier otro recurso que haga todo el trabajo de DNSSEC "gratis" por usted.

Si el solucionador de DNS no es compatible con DNSSEC, ¿aún puede enviar consultas de DNS a un servidor de nombres autorizado que tenga configurada DNSSEC para su zona?

Sí. Un solucionador que desee tener datos DNSSEC debe cambiar el indicador "DO" en su solicitud.

De digla documentación:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

Que puedes ver de esa manera:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

O del §3.2.1 de RFC 4035:

3.2.1. El bit DO

El lado de resolución de un servidor de nombres recursivo consciente de la seguridad DEBE establecer el bit DO al enviar solicitudes, independientemente del estado del bit DO en la solicitud de inicio recibida por el lado del servidor de nombres. Si el bit DO en una consulta de inicio no está establecido, el lado del servidor de nombres DEBE eliminar cualquier RR DNSSEC de autenticación de la respuesta, pero NO DEBE eliminar ningún tipo de RR DNSSEC que la consulta de inicio haya solicitado explícitamente.

Si el cliente DNS (resolución recursiva) hace esto Y si el servidor de nombres autorizado al que se consulta tiene DNSSEC habilitado (por lo tanto, tipos de registros // RRSIGen las zonas), entonces el solucionador obtendrá esos registros y luego podrá realizar la validación de DNSSEC.NSECNSEC3

Cuando usted (un stub/cliente DNS que no es un solucionador) consulta un solucionador recursivo, tiene la opción de usar el CDindicador, definido como tal:

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(cuidado con la posible doble negación).

Si el cliente no usa CD, entonces la validación de DNSSEC NO está deshabilitada, por lo tanto, está habilitada y el servidor de eliminación entregará la respuesta final (si DNSSEC está habilitado para el registro Y la validación fue exitosa) o responderá NXDOMAINsi DNSSEC validación fallida. El indicador ADse establecerá para indicar que todos los registros fueron validados como seguros, si es el caso (si la consulta proviene de un servidor de nombres recursivo, ese indicador no puede existir en uno autorizado, ya que necesita la cadena DNSSEC completa desde la raíz de IANA). para validar cualquier registro dado)

Respuesta2

  1. Lo ideal sería validar localmente en el cliente (no es tan común hoy en día, pero está lejos de ser inaudito), o confiar en una ruta de red segura que pueda cerrar la brecha entre el cliente y un solucionador de validación confiable.
    Esta ruta de red segura podría significar algo como DNS sobre TLS, DNS sobre HTTPS, DNSCrypt o, hasta cierto punto, una red local (nivel de confianza más débil, pero aún útil para un subconjunto de escenarios de ataque).
  2. Sí

información relacionada