En el momento de decidir firmar una zona con DNSSEC, una de las decisiones iniciales es qué sistema de “negación” se utilizará. Existen dos actualmente, la original y más simple llamada “NSEC”, y una posterior que es mucho más compleja, llamada “NSEC3”. (¿Por qué no hay “NSEC2″? Por la misma razón que no hay IPv5).

La recomendación siempre ha sido utilizar NSEC3 solo en casos especiales, generalmente orientado a registros (TLD) que requieren por razones legales o de privacidad mantener la lista de subdominios en forma secreta. También NSEC3 es atractivo para este tipo de registros porque permite hacer firma parcial de su zona, utilizando la técnica “opt-out”, que permite ir creciendo en tamaño de zona y de registros en forma gradual, a medida que los subdominios van activando DNSSEC,xi sacrificando un poco de seguridad.i

Pero bueno, cada administrador tiene las razones y decide qué técnica utilizará.

Si decide utilizar NSEC3, en seguida hay que definir otras variables importantes, como algoritmo de firmado, tamaño de llaves, etc; y entre algunas de esas decisiones es definir dos parámetros que tienen que ver con el “salting” de los nombres: número de iteraciones y tamaño del salt, así como el cambio regular de este último valor.

Esta es información criptográfica que permite lograr mayor seguridad para evitar el descubrimiento de los nombres de una zona. Por lo general los softwares de firmado vienen con valores por defecto razonables, y en una alta cantidad de instalaciones estos valores no se modifican.

Sin embargo, ahora último ha comenzado una preocupación por poner límites a estos dos valores. Análisis de seguridad por expertos criptográficos han considerado que no es necesario tener estos parámetros de salt ni de iteraciones en la mayor parte de las zonas, por lo que la recomendación actual es: poner en cero las iteraciones, y usar un salt vacío. Se considera que la ganancia en seguridad de poner valores más elevados es mínima, y tiene la desventaja de exigir un alto procesamiento a los resolutores (resolvers) que deben validar los registros de esa zona.

Aunque el estándar actual tiene límites teóricos un tanto exagerados, y nada impide utilizar valores grandes, el problema es que ahora son los resolutores quienes pueden a su vez prohibir por implementación valores mayores, que le puedan significar un procesamiento elevado y tiempos de respuesta altos al resolver y validar nombres de dominio en estas zonas. Nada les impide protegerse frente a valores no razonables.

Es así como el mes pasado (marzo 2021), ya tenemos el primer software resolutor de código abierto que ha decidido poner un límite máximo de 150 iteraciones para validar con NSEC3[1] (actualización mayo de 2021: Bind también limita a 150 iteraciones[4]). Si un dominio actualmente indica más de 150 iteraciones, ese resolutor se negará a validarlo, y marcará la zona como “insegura”, es decir, ¡tal como si no tuviera DNSSEC activo!

Ya se está trabajando a nivel de estándares en IETF[2] para escribir un documento que analiza esta situación, y se han realizado charlas[3] sobre el tema en conferencias del ámbito DNS.

Le recomendamos por ende revisar cuántas iteraciones está realizando en su dominio, si es que utiliza NSEC3. Cualquier consulta por el tipo “NSEC3PARAM” entrega este valor en el tercer número, por ejemplo este dominio “ejemplo.cl” tiene 250 iteraciones, y un valor de salt “4240ECEF733CBFBD”:

$ dig -t nsec3param ejemplo.cl +short 1 0 250 4240ECEF733CBFBD

La recomendación es bajar el valor de número de iteraciones a 0 (en realidad este número es el “extra” de iteraciones, ya que siempre se hace 1), y dejar vacío el salt (valor “-”). Por ejemplo la herramienta de Bind “dnssec-signzone” acepta los parámetros “-3 - -H 0” que logran dicho resultado.

Referencias: - [1]: “validator: downgrade NSEC3 records with too many iterations”, Knot Resolver 5.3.1 (2021-03-31), https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1 - [2]: “Guidance for NSEC3 parameter settings”, draft document in IETF, https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/ - [3]: “NSEC3 Iterations etc. High Counts and opt-out considered harmful, avoid fixed salt”, talk from ICANN DNSSEC Workshop, https://cdn.filestackcontent.com/content=t:attachment,f:%228.%20Viktor%20Dukhovni%20NSEC3-ICANN.pdf%22/m2OglWwSR2o9L4m6Xsgo (PDF) - [4]: ”DNSSEC responses containing NSEC3 records with iteration counts greater than 150 are now treated as insecure”, Notes for BIND 9.16.16 (2021-05-20)