Cada vez que su servidor necesita encontrar un nombre de dominio, envía una solicitud de DNS a otro solucionador de DNS. Si solicita el mismo dominio una y otra vez, esas solicitudes repetidas aún tienen que viajar a través de la red, aunque la respuesta no cambie.
Por ejemplo, supongamos que una aplicación web se conecta a tres API externas cada vez que alguien visita su sitio web. Si su servidor maneja miles de solicitudes por día, eventualmente realizará la misma búsqueda de DNS miles de veces.
Este es un tráfico de red innecesario y agrega un poco de latencia a cada solicitud. Los solucionadores de DNS de almacenamiento en caché local resuelven este problema almacenando registros DNS usados recientemente y reutilizándolos hasta que caduquen. En Rocky Linux 10, puedes configurar uno usando Unbound en unos diez minutos.
no obligado es un solucionador de DNS recursivo, ligero y verificado, impulsado por NLnetLab. a diferencia de vinculante o DNS fuerteno está diseñado para alojar zonas DNS. Su trabajo principal es analizar consultas DNS, almacenar en caché los resultados en la memoria y devolver la respuesta almacenada en caché inmediatamente cuando se vuelve a solicitar el mismo dominio.
Los pasos de esta guía también se aplican a LokiLinux 10, sombrero rojo 10y AlmaLinux 10. Las tres distribuciones proporcionan los mismos paquetes desagregados a través de dnfutiliza el mismo archivo de configuración y se comporta casi de manera idéntica después de instalar y ejecutar el servicio.
Boletín semanal de TechMint
Conseguir Aprenda el curso intensivo de 7 días de Linux Únase a más de 34.000 profesionales de Linux que leen gratis todos los jueves.
Configuración del laboratorio
Para esta guía usaremos dos LokiLinux 10 sistema.
- servidor DNS:192.168.1.50(
resolver.tecmintlocal.com). - máquina cliente: 192.168.1.75 (
app01.tecmintlocal.com).
este sistema de nombres de dominio El servidor se ejecutará no obligadoy el cliente lo usará sistema de nombres de dominio Encontrar.
Antes de instalar cualquier cosa, asegúrese de que su servidor DNS tenga el nombre de host y la dirección IP estática correctos. Dado que el cliente siempre se conectará a este servidor para consultas DNS, su dirección IP debe permanecer sin cambios. Si se produce un cambio, los clientes no podrán acceder al solucionador hasta que se actualice su configuración de DNS.
Ejecute los siguientes comandos en el servidor DNS para verificar su nombre de host y dirección IP:
hostnamectl ip -4 addr show
Deberías ver el nombre de host del servidor configurado en resolver.tecmintlocal.com y la interfaz de red a la que está asignada la dirección IP 192.168.1.50. Si su entorno utiliza valores diferentes, simplemente reemplace los nombres de host y las direcciones IP en esta guía con sus propios valores.
Paso 1: instalar Unbound
Actualice primero el paquete de software del sistema y luego instálelo no obligado junto con bind-utils embalar.
sudo dnf update -y sudo dnf install -y unbound bind-utils
este bind-utils El paquete incluye comando minerouna de las herramientas más útiles para probar DNS. Usaremos esto más tarde para verificar. no obligado Analiza correctamente las consultas y ofrece resultados almacenados en caché.
Antes de realizar cualquier cambio, es una buena idea hacer una copia de seguridad de la configuración preestablecida. no obligado Perfil. Si accidentalmente comete un error al editar una configuración, puede restaurar rápidamente los archivos originales sin reinstalar el paquete.
sudo cp /etc/unbound/unbound.conf /etc/unbound/unbound.conf.orig
Si esto te ayuda, ¿Quién sigue resolviendo problemas de latencia de DNS sin un solucionador local?
Paso 2: Configurar Unbound
Abierto no obligado Abra el perfil en su editor de texto preferido.
sudo vi /etc/unbound/unbound.conf
adentro server: sección, agregue o actualice las siguientes configuraciones:
server:
interface: 192.168.1.50
interface: 127.0.0.1
port: 53
do-ip4: yes
do-udp: yes
do-tcp: yes
access-control: 127.0.0.0/8 allow
access-control: 192.168.1.0/24 allow
access-control: 0.0.0.0/0 refuse
hide-identity: yes
hide-version: yes
verbosity: 1
logfile: "/var/log/unbound.log"
use-syslog: no
Lo que hacen estas configuraciones es:
interfaceEspecifique la dirección IP donde Unbound escucha las solicitudes de DNS. En este ejemplo, escucha en la IP LAN del servidor (192.168.1.50) y la dirección de loopback local (127.0.0.1), que permite que el propio servidor y otras computadoras de la red local utilicen el analizador.do-ip4,do-udpydo-tcpHabilite IPv4 y permita que Unbound acepte consultas DNS a través de UDP y TCP (protocolos de transporte DNS estándar).access-controlDetermine qué clientes pueden usar su servidor DNS. Aquí, solo en máquinas y dispositivos locales.192.168.1.0/24La red puede enviar consultas DNS.hide-identityyhide-versionEvite que Unbound revele la identidad y el número de versión de alguien cuando realiza una consulta DNS especial. Aunque no son obligatorias, estas opciones proporcionan una pequeña ventaja de seguridad al exponer menos información sobre el servidor.verbosity,logfileyuse-syslogControlar el registro. Establecer detalle en1Proporciona registros de operaciones básicas y los almacena en archivos de registro dedicados para facilitar la resolución de problemas.
notas: En Rocky Linux 10, Unbound admite la autenticación DNSSEC lista para usar. Verifica automáticamente las respuestas DNS firmadas utilizando anclajes de confianza raíz, por lo que en la mayoría de los casos no necesita ninguna configuración DNSSEC adicional.
Configurar reenviadores
Por defecto, no obligado Se pueden realizar búsquedas de DNS totalmente recursivas comunicándose con el servidor DNS raíz. Para muchos entornos, es más sencillo y, a menudo, más rápido reenviar solicitudes a un proveedor de DNS ascendente confiable.
Agregue la siguiente sección al final del perfil:
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 9.9.9.9
En este ejemplo:
1.1.1.1Es el servidor DNS público de Cloudflare.9.9.9.9Es el servidor DNS público de Quad9.
Si el primer servidor no está disponible, no obligado Pruebe automáticamente el siguiente.
Paso 3: resuelva cualquier conflicto del puerto 53
antes de comenzar no obligadoasegúrese de que ningún otro servicio esté usando el puerto 53que es el puerto estándar sistema de nombres de dominio.
existir LokiLinux, systemd-resolved Está habilitado de forma predeterminada y normalmente establece un detector de código auxiliar DNS nativo en 127.0.0.53:53. Si el puerto ya está en uso, no obligado no podrá comenzar.
Para comprobar qué servicio está utilizando el puerto 53, ejecute:
sudo ss -tulpn | grep :53
si ves systemd-resolved puerto de escucha 53solo se desactiva su escucha de código auxiliar DNS. Esto libera el puerto Unbound y al mismo tiempo permite que systemd-resolved continúe procesando otras funciones del sistema.
Cree un perfil con la siguiente configuración:
sudo mkdir -p /etc/systemd/resolved.conf.d echo -e "[Resolve]\nDNSStubListener=no" | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf sudo systemctl restart systemd-resolved
Después de reiniciar el servicio, verifique el puerto 53 nuevamente:
sudo ss -tulpn | grep :53
Si no hay nada escuchando en el puerto 53, no obligado Cuando inicie el servicio en el siguiente paso, podrá vincularse a él.
pista: Si hay otros servicios DNS, como vinculante (named) o dnsmasq El puerto 53 está en uso; detenga o reconfigure el servicio antes de iniciar Unbound. Sólo una aplicación puede escuchar en la misma dirección IP y puerto a la vez.
Paso 4: verificar y comenzar a desvincular
Antes de iniciar el servicio, verifique el archivo de configuración para detectar errores de sintaxis. Esto le ayudará a detectar cualquier error antes de que Unbound intente cargar la configuración.
sudo unbound-checkconf
Si la configuración es válida, el comando devuelve:
unbound-checkconf: no errors in /etc/unbound/unbound.conf
Si ve algún mensaje de error, no obligado Por lo general, esto le indica el número de línea donde ocurrió el problema. Abra el archivo de configuración, corrija los errores y ejecute el comando nuevamente hasta que ya no se informen errores.
Una vez verificada la configuración, inicie el servicio Unbound y deje que se inicie automáticamente cuando se inicie el sistema:
sudo systemctl enable --now unbound
A continuación, verifique que el servicio se esté ejecutando:
sudo systemctl status unbound
Si todo está bien, deberías ver el servicio en active (running) estado.
● unbound.service - Unbound DNS server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled)
Active: active (running) since ...
Si el servicio no se inicia, verifique la salida de estado para ver si hay mensajes de error. También puede consultar los archivos de registro configurados previamente o ver los registros del sistema para obtener más detalles:
sudo journalctl -u unbound --no-pager
Paso 5: permitir el tráfico DNS a través del firewall
Si firewalld está habilitado, debe permitir el tráfico DNS entrante para que otros sistemas en la red puedan usar el servidor Unbound.
Ejecute el siguiente comando:
sudo firewall-cmd --add-service=dns --permanent sudo firewall-cmd --reload
Para verificar que la regla se agregó exitosamente, ejecute:
sudo firewall-cmd --list-services
Si todo está configurado correctamente, deberías ver dns Listado con cualquier otro servicio que se haya permitido, como:
cockpit dhcpv6-client dns ssh
En este punto, su firewall está configurado para aceptar solicitudes de DNS de clientes permitidos por la configuración independiente.
Paso 6: Verifique que la caché DNS esté funcionando correctamente
Ahora es el momento de confirmar no obligado En realidad almacena en caché las respuestas DNS. Desde el servidor DNS, use el siguiente comando para consultar el dominio dig y apúntelo directamente a su servidor Unbound:
dig tecmint.com @192.168.1.50
Buscando Query time campos en la salida. La primera búsqueda suele tardar más porque no obligado Se debe contactar a un servidor DNS ascendente para resolver el dominio.
Por ejemplo:
;; Query time: 68 msec ;; SERVER: 192.168.1.50#53(192.168.1.50)
Ahora ejecuta el mismo comando nuevamente:
dig tecmint.com @192.168.1.50
Esta vez, la respuesta debería ser mucho más rápida porque Unbound puede devolver la respuesta desde su caché en lugar de realizar otra búsqueda de DNS externa.
Por ejemplo:
;; Query time: 0 msec ;; SERVER: 192.168.1.50#53(192.168.1.50)
El tiempo de búsqueda exacto variará según su red y los servidores DNS ascendentes, pero la segunda búsqueda debería ser significativamente más rápida que la primera. Cuando se entregan respuestas desde la caché local, los tiempos de consulta de 0 ms o 1 ms son comunes.
También puedes probar usando un dominio diferente, por ejemplo:
dig google.com @192.168.1.50 dig github.com @192.168.1.50
Ejecute cada comando dos veces y compare los tiempos de consulta. La primera búsqueda recupera el registro DNS del solucionador ascendente, mientras que la segunda búsqueda generalmente se realiza directamente desde la caché de Unbound, lo que indica que la caché DNS está funcionando como se esperaba.
Paso 7: configurar el cliente para utilizar un servidor DNS independiente
Una vez que el servidor DNS esté en funcionamiento, el paso final es configurar las computadoras cliente para usarlo para búsquedas de DNS.
Si estas usando administrador de redconfigura tu no obligado servidor (192.168.1.50) como servidor DNS preferido para conexiones de red.
Primero, enumere las conexiones de red disponibles:
nmcli connection show
Tenga en cuenta el nombre del enlace activo (por ejemplo, «Conexión por cable 1«), luego ejecute:
sudo nmcli connection modify "Wired connection 1" ipv4.dns "192.168.1.50" sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes sudo nmcli connection up "Wired connection 1"
Estos comandos configuran el cliente para usar su no obligado El servidor realiza la resolución DNS, en lugar del servidor DNS proporcionado automáticamente por el enrutador o el servidor DHCP.
Muestra el contenido de /etc/resolv.conf:
cat /etc/resolv.conf
Debería ver los servidores independientes en la lista, por ejemplo:
nameserver 192.168.1.50
Ahora pruebe la resolución DNS del cliente:
dig google.com
En la salida, busque SERVER sitio. Debería mostrar sus servidores independientes:
;; SERVER: 192.168.1.50#53(192.168.1.50)
También puedes utilizar algunos otros dominios para realizar pruebas:
dig github.com dig tecmint.com
Si la consulta se completa exitosamente y SERVER campo apunta a 192.168.1.50tus clientes ahora están usando no obligado como su solucionador de DNS.
A partir de este momento, la caché de Unbound servirá búsquedas de DNS duplicadas para el mismo dominio siempre que sea posible, reduciendo así los tiempos de búsqueda y minimizando las solicitudes innecesarias a los servidores DNS ascendentes.
Gestión y solución de problemas de Unbound
puñado unbound-control Los comandos cubren la mayor parte del mantenimiento de rutina.
sudo unbound-control statusMuestra el tiempo de actividad, la versión y si el servidor está respondiendo consultas.sudo unbound-control stats_noreset | grep totalMuestra el total de consultas procesadas y el recuento de aciertos de caché sin restablecer los contadores.sudo unbound-control dump_cache > /tmp/dns_cache_backup.txtEscribe la caché completa en un archivo, lo que resulta útil antes de un reinicio planificado.sudo unbound-control lookup tecmint.comMuestra qué reenviador respondió a un dominio específico y si actualmente está almacenado en caché.sudo unbound-control flush tecmint.comElimina un único registro de caché sin tocar nada más.sudo unbound-control flush_zone tecmintlocal.comBorra todos los registros almacenados en caché en una zona específica, lo que resulta útil cuando acaba de cambiar los registros DNS internos y no desea esperar un TTL.
Si los informes de los clientes no resuelven ningún problema, verifique journalctl -u unbound -f En primer lugar, porque la mayoría de los fracasos se deben a access-control La lista no incluye la subred del cliente ni las zonas de reenvío que apuntan a solucionadores ascendentes a los que no se puede acceder desde su red.
advertir: Nunca configurar access-control: 0.0.0.0/0 allow En un servidor con IP pública. Esto convierte a Unbound en un solucionador abierto que cualquier persona en Internet puede aprovechar para realizar ataques de amplificación de DNS a terceros.
en conclusión
Ya has configurado no obligado Como solucionador de DNS de almacenamiento en caché local LokiLinux 10. A partir de este momento, las solicitudes DNS repetidas para el mismo dominio se atenderán directamente desde la caché local en lugar de enviarse al servidor DNS ascendente cada vez.
Esto puede reducir los tiempos de búsqueda de DNS, reducir el tráfico de red innecesario y mejorar la capacidad de respuesta de las aplicaciones que acceden con frecuencia a los mismos servicios externos.
¿Alguna vez ha ejecutado Unbound en un entorno de producción o todavía depende del solucionador de su ISP? Cuéntanos qué te motiva en los comentarios..
Si este artículo fue útil, Con alguien de tu equipo.
