Activar verificación de DNSSEC en "dnsmasq"

Por defecto, los sistemas Ubuntu no verifican DNSSEC en el resolver. ¿Es posible solucionarlo?.

Ubuntu (y otras muchas distribuciones Linux) emplean dnsmasq como resolver DNS local. Las versiones modernas de dnsmasq soportan DNSSEC, pero no está activado por defecto.

La configuración varía según estemos usando NetworkManager (habitual en entornos domésticos) o no (lo normal en servidores). Describiré el caso de la distribución Ubuntu 16.04:

  • Si no utilizamos NetworkManager:

    • Editamos el fichero /etc/dnsmasq.conf y descomentamos las líneas:

      #conf-file=%%PREFIX%%/share/dnsmasq/trust-anchors.conf
      #dnssec
      #dnssec-check-unsigned
      

      convirtiéndolas en:

      conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
      dnssec
      dnssec-check-unsigned
      
  • Si utilizamos NetworkManager:

    • Añadimos un fichero nuevo en el directorio /etc/NetworkManager/dnsmasq.d/. Supongamos que dicho fichero se llama dnssec.conf. El nombre no es importante, siempre que tenga la extensión kbd.

    • El contenido de dicho fichero debe ser:

      conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
      dnssec
      dnssec-check-unsigned
      

Para comprobar si todo está funcionando correctamente, podemos realizar una consulta DNS:

$ dig jcea.es

; <<>> DiG 9.10.3-P4-Ubuntu <<>> jcea.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34573
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;jcea.es.                       IN      A

;; ANSWER SECTION:
jcea.es.                28446   IN      A       176.9.11.11

;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jan 10 19:56:02 CET 2018
;; MSG SIZE  rcvd: 52

La clave aquí está en el status: NOERROR y en la línea:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Hay que fijarse en los flags. El significado es el siguiente:

  • qr: Indica que se trata de una respuesta DNS.
  • rd: Indica que en la petición al servidor DNS le solicitamos recursión, si es necesaria para resolver la pregunta DNS.
  • ra: Indica que el servidor está dispuesto a darnos recursión.
  • ad: Significa Authenticated Data. Es decir, que los datos proporcionados están protegidos por DNSSEC y que la verificación de los mismos ha sido exitosa.

Veamos que ocurre si solicitamos datos de un dominio DNSSEC configurado expresamente para entregar datos incorrectos, corruptos o manipulados:

$ dig dnssec-failed.org

; <<>> DiG 9.10.3-P4-Ubuntu <<>> dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1892
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec-failed.org.             IN      A

;; Query time: 156 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jan 10 20:26:08 CET 2018
;; MSG SIZE  rcvd: 46

Aquí vemos que la resolución DNS falla con un error status: SERVFAIL. No es un código de error muy claro, pero hay muchos sistemas antiguos por ahí que no sabrían interpretar otro tipo de respuesta. La dictatura de los sistemas heredados, que nunca desaparecen del todo.

dnssec-failed.org es un dominio DNS configurado expresamente para fallar la verificación DNSSEC. Podemos verlo en toda su gloria así:

Advertencia

Cuando dnsmasq no tiene en caché la respuesta a lo que le estamos preguntando, la enviará a servidores DNS externos. Es imprescindible que dichos servidores soporten DNSSEC. Si no es así, dnsmasq será incapaz de resolver nada.

Lamentablemente la mayoría de los servidores DNS de los proveedores de acceso a Internet de España no tienen DNSSEC activado. Es triste, pero es así.

Lo más evidente, pero que supone un compromiso de privacidad, es utilizar proveedores de DNS de terceros que sepamos que van a sobrevivir muchos años y que soporten DNSSEC. Los más evidentes, pero menos recomendables desde la perspectiva de la privacidad, son los 8.8.8.8 y 8.8.4.4 de Google o el 1.1.1.1 de Cloudflare [1].

[1] Actualización 20180407: Añado la dirección de Cloudflare. Tampoco es que me emocione, pero al menos no dárselo todo al mismo señor feudal...

Personalmente tengo servidores propios en internet para estar tareas y también suelo preferir utilizar un servidor DNS de verdad como BIND.

Si estás en un entorno doméstico, muy posiblemente tengas que configurar tu sistema para que no utilice el servidor DNS que te entrega el DHCP de tu proveedor de acceso a internet. Será el tema de una entrada futura del blog.

Actualización 20180204: Puedes ver cómo hacerlo en Ignorar la configuración DNS que nos llega por DHCP (y usar dnsmasq).