Esta entrada de publicó antes de terminarse. En cuanto esté lista aparecerá como una nueva. Perdón por el despiste 🙂

¿Qué es?

DNSSEC es una extensión al sistema de resolución de nombres (DNS) que permite aumentar la seguridad de éste, evitando ataques como el envenenamiento de cache (respuestas falsas con el fin de dirigir el tráfico a un destino diferente al real).

Básicamente añade autenticación a las respuestas DNS mediante firma digital, permitiendo a los clientes validar la veracidad de dichas respuestas. DNSSEC no cifra el tráfico entre clientes y/o servidores, que sigue siendo «en claro». Ni evita ataques de denegación de servicio.

¿Cómo funciona DNSSEC?

El funcionamiento se basa en una delegación de confianza entre las zonas padre e hijas y el uso de criptografía asimétrica (clave pública/privada). La zona raíz (.) está firmada con una clave privada y su pública es de conocimiento global (normalmente viene incluida en los servidores DNS). En dicha zona (.) se encuentra un registro DS (Delegation Signer) por cada zona hija (.com, .net, .org, .es,…) que contiene un hash de la clave pública correspondiente a cada una de ellas.

Es decir, en la zona raíz (.) hay un registro DS que indica cual es la clave pública de la zona .net. En la zona .net hay un registro DS para cada dominio (que soporte DNSSEC) que cuelga de ella. Por ejemplo, en la zona .net, además de los servidores DNS (NS) que sirven el dominio inittab.net, también hay un registro DS que indica con que clave (por su hash) hay que verificar las respuestas de esa zona.

Cuando usamos DNSSEC, las respuestas a una pregunta DNS (sea un registro A, MX, DS, CNAME, …) vendrán acompañadas de un registro «extra» de tipo RRSIG (Resource Record SIGnature) que consiste en la firma digital (con la clave privada de la zona) del registro que se solicitó. Este registro RRSIG puede ser verificado con la clave pública de inittab.net, que además puede ser validada al ser un registro DS en la zona padre (.net), que a su vez está firmado por la clave privada de ésta,….

De forma que si solicitamos el registro MX del dominio inittab.net, el proceso (que seguiría normalmente el servidor DNS que nos presta el servicio de resolución de nombres) sería:

• Solicitar a los servidores raíz la lista de DNS (registros NS) que sirven el dominio .net. La respuesta llevaría dichos registros (NS), además de los correspondientes RRSIG para validarlos. Además habría que solicitar el registro DS (hash de la clave pública) del dominio .net, para poder validar la respuesta que nos den los siguientes servidores DNS. Por supuesto este registro (DS) será verificable con su correspondiente registro RRSIG (firma creada con la clave privada del dominio raíz).
• Nuestro servidor DNS validaría con la clave pública de la zona raíz (que ya tiene, por ejemplo en /etc/bind/bind.keys) que la firma (RRSIG) de los registros NS y DS es correcta y por tanto la información válida.
• Lo siguiente sería pedir a alguno de los servidores encargados de .net su clave pública (registro DNSKEY) para poder validar las siguientes respuestas que nos dé. Este registro debe contener una clave cuyo hash coincida con el que venía en el registro DS que nos entregó la zona raíz y que ya validamos. (Aquí he simplificado un poco el proceso, luego hablaremos de los dos tipos de claves de firmado, KSK y ZSK)
• Ahora, con la clave pública (ya validada) del dominio .net, podemos pedir a sus DNS los registros NS del dominio inittab.net y el registro DS con el hash de su clave pública. Por supuesto las respuestas a estas preguntas vendrán acompañadas de los correspondientes registros RRSIG que permitirán comprobar la validez de las mismas con la clave pública de .net.
• El proceso se repetiría con los DNS de inittab.net. Es decir, pedimos la clave pública de inittab.net (DNSKEY) verificamos que su hash coincide con el registro validado DS que nos entregaron los servidores de la zona padre (.net) y con ella validaremos el resto de peticiones que hagamos del dominio y que vendrán acompañadas de sus correspondientes RRSIG.

Claves de firma de clave y claves de firma de zona (KSK vs ZSK)

Como se puede observar del proceso anteriormente descrito, las zonas padre deben contener una referencia (DS) a la clave con la que las zonas hijas firman sus registros. En el caso de un dominio tradicional (p.e. inittab.net), eso requiere de informar en el registrador, junto con los DNS que lo servirán, el valor de dicho registro DS para el domino. Esto es un proceso manual y poco automatizable.

Además la información que se firma de los registros de un dominio es muy pequeña (una IP, un nombre de máquina, un registro SPF, etc..), lo que «facilita» el criptoanálisis de la clave con la que están firmados. Por ello es conveniente cambiar la clave con la que se firman de forma periódica.

De hecho los registros RRSIG tienen una validez temporal (independiente del TTL del dominio) y tienen que ser recreados (firmados) de forma periódica. El motivo es evitar ataques de repetición (Replay Attacks) que permitirían reutilizar una respuesta vieja (firmada hace meses o años) por un atacante para engañar a un cliente.

Por estos motivos, y para facilitar el cambio de la clave con la que se firman los registros de la zona, se recomienda el uso de dos claves: KSK y ZSK. La clave KSK (Key Signing Key) es aquella que estará «informada» como DS en la zona superior. Su función es la de firmar la clave de zona (ZSK) con la que están firmados el resto de registros del dominio. Es decir, la «exposición» de la KSK es mínima.

Por el contrario la ZSK (Zone Signing Key) es la que firma todos los registros de la zona. Puede ser algo más «pequeña/corta» que la KSK ya que su rotación periódica es más sencilla que la de una sola clave o la de la KSK. Es decir, no hay que modificar la zona padre (cambios en el registrador) cuando se quiera cambiar de clave de firmado de zona (ZSK), basta con generar una nueva y firmarla con la KSK, únicamente informando los cambios en nuestra zona DNS.

Desde el punto de vista técnico no hay diferencias (importantes) entre un tipo de clave y otro. Sólo es la forma en la que se usan lo que las diferencia. De hecho puede usarse una única clave, informando a la zona padre de ésta, y firmando todo con ella. El problema es que el trabajo de cambio de clave será más complejo. Mientras que el de cambio de una ZSK usando una KSK está prácticamente automatizado con las herramientas DNSSEC que usaremos y no
requiere de cambios en el registrador del dominio.

Así que aunque parezca una solución más complicada inicialmente, el uso de una clave para cada función a la larga es más seguro y más sencillo de gestionar.

 

En la próxima entrada veremos todos los pasos necesarios para implementar DNSSEC en nuestro dominio.

$ exit