DNSSec

Antes de meternos a explicar qué es DNSSec es necesario que os hable de alguna cosa antes.

La zona raíz, aquí estamos hablando de los root servers de los que hablamos hace tan sólo unos días en el Podcast #187: Root Servers.

También tenemos que saber que la zona raíz tenemos que firmarla, esto seguro que ya los sabéis también porque en el capítulo Podcast #175: Traspaso de la KSK en la Zona Raíz con João Damas estuvimos hablando justamente de eso, aunque hoy hablaremos un poquito más sobre el tema.

Realmente si recordáis el podcast del traspaso de la KSK, la sigla KSK corresponde a clave de firma de clave y la sigla ZSK corresponde a clave de firma de zona.

Otro concepto a tener en cuenta es que tenemos que generar un DS (Delegation signer) que lo que contiene es un hash de la clave pública con la que hay que verificar las respuestas de esa zona.

Además en DNSSec tendremos unos registros extras que vendrán acompañando a cualquier consulta llamados RRSIG (Resource Record SIGnature) que contienen la firma digital del registro que se solicitó y que tienen que ser regenerados de vez en cuando. El registro RRSIG se valida con la clave pública del dominio en cuestión, que puede ser validada por ser un registro DS en la zona superior, el cual a su vez está firmado.

Como nota es interesante saber que para ir regenerando los RRSIG es necesario disponer de una KSK Y una ZSK, la KSK se utilizará para firmar la ZSK y la ZSK se utilizará para firmar el resto. Ojo que en PowerDNS en vez de KSK y ZSK tenemos sólo CSK, eso sí, un CSK por dominio.

Y por último tenemos que conocer que el registro DNSKEY (clave pública) necesario para poder validar las siguientes respuestas.

De momento la cosa parece un poco críptica, así que vamos a tratar de explicar esto despacito.

Lo primero es habilitar DNSSec en nuestros dominios, ya que si no lo hacemos esto esto carece de sentido. Para poder habilitar DNSSec en un dominio necesitamos dos cosas:

  1. El registrador del dominio pueda poder aceptar los registros DS (Delegation Signature) y poder enviarlos a un dominio de nivel superior (TLD), como .com, .org o .net.
  2. El proveedor de hosting de DNS que opera los servidores DNS para el dominio sea compatible con DNSSEC y tiene que poder firmar sus archivos de zona DNS.
Configuración de DNSSec en Neodigit.

Una vez tenemos habilitado el DNSSec vamos a ver cómo funciona:

  1. Pedimos a los root servers la lista de servidores que sirven el dominio de primer nivel, en mi caso .com. Estamos pidiendo los registros NS. Esto vendrá acompañado de un RRSIG para validarlos y solicitaremos el DS del dominio de primer nivel, el cual vendrá con su RRSIG para validar.
  2. Nuestro servidor DNS valida que los registros NS y DS son correctos gracias a la clave que tenemos descargada que el RRSIG sea valido. Estamos validando el root. (/etc/bind/bind.keys en Bind)
  3. Ahora le pedimos al servidor DNS del siguiente nivel (.com) su clave pública (DNSKEY) que validamos con el DS generando el hash al DNSKEY.
  4. En este punto pedimos los DNS (NS) del dominio de segundo nivel, por ejemplo eduardocollado.com y nos va a enviar los NS, con su DS y los RRSIG correspondientes.
  5. Y hacemos lo mismo con los servidores DNSs del dominio.

Ahora tenemos el tema de la rotación de llaves, el rolling keys, algo que es complicado porque si generamos una nueva llave es necesario cambiar el DS del dominio en el nivel inferior y eso requiere una acción manual del usuario, así que es algo realmente complejo.

Hay alternativas por lo que he podido entender de lo que mi compañero Adrian Almenar me ha estado explicando, voy a ver si soy capaz de contároslo.

Tenemos dos opciones, utilizando un registro CDSNKEY y por otro lado utilizando registros DS o CDS.

El CDSNKEY será el contenido de la llave para generar el DS, mientras que los registros DS o CDS serían directamente el DS, con la única diferencia que DS es sha-1 y CDS es sha-2, pero se trata de lo mismo.

La idea es que el registrador superior reciba el DS sin una intervención directa, es interesante cuando hay que generar una nueva llave, porque automatizaría el proceso, pero claro, el problema que yo le veo es que eso sólo se podría hacer a partir de la segunda llave, y no veo que la primera vez se pudiera usar esta forma de trabajar. De momento parece ser que el .CZ sí que lo permite, pero ninguno más, así que esto es algo más a futuro que otras cosas.

Aquí os dejo un ejemplo con el dominio eduardocollado.com

Como veis el sistema de DNSSec es una relación de confianza de zonas padres e hijas utilizando criptografía asimétrica, es decir, con el uso de claves privadas y claves públicas.

Obviamente DNSSec no soluciona todos los problemas de seguridad en Internet, pero ayuda mucho ya que hacemos que las respuestas de los DNSs unas sean dependientes de los niveles superiores, una especie de blockchain ahora que está tan de moda esa palabra.

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.