Esto significa que los sitios web tienen pocos incentivos para comenzar a admitir DNSSEC, ya que un MITM puede falsificar un registro DNS simplemente al no incluir una firma.
Esto es incorrecto. Si un atacante MITM envía un resultado sin una firma a un cliente que admite DNSSEC, la resolución fallará . Esto se debe a que hay un registro DS firmado para ese dominio devuelto por los servidores de nombres de TLD. El atacante MITM no puede también quitar ese registro, ya que entonces deberá proporcionar una respuesta con un registro NSEC / NSEC3 válido y firmado que demuestre que el registro DS solicitado no existe. Esto es imposible sin obtener la clave privada de TLD (o raíz).
Parece que una solución fácil sería proporcionar declaraciones firmadas de que un sitio web no es compatible actualmente con DNSSEC, de manera similar a la forma en que funcionan las respuestas firmadas para los subdominios.
¿Esto es parte de DNSSEC? Si no, ¿por qué no? ¿Qué otras soluciones hay para este problema / es un problema?
No hay un registro específico responsable de los dominios que no admiten DNSSEC. En su lugar, el servidor probará que el registro DS (que indica que el dominio usa DNSSEC) no existe.
Una de las razones fue que, por razones de compatibilidad con versiones anteriores
La especificación EDNS es totalmente compatible con versiones anteriores. Como DNSSEC utiliza EDNS, también es totalmente compatible con versiones anteriores. Los clientes que no admiten DNSSEC simplemente no solicitarán (y el servidor no responderá con) las firmas DNSSEC. Estos clientes no recibirán los beneficios de DNSSEC, pero podrán consultar las zonas firmadas por DNSSEC sin problemas. El uso de registros DS en los servidores de nombres raíz y los servidores de nombres de TLD permite que los TLD y los dominios no se firmen sin ningún problema (sin embargo, dichos TLD / dominios obviamente no recibirán los beneficios de DNSSEC).