Unbound, ahora el DNS central de mi red
Después de haberme pasado de Pi-hole a AdGuard Home y lograr que todo funcionara bien, siempre había algo que me hacía sentir que faltaba algo y es que cada cierto tiempo que entraba, me saltaban a los ojos los números del tiempo de respuesta del DNS que resolvía los dominios. Veía que pasaba de 1 ms o 3 ms a más de 30 ms, y eso no me caía muy bien, además, al hacer dig no lo tomaba desde la caché en algunas webs
;; ANSWER SECTION:
github.com. 58 IN A 140.82.112.3
;; Query time: 150 msec
como se ve, luego de un tiempo el query time pasa de ser 1ms a 150ms y eso es algo que no me gusta porque aunque no es mucho pienso que al usar el optimistic cache de AdGuard Home debería enviar los antiguos datos que tiene en cache, pero este no lo hace bien
serve-expired, por lo que si el TTL expira y el dominio aún no ha sido resuelto de nuevo, simplemente no lo devuelve desde caché.
además, el usar ese caché que tiene un tiempo alto en algunas apps de banco japoneses estas terminan por no funcionar bien, ya que suelen cambiar de IP frecuentemente, y eso hace que den errores
además, claro, de las actualizaciones que se tienen que hacer para que todo esté bien y al día, o para arreglar cosas que en la versión anterior se habían arruinado
decisión de cambiar a Unbound de forma directa…
Antes no quería cambiar directamente a Unbound, porque pensaba que era imposible usar las listas de bloqueo disponibles, pero eso se puede solucionar fácil con un script que los convierta de:
0.0.0.0 bad-domain.ks
pasaría a ser:
local-zone: "bad-domain.ks." always_null
0.0.0.0 era como decirles “ya hijito, pasa nomás”. ¡No mi ciela! Acá no pe, con always_null se van de patitas pa la calle 🤣.
todo esto haciéndolo con un script que también corre cada cierto tiempo y que se puede programar en cron, con lo que sería lo mismo que tiene AdGuard Home. También se puede poner un whitelist, de modo que, tras cambiar los dominios a bloquear, el whitelist recorra todo el archivo y elimine aquellos que estén permitidos.
También quería algo para poder usar DNS-over-TLS (DoT), y eso también se puede hacer fácilmente en Unbound. En total, los puntos fuertes que tiene AdGuard Home se pueden replicar con un poco de tiempo en Unbound.
vamos a por lo que me cambié a Unbound…
lo principal, como había dicho, era que me molestaba que no usara el cache al terminarse el TTL y esto es muy fácil en Unbound con solo cambiar unas configuraciones:
serve-expired: yes
serve-expired-client-timeout: 0
cachedb) si se quiere mantener la caché persistente entre reinicios. Esto permite mejorar la disponibilidad del DNS incluso después de reiniciar el sistema.
Con estas opciones, Unbound ya puede servir dominios expirados, evitando así la espera. Mientras tanto, resuelve el dominio en segundo plano y lo vuelve a poner en Redis si es que cambió.
;; ANSWER SECTION:
github.com. 58 IN A 140.82.114.3
;; Query time: 0 msec
pero ¿qué pasaría si hay más usuarios o yo misma que piden el mismo dominio y en ese momento se está actualizando, entonces como yo lo pienso eso haría que el siguiente usuario tenga que esperar a que se resuelva el dominio otra vez hipotéticamente pasaría eso, eso, así que para poder hacer que no pase, decidí ponerle un poco de TTL a los dominios expirados que normalmente el más alto que vi al resolver un dominio era de 700ms así que le agregué en la configuración para que le dé 2 segundos de TTL a ese dominio expirado mientras que se toma el tiempo de resolverlo.
serve-expired-ttl-reset: yes para que las respuestas con TTL reconfigurado no mantengan el TTL original (expirado), sino el nuevo TTL que tú defines, como los 2 segundos en este caso.
;; ANSWER SECTION:
github.com. 2 IN A 140.82.112.3
;; Query time: 0 msec
podría ponerle 1 pero mejor darle 2 para no tener problemas por si alguno demora más.
con todo esto ya todo de momento me está yendo mejor y las aplicaciones que me fallaban ya no lo hacen y todo va muy bien.
13 de Julio de 2025
Este update no era el que tenía pensado hacer, pero me ha sorprendido lo bien que la IA puede manejar todas estas cosas con tanta naturalidad que da miedo. Hacer un audio tipo podcast sobre el post me ha parecido algo muy guay, y con solo unos clics y presionar un botón, ¡listo!
15 de Julio de 2025
Tengo un dispositivo de Google que por defecto usa el DNS de Google (8.8.8.8). Si lo bloqueo desde el router, simplemente se queda sin internet y deja de funcionar. Investigando un poco, vi que entrando por SSH al router podía usar iptables para redirigir todo el tráfico DNS hacia mi servidor con Unbound:
iptables -t nat -A PREROUTING -p udp --dport 53 -d 8.8.8.8 -j DNAT --to-destination 192.168.50.156:53
Y sí, funciona… pero solo por un tiempo, porque el router, al no estar pensado para este tipo de cambios, termina volviendo a su configuración por defecto después de reiniciar o pasar un rato. La única forma de hacer estos cambios permanentes sería usando el firmware Merlin, pero justo mi modelo de router es uno de los pocos que no está soportado por Merlin 😩.
Así que por ahora me toca aguantar que ese dispositivo insista en resolver todo solo con el DNS de Google, hasta que por fin pueda tener mi tan anhelado router PC, y ser más libre con estas cosas. ¡Ya falta poco!
18 de Agosto de 2025
Hoy necesité desbloquear un dominio, más bien un subdominio, para que funcionara correctamente una app, pero me encontré con la ingrata sorpresa de que mi script que desbloquea los dominios —es decir, elimina del blocklist las entradas que pongo en mi whitelist— no funciona como quiero. Lo primero es que, si agrego el subdominio que quiero desbloquear, lo hace, pero si el dominio principal está bloqueado, entonces el subdominio también lo estará. Por ejemplo, si en mi whitelist tengo cdn.badddomain.com, el script lo busca y lo elimina del blocklist; pero si la lista de bloqueo incluye badddomain.com, aunque no aparezca cdn.badddomain.com en la lista de bloqueo, igual seguirá bloqueado porque el dominio principal lo arrastra junto con todos los demás subdominios.
Según parece, no hay forma con los always_null de arreglar eso, ya que la única manera sería quitar el dominio principal (desbloquear badddomain.com), y eso no me sirve porque dejaría accesible justo lo que quiero mantener bloqueado. La salida es usar transparent. Así que ajusté el script para que convierta los dominios de la whitelist en transparent y elimine del blocklist cualquier entrada redundante, creando además un archivo de configuración adicional llamado whitelist.conf que contiene lo siguiente:
local-zone: "cdn.badddomain.com." transparent
De esta forma se desbloquea el subdominio, pero se mantiene bloqueado el dominio principal, con un resultado más claro como este:
local-zone: “badddomain.com.” always_null
local-zone: “cdn.badddomain.com.” transparent
Es decir, el dominio principal sigue bloqueado con always_null, mientras que el subdominio puede resolver normalmente gracias a transparent.
