Episode 2
Nuevos registros
Para validar la autenticidad de los datos DNS, DNSSEC introduce nuevos de registros DNS.
Lo primero que hará tu proveedor DNS al configurar tu dominio con DNSSEC es agrupar todos los registros en RRsets.
RR en RRsets significa Resource Records. Una forma elegante de decir “registros del mismo tipo y nombre” dentro de una zona o dominio.
Los RRsets agrupan todos los registros del mismo tipo y nombre en un conjunto que se firma digitalmente.
En el mundo físico, los humanos usan firmas para vincular identidad y autenticidad a un mensaje.
La misma analogía se aplica al mundo DNSSEC.
El servidor autoritativo firma cada RRset con claves de firma de zona (ZSK).
Hablaremos de más claves luego, así que recuerda que estas se usan para generar y verificar la firma sobre los registros de zona.
Cada ZSK tiene una pareja de claves. Una privada y otra pública. Esta es la base de la criptografía asimétrica.
Las claves privadas y públicas trabajan juntas. Los datos cifrados con la clave privada pueden descifrarse o validarse con la clave pública.
La clave pública puede compartirse con cualquiera. Es pública y accesible para todos.
Las claves privadas son (lo has adivinado) privadas y no deben compartirse.
¡Que los cangrejos no las consigan!
Juntas estas claves aportan dos cosas importantes.
Uno: Verificar que el contenido proviene de la fuente correcta.
Dos: Verificar que el contenido no se ha alterado desde que se envió.
Estas claves no se usan para cifrar todo el contenido de los registros. En su lugar, se crea una firma digital tomando una porción del RRset, haciendo hashing y cifrándola.
El proceso de hashing no solo es relevante para la validación.
El hashing reduce el tamaño del contenido enviado, haciendo la firma de longitud fija.
Esto es importante porque queremos mantener el protocolo de DNS pequeño y ligero.
Las firmas se almacenan en un registro DNS llamado RRSIG (Resource Record Signature).
Y la clave pública para descifrar ese registro RRSIG se almacena en un nuevo tipo de registro DNS llamado DNSKEY.
Así es como sucede…
Parte del contenido del RRset se transforma con un algoritmo de hashing.
El resultado se cifra con la parte privada de la clave de firma de zona, creando un registro RRSIG.
Después, el servidor autoritativo envía el RRset y el RRSIG al recusor.
El recusor toma el RRset y le aplica un hashing, igual que lo hizo el servidor autoritativo con el mismo algoritmo.
El recusor descifra el registro de firma con la parte pública de la clave de firma de zona para obtener un hash.
Si ambos hashes coinciden, el recusor sabe que la respuesta proviene de la fuente esperada y no ha sido manipulada.
Un recusor que no admite DNSSEC o que no dispone del algoritmo de hashing ignorará la firma que acompaña al registro.
Este es el flujo actual cuando el recusor DNS solicita el registro A de www.dnsimple.com.
El servidor autoritativo devuelve el registro A dentro de un RRset y el registro RRSIG.
El recusor pide entonces el registro DNSKEY para validar que el registro solicitado es válido y procede de una fuente de confianza.
El recusor valida la respuesta a través del RRset, el RRSIG y el DNSKEY.
Pero ¿y si el DNSKEY fuese falseado?
