Resumen

  • RFC 5155 permite omitir del encadenamiento NSEC3 determinadas delegaciones sin firma cuando el registro que las cubre lleva el indicador Opt-Out.
  • Ese registro no afirma si las delegaciones inseguras cubiertas existen o no; autentica una negación de alcance más limitado.
  • Una delegación segura requiere un RRset DS firmado y una cadena validada, no solo una firma NSEC3 correcta alrededor del hash consultado.
  • El control debe conservar los resultados seguro, inseguro e indeterminado, en vez de resumirlos como «DNSSEC superado».

Pensemos en una traza del resolvedor donde todas las RRSIG validan y los intervalos NSEC3 encajan. La exportación de auditoría convierte luego esa línea verde en «delegación hija segura». Pero el nombre está dentro de un intervalo Opt-Out. La prueba era auténtica; la conclusión era demasiado amplia.

Es un caso hipotético. La validez criptográfica no puede ampliar lo que el registro firmado afirma.

Qué modifica Opt-Out

RFC 5155 define NSEC3 como una forma con hash de negación de existencia autenticada. La zona firma registros ordenados por hash, en lugar de exponer una cadena legible de nombres propietarios.

En una zona centrada en delegaciones, mantener un NSEC3 y una firma para cada hijo sin firma puede ser costoso. Opt-Out permite excluir los nombres de delegaciones inseguras aptas. Un registro con el indicador activado puede abarcar cero o varias, y esas delegaciones pueden añadirse o retirarse sin reconstruir esa parte de la cadena.

La economía operativa cambia el alcance de la prueba. RFC 5155 indica que un NSEC3 Opt-Out no afirma la existencia ni la inexistencia de las delegaciones inseguras que puede cubrir. Sigue haciendo afirmaciones autenticadas sobre otros datos autoritativos del intervalo, pero el hijo sin firma queda deliberadamente fuera del inventario criptográfico completo.

Una prueba válida puede terminar en «inseguro»

La evidencia del padre en el punto de delegación es decisiva. RFC 5155 distingue una delegación segura —RRset NS acompañado por un RRset DS firmado— de una insegura con NS pero sin DS. El DS conecta los datos autenticados del padre con la DNSKEY del hijo.

Validar la RRSIG del NSEC3 demuestra que el padre firmó esa declaración. No fabrica un DS para el hijo cubierto, y el indicador Opt-Out tampoco afirma por sí mismo que exista esa delegación. RFC 7129 lo expresa claramente: los registros Opt-Out no pueden probar ni negar la existencia de las delegaciones inseguras que cubren, y estas no reciben la seguridad criptográfica de DNSSEC.

El resolvedor debe identificar el punto de delegación, encontrar DS o autenticar su ausencia, evaluar el NSEC3 pertinente y seguir la validación donde exista cadena. Seguro, inseguro, bogus (validación fallida) e indeterminado son resultados distintos.

Conservar el alcance de la prueba

La evidencia debe nombrar consulta, código de respuesta, zona y delegación. Para NSEC3 conserva algoritmo, iteraciones, sal, hash propietario, siguiente hash, mapa de tipos e indicador Opt-Out. Añade el ancestro demostrable más cercano cuando corresponda, los resultados DNSKEY/RRSIG y el ancla de confianza.

También importan tiempo y caché. TTL, inicio y caducidad de firmas, publicación en el padre y edad del caché limitan la observación. Un cambio posterior de DS puede alterar el estado aunque la antigua prueba siga archivada.

La conclusión defendible es concreta: esta respuesta NSEC3 firmada validó para esta consulta y respaldó esta clasificación en este momento. No dice que toda delegación cubierta sea segura.