Admin Libre - Administración de sistemas y redes

Servidor DNS caché privado con bloqueo de anuncios
Por Francisco Gaitán el 25 de Septiembre de 2023

Voy a configurar mi propio servidor de DNS caché para no tener que utilizar los DNS de mi ISP ni ningún servicio de DNS público con bloqueo de anuncios.

Usar un servidor remoto tiene algunas ventajas:

  • El servidor puede estar alojado en un proveedor con mayor respeto a la privacidad
  • Ahorro de recursos si usas un EdgeRouter Lite y vas a usar unbound-adblock
  • El servidor remoto guarda las consultas que no han expirado aunque apagues el router

Una alternativa más ligera al túnel consiste en usar TLS con la opción forward-tls-upstream en unbound y DNS sobre TLS en el servidor.

Topología de red

  • Un servidor OpenBSD corriendo unbound
  • Un router local OpenBSD corriendo unbound
  • Un túnel WireGuard que conecta ambos servidores

Funcionamiento

Cuando un host conectado al router pide la resolución de un nombre de dominio al router, si éste no lo tiene en caché reenviará la consulta al servidor remoto a través de un túnel WireGuard. En caso de que el servidor remoto no tenga la respuesta éste la realizará de forma recursiva desde los servidores raíz y guardará los resultados en caché de acuerdo al valor TTL de los registros y devolverá el resultado al router local, que a su vez enviará la respuesta al host que realizó inicialmente la consulta.

Configuración del túnel WireGuard

Voy a crear un túnel WireGuard de forma que el router incia las conexiones hacia el servidor. Tendrá direcciones locales IPv4 e IPv6 para servir la red local, aunque se conectará al servidor a través de IPv4. Esto lo explico aquí:

Usaré estas subredes:

  • Servidor remoto:
    • 172.16.1.1/12
    • fdb9:a1d2:585c:0::1/64
  • Router local:
    • 172.16.1.10/12
    • fdb9:a1d2:585c:0::100/64

WireGuard en el servidor remoto

wgkey `cat /etc/wireguard/$(hostname).key` wgport 51820
wgpeer <clave-publica-router> wgaip fdb9:a1d2:585c:0::100/64 wgaip 172.16.1.10/32 
inet 172.16.1.1/12
inet6 fdb9:a1d2:585c:0::100/64 
up
description "DNS tunnel"

WireGuard en el router local

wgkey `cat /etc/wireguard/$(hostname).key`
wgpeer <clave-publica-servidor> wgendpoint <ip-publica-servidor> 51820 wgaip fdb9:a1d2:585c:0::1/64 wgaip 172.16.1.1/32 wgpka 25
inet 172.16.1.10/12
inet6 fdb9:a1d2:585c:0::100/64 
up
description "DNS tunnel"

Configuración de unbound

Como de costumbre explicaré solamente las partes relevantes de la configuración unbound.conf(5), no la configuración completa, que la explica mucho mejor la documentación oficial.

El puerto correspondiente a DNS es el 53 TCP y UDP. Si usas DNS sobre TLS (DoT) sería 853 TCP y UDP.

unbound en el servidor remoto

Escucho en la interfaz local con IP 172.16.1.1 y permito acceso al router local

server:
   interface: 172.16.1.1
   access-control: 172.16.1.10/32 allow

Esta es la parte correspondiente a unbound-adblock cuya instalación viene explicada en la documentación oficial:

   # Required modules for RPZ
   module-config: "respip validator iterator"

   rpz:
      name: "unbound-adblock"
      zonefile: "/var/unbound/db/adblock.rpz"
      rpz-log: yes
      rpz-log-name: "unbound-adblock"

Opcionalmente se pueden reenviar las peticiones al servidor DNS del proveedor en lugar de hacerlas de forma recursiva:

   forward-zone:
      name: "."
      forward-addr: 203.0.113.1 

unbound en el router local

Este router servirá DNS a través de interfaces locales IPv4 e IPv6 a las redes 192.168.100.0/24 y 2001:db8:83ac:1aa::/64. Las consultas que no tenga guardadas en caché serán reenviadas al servidor remoto a través del túnel WireGuard.

server:
   interface: fdb9:a1d2:585c:0::100
   interface: 192.168.100.1
   access-control: 2001:db8:83ac:1aa::/64 allow
   access-control: 192.168.100.0/24 allow

Especifico el servidor recursivo donde enviar todas las consultas:

forward-zone:
   name: "."
   forward-addr: 172.16.1.1

Resolución de DNS en el servidor y en el router

En este caso no quiero que las consultas pasen por el bloqueador de DNS, por lo que correré unwind sin archivo de configuración para que funcione como recursor. resolvd se encargará del archivo resolv.conf(5):

router# rcctl enable unwind resolvd
router# rcctl start unwind resolvd
servidor# rcctl enable unwind resolvd
servidor# rcctl start unwind resolvd

Configuración del DNS en una máquina de la red local

Los servidores DNS de la red serían los correspondientes a las interfaces de unbound en el router local, las cuales se sirven desde dhcpd.conf(5) y rad.conf(5) o se configuran a mano sin olvidar desactivar resolvd(8):

  • fdb9:a1d2:585c:0::100
  • 192.168.100.1

O, sin desactivar resolvd, también se puede usar unwind(8), cuya configuración podría ser algo así:

fwd1 = 192.168.100.1 
fwd2 = fdb9:a1d2:585c:0::100 
preference { forwarder }
forwarder { $fwd1 $fwd2 }

Gracias a la opción preference unwind se limita a reenviar las peticiones sin hacer de recursor, de lo contrario los bloqueos de unbound-adblock no serán efectivos.

Destacado

Contacto

Si has encontrado algún error o quieres comentarme algo mándame un correo a webmaster@adminlibre.org