En mi opinión, debería ser posible falsificar la respuesta de DNS para que no incluya partes de DS / RRSIG / ... para cualquier solicitud, por lo que se omite la validación de DNSSEC del dominio resuelto.
¿Es el sistema DNSSEC inmune a este tipo de ataque?
¿Unbound con archivos de anclaje DLV y ROOT almacenados localmente hace alguna diferencia?
Sí, DNSSEC es inmune a este tipo de ataque. Comenzando en un ancla (generalmente la raíz, a veces DLV), cada delegación es explícitamente segura (presencia de DS establecida en la delegación):
powerdns.com. 172800 IN NS powerdnssec1.ds9a.nl.
powerdns.com. 172800 IN NS powerdnssec2.ds9a.nl.
powerdns.com. 86400 IN DS 44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com. 86400 IN DS 44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com. 86400 IN DS 44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279
o explícitamente inseguro (NSEC [3] el mapa de bits demuestra la ausencia de DS en la delegación):
gov-1l.us. 7200 IN NS HNS1.BEYONDHOSTING.NET.
gov-1l.us. 7200 IN NS HNS2.BEYONDHOSTING.NET.
gov-1l.us. 86400 IN NSEC GOV-ABUSE.us. NS RRSIG NSEC
o implícitamente inseguro (exclusión de NSEC3):
stackexchange.com. 172800 IN NS brad.ns.cloudflare.com.
stackexchange.com. 172800 IN NS roxy.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
4OTDAP6T1E8VS8BHMCK8CDHSGE3GCOBM.com. 86400 IN NSEC3 1 1 0 - 4OTJJUP7OGM6C149HPOE7O9M1L9LS1OP NS DS RRSIG
( stackexchange.com hashes a 4otjehvpu9q5tm1d5v0ec302rcbll9um que está cubierto por la segunda denegación, por lo tanto, no hay una delegación segura).
En todos estos casos, SI hay una delegación segura, el registro NSEC [3] para el nombre en cuestión probará la presencia de DS. Por lo tanto, si las firmas se eliminan, un cliente de validación puede detectar esto.
Para leer más, recomiendo RFC7129: Denegación de existencia autenticada en el DNS y sección 5.2 (Autenticación de referencias) de RFC4035 (Modificaciones de protocolo para las extensiones de seguridad de DNS)
Lea otras preguntas en las etiquetas man-in-the-middle dns dns-spoofing dnssec