¿Por qué no podemos omitir DNSSEC?

Question

¿Por qué no podemos omitir DNSSEC?

#1 de Habbie (3 votos)

11

DNSSEC es un conjunto de extensiones de seguridad para mejorar la seguridad de DNS. (por ejemplo, evitar el envenenamiento de caché)

Sin embargo, me preguntaba ¿cómo sabe la resolución que el próximo NS usará DNSSEC?

Por ejemplo: alguien quiere resolver www.example.com. . Supongamos que el NS example.com. autorizado tiene DNSSEC habilitado y configurado correctamente.

El resolutor primero se pondrá en contacto con los servidores raíz . , luego con los servidores de TLD com. y finalmente con el autoritativo example.com. . Sin embargo, como el solucionador envía una consulta de DNS a ese último NS, no sabe si DNSSEC está habilitado.

Esto significa que un atacante puede falsificar un paquete DNS y hacer su trabajo de envenenamiento ...

Sé que estoy equivocado, la resolución debe ser consciente de que el próximo NS utiliza DNSSEC. ¡Pero no entiendo cómo !?

dnssec

pregunta Posterrr57 27.04.2015 - 17:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas dnssec

¿Cómo protejo mi cuenta de Gmail cuando accedo a ella desde un teléfono inteligente Android? ¿La ejecución aleatoria de "docker pull" significa esencialmente que le estoy dando acceso a alguien a la raíz?

score 3 · Answer 1

El autoritativo de .com indicará en su respuesta firmada que example.com también está firmado (se omite alguna salida)

$ dig +norec +dnssec a www.example.com @c.gtld-servers.net

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.
example.com.        86400   IN  DS  31589 8 1 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE
example.com.        86400   IN  DS  31589 8 2 CDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03 E576343C
example.com.        86400   IN  RRSIG   DS 8 2 86400 20150503041532 20150426030532 33878 com. P7R78q8UpfNTw+oVYJkL4BizSB4b8sglabdODISZEFSP3/z7CPAXOa4C 31rbNeLvD/O0I6pmYbg33HILGyj+yxAlZj7x3LNuLzaun86S201XcLkH /Xe/tLA+kEBgwZ6RV+1Vvqc51kAcQuN0U+6v5nZFaCJ1ZhvZ/S8w7FMf dfY=

Note el RRSIG - esto está firmado con la clave para .com, y le permite al cliente validar los registros de DS. Los registros de DS (Delegación de la delegación), a su vez, son un hash del DNSKEY para example.com. Cuando un cliente recibe esta respuesta, sabe que example.com DEBE estar firmado y DEBE estar firmado con una clave que coincida con uno de los registros de DS. Si el cliente obtiene datos que no son DNSSEC de los servidores de nombres de example.com, sabe que algo está mal y tratará los datos como BOGUS.