Un resolver para tus dispositivos, no un amplificador abierto.

Elige el rol

Un resolutor recursivo como Unbound y una interfaz de filtrado como AdGuard Home resuelven problemas relacionados pero distintos. Decide si el servicio resuelve por sí mismo o reenvía a un servidor ascendente y comprende qué parte ve entonces las consultas.

Mantenlo privado

Un resolutor público sin restricciones puede ser abusado para ataques de reflexión. Vincúlelo a una red privada o permita solo fuentes autorizadas, incluido IPv6. Si utiliza DNS cifrado, autentique o restrinja el acceso de forma adecuada en lugar de suponer que HTTPS lo hace privado.

Establece una política de registro

Las consultas DNS pueden revelar actividad sensible de navegación y de aplicaciones. Desactive la retención innecesaria, proteja los registros que conserve y explique el alcance a los usuarios. El transporte cifrado protege una ruta; no impide que el propio resolutor vea las consultas.

Prueba más de un nombre

Verifica el comportamiento de DNSSEC cuando esté habilitado, los resultados de IPv4 y IPv6, las excepciones de filtrado y la recuperación cuando falla un servidor ascendente. Mantén una forma segura de corregir el acceso sin depender exclusivamente del resolutor que estás reparando.

Demuestra que desconocidos no pueden consultarla

Vincula el resolutor a la interfaz prevista, define los rangos de clientes permitidos y restringe el firewall. Valida la configuración antes de reiniciar. Consúltalo desde un cliente autorizado y luego repite desde fuera de la red de confianza: esa solicitud debería rechazarse o agotar el tiempo de espera. Comprueba IPv6 por separado. Un resolutor que acepta consultas arbitrarias de internet puede convertirse en una fuente de abuso.

• Ejecuta el validador de configuración antes de aplicar cambios
• Pruebe un cliente permitido y un cliente denegado
• Mantén temporalmente los diagnósticos detallados de consultas

unbound-checkconf

Documentación oficial: Configuración de control de acceso sin restricciones

Mantener precisas las afirmaciones sobre DNS cifrado

DNS-sobre-HTTPS o DNS-sobre-TLS cifra una ruta de transporte concreta. El resolutor sigue recibiendo la consulta, y un resolutor de reenvío puede pasarla a otro operador. Revise la elección del upstream y la retención. Si expone un endpoint de resolutor cifrado, haga su política de acceso tan deliberada como la del puerto DNS ordinario.

Elige la cadena de resolución antes de abrir un puerto

Un diseño privado útil es un cliente VPN que consulta AdGuard Home, con AdGuard reenviando a Unbound en loopback. Unbound realiza entonces la recursión; AdGuard añade filtrado y una interfaz de gestión. Como alternativa, usa solo Unbound para una pila más pequeña. Asigna a cada listener una dirección y un puerto distintos y traza la dirección de reenvío: enviar Unbound de vuelta a AdGuard crea un bucle. Decide qué clientes privados pueden usar el servicio antes de publicar nada.

• Mantén cerrados los puertos TCP y UDP de entrada públicos 53 salvo que exista una política específica de clientes autorizados.
• Asigna reglas de acceso separadas a la interfaz de filtrado y al listener de DNS.
• Comprueba la propiedad del puerto antes de la instalación; un resolutor del sistema existente puede estar ya ocupando la dirección prevista.

Documentación oficial: Configuración de AdGuard Home

Un punto de partida de Unbound en loopback

En un sistema con Unbound ya instalado, el siguiente fragmento ilustra un backend accesible solo en el host. Intégralo con la configuración de la distribución en lugar de sobrescribir los ajustes del paquete o la gestión de trust-anchors. El puerto alto permite que otro frontend DNS use el puerto 53. Valida el archivo efectivo completo y luego recarga mediante el gestor de servicios instalado. Un cliente remoto necesita un túnel o frontend controlado por separado; este fragmento intencionadamente no crea ningún resolver público.

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

Documentación oficial: Referencia de configuración de Unbound

Ejecuta una lista de verificación de aceptación desde dos redes

Primero consulta el backend localmente y después la ruta normal del cliente. Comprueba los registros A/AAAA ordinarios, un nombre deliberadamente inexistente y la validación DNSSEC usando un dominio de prueba documentado. Repite desde una máquina fuera de la subred permitida: no debe recibir recursión. Revisa si un navegador usa su propio resolutor cifrado y omite el DNS configurado del dispositivo. Mantén disponible un resolutor independiente temporal durante el cambio para que un error de DNS no elimine tu ruta de administración.

• Diagnóstico local: dig @127.0.0.1 -p 5335 example.org A
• Inspecciona la accesibilidad tanto por UDP como por TCP, además de los listeners de IPv6.
• Confirma las excepciones de filtrado y registra solo los diagnósticos realmente necesarios.

Diagnostica tiempos de espera, bucles y fallos de validación

Un tiempo de espera agotado en el frontend con un backend local que funciona sugiere la dirección del frontend, el firewall o el destino de reenvío. Las consultas repetidas autoiniciadas sugieren un bucle. Las fallas generalizadas de DNSSEC pueden implicar una hora del sistema incorrecta o el mantenimiento de los anclajes de confianza; corrige la causa en lugar de dejar la validación deshabilitada. Si solo fallan las respuestas grandes, investiga el fallback TCP y la ruta de red. Mantén el registro de consultas de forma temporal y prueba un reinicio y una restauración de la configuración antes de convertir el resolutor en una dependencia para todos los dispositivos.