Podcast: Descargar (Duración: 19:35 — 18.8MB)
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:
- 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.
- 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.
Una vez tenemos habilitado el DNSSec vamos a ver cómo funciona:
- 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.
- 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)
- 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.
- 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.
- 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
edu@Andromeda ~ # dig +dnssec ns com @l.root-servers.net ; <<>> DiG 9.13.7 <<>> +dnssec ns com @l.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22834 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;com. IN NS ;; AUTHORITY SECTION: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20190310170000 20190225160000 16749 . N9g+eeSjBKK+bOPW8IA/JGGQgTVrdZ12fIFS+8ggHLVW3LGQI6YTmpef +O+dbqeaFOnYcGBlRcc7HD9bVIy+ygImoMnKos98hx9YfPR+XK2HUBWM oZTT3yr27eL0hKxby4srlECX1B51gwuuYQQYpL8FI2Gl4v0eB0pMZWZ1 A0FUNWZA20lZ7HrBQ9OLnWCGkMgKkXqTvhcd0dhr0e3cVKmhC2m+de4X FlVm1zSjnmtEv6kT2n8YxnOsdNMs8VFa94MsjLr2OvT/HfbDmIiyEPEz 0U8K9oeFhVR2wczDydOiMpZ4l29aPMcZ7qQLaWGpOxHgTYiODlFD/qBY 00lq1w== ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 m.gtld-servers.net. 172800 IN A 192.55.83.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 ;; Query time: 37 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: lun feb 25 19:26:28 CET 2019 ;; MSG SIZE rcvd: 1163 edu@Andromeda ~ # dig +dnssec ns eduardocollado.com @e.gtld-servers.net ; <<>> DiG 9.13.7 <<>> +dnssec ns eduardocollado.com @e.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40192 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;eduardocollado.com. IN NS ;; AUTHORITY SECTION: eduardocollado.com. 172800 IN NS ns1.neodigit.net. eduardocollado.com. 172800 IN NS ns2.neodigit.net. eduardocollado.com. 86400 IN DS 38890 13 1 38BF99A8BB8A4D3FA8D66A65964014099C2D34E9 eduardocollado.com. 86400 IN RRSIG DS 8 2 86400 20190304054735 20190225043735 16883 com. tPJ2JQf9590P2yOZ3WroyEwqh1Aa+WsiYdV8BS/vqFKeqXsS2nPxPOl1 ijWLq90pUYyBUE7hBD3ZDsqPoguo4YeWKxqNbc87BbqhXudMpdjHC+Wl Gd9XbBHOtcu7qKff1gTsU/lxVg9cQ14Uzqbu/V56zOlPexua/66FUgmr G4g= ;; Query time: 42 msec ;; SERVER: 192.12.94.30#53(192.12.94.30) ;; WHEN: lun feb 25 19:26:52 CET 2019 ;; MSG SIZE rcvd: 294 edu@Andromeda ~ # dig +dnssec eduardocollado.com @ns1.neodigit.net ; <<>> DiG 9.13.7 <<>> +dnssec eduardocollado.com @ns1.neodigit.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;eduardocollado.com. IN A ;; ANSWER SECTION: eduardocollado.com. 7200 IN RRSIG A 13 2 7200 20190307000000 20190214000000 38890 eduardocollado.com. FHBRqGzga6FVCfNar88YM7xhh1cTZQd2YpM5ZIF9/BM49M96qrZ4D+wP nh1lxBpEhyG/ptHMqF2FwSE6OJ12Xg== eduardocollado.com. 7200 IN A 31.47.74.50 ;; Query time: 7 msec ;; SERVER: 31.47.72.140#53(31.47.72.140) ;; WHEN: lun feb 25 19:27:37 CET 2019 ;; MSG SIZE rcvd: 177 edu@Andromeda ~ #
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.