Configurar rutas de solicitudes DNS en Sophos Firewall

Una DNS Request Route reenvía las consultas de un dominio o una zona inversa determinados a los servidores DNS seleccionados. Un caso habitual es ad.example.com: el firewall resuelve los nombres públicos mediante sus resolvers habituales, pero envía las consultas de esta zona interna a los controladores de dominio.

La ruta solo interviene si Sophos Firewall procesa la consulta como servidor DNS. Si un cliente consulta directamente al servidor DNS interno, el reenvío depende de ese servidor, no de la Request Route del firewall.

La zona de destino no tiene por qué ser interna: una Request Route también puede dirigir las consultas de determinados dominios públicos a un resolver DNS de la propia red. Esto resulta útil si ese resolver se encarga deliberadamente de dichos dominios. El procesamiento local puede reducir las consultas DNS externas; sin embargo, una mejora concreta de la velocidad o una mayor confidencialidad solo se obtienen si el resolver de destino procesa las consultas de la forma adecuada y no se limita a reenviarlas sin cambios a Internet.

Determinar la ruta DNS antes del cambio

Hay tres configuraciones que pueden parecer similares, pero cumplen funciones distintas:

• El cliente consulta al firewall: DHCP o el perfil de VPN proporciona la dirección IP de la interfaz del firewall como servidor DNS. Para acceder al servicio DNS local, la zona del cliente debe tener permitido DNS en Administration > Device access > Local service ACL. Las reglas de firewall convencionales no controlan este acceso al propio firewall.
• El cliente consulta directamente a un servidor DNS interno: el resolver DNS interno responde por las zonas locales y reenvía las demás consultas. Si el tráfico atraviesa zonas diferentes, puede ser necesaria una regla de firewall convencional; este recorrido del cliente no utiliza ninguna Request Route del firewall.
• El firewall consulta a un servidor de destino interno: una Request Route selecciona el servidor de destino en función del dominio consultado. El enrutamiento y la conectividad con ese servidor deben ser correctos.

En cambio, una DNS Host Entry responde directamente en el firewall por un único nombre. Para unos pocos registros estáticos, consulte Configurar entradas de host DNS en Sophos Firewall. Una Request Route resulta más adecuada para una zona completa administrada en un servidor DNS. Las opciones de DHCP, por su parte, determinan qué servidor DNS y qué dominio de búsqueda recibe el cliente; consulte Configurar opciones DHCP en Sophos Firewall.

⚠️ La Request Route se selecciona por el nombre de dominio, no por la red de origen del cliente. Si distintas sedes necesitan respuestas diferentes, deben proporcionarlas los resolvers implicados o rutas DNS independientes. Una sola ruta no crea una vista DNS que dependa del origen.

Ejemplo y requisitos previos

En este ejemplo, una zona interna de AD se reenvía a dos resolvers DNS:

• zona interna: ad.example.com
• servidor de destino principal: 10.10.10.10
• segundo servidor de destino: 10.10.10.11
• red de clientes: 10.20.30.0/24
• dirección IP del firewall como resolver DNS del cliente: 10.20.30.1
• prueba positiva: dc01.ad.example.com
• prueba negativa: example.net

example.com y example.net son dominios reservados para documentación. En producción, sustituya la zona y las direcciones de los servidores y de la interfaz por sus propios valores. Los dos servidores de destino deben ser autoritativos para la misma zona y contener la misma versión de sus datos. Una lista extensa de resolvers distintos no constituye una redundancia bien diseñada.

Antes de crear la ruta, compruebe lo siguiente:

1. El firewall está configurado como resolver DNS en Network > DNS > DNS configuration.
2. Los servidores de destino son accesibles por la ruta local o de VPN prevista.
3. Los clientes a los que debe aplicarse la ruta utilizan realmente la dirección IP del firewall como servidor DNS.
4. En Administration > Device access, DNS solo está habilitado para las zonas de cliente necesarias. Si no debe acceder toda la zona, conviene utilizar una Local Service ACL Exception más restrictiva.
5. La zona interna existe en los servidores de destino y contiene un registro conocido para las pruebas.
6. La ruta DNS anterior y las Request Routes existentes están documentadas para poder revertir el cambio.

Crear la DNS Request Route

1. Abra Network > DNS en WebAdmin.
2. Vaya a la sección DNS request route.
3. Seleccione Add.
4. Introduzca ad.example.com en Host/Domain name.
5. En Target servers, seleccione 10.10.10.10 y 10.10.10.11. Si los objetos de servidor no existen, créelos como IP Hosts mediante Create.
6. Compruebe el orden: SFOS consulta los hosts seleccionados en el orden indicado.
7. Guarde la configuración con Save.

Sophos admite como máximo ocho direcciones IP de destino por Request Route. Añadir servidores solo mejora la disponibilidad si todos responden correctamente por la misma zona y son accesibles mediante rutas independientes que funcionen realmente.

Cuando coincide una Request Route y el firewall no encuentra una respuesta adecuada en la caché, SFOS envía la consulta a sus Target Servers. Para ese dominio no recurre a los reenviadores globales ni a los servidores raíz. Por tanto, si todos los servidores de destino están inaccesibles o no están configurados correctamente para la zona, la resolución falla en vez de utilizar inadvertidamente un resolver DNS público.

A continuación, la nueva entrada debe aparecer en DNS request route con el dominio y los servidores de destino esperados.

Evaluar correctamente varios servidores de destino

El orden documentado es un mecanismo de disponibilidad, no una forma de conciliar datos DNS contradictorios. En el caso de los resolvers estáticos globales, SFOS considera NXDOMAIN una respuesta válida y no consulta después al servidor siguiente. La ayuda de SFOS 22 no confirma expresamente este comportamiento para los servidores de destino de una Request Route. Por ello, no se debe confiar en un segundo servidor con un contenido de zona diferente ni prometer una conmutación por error concreta después de NXDOMAIN.

Durante la validación, consulte por separado cada servidor de destino desde un sistema de pruebas autorizado. Ambos deben responder de igual forma a la prueba positiva; un nombre creado deliberadamente para no existir también debe producir el mismo resultado en los dos servidores. Así se detectan errores de replicación o de autoridad de la zona antes de que el firewall tenga que cambiar de servidor.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

Estas consultas directas comprueban los datos de la zona y la respuesta del servidor, no la Request Route. Ejecútelas únicamente desde una red que, según el diseño DNS, tenga permiso para acceder a ambos resolvers. Después, una consulta a través de 10.20.30.1 confirma que el firewall también reenvía la zona a los servidores previstos.

Reenviar búsquedas inversas

Para las consultas PTR, introduzca la zona inversa, y no una red, en Host/Domain name. Para 172.16.16.0/24, la zona inversa IPv4 convencional es:

16.16.172.in-addr.arpa

Para 172.16.0.0/16, es:

16.172.in-addr.arpa

Una notación CIDR como 172.16.16.0/24 no debe introducirse en el campo del dominio. Lo determinante es la zona configurada realmente en el servidor DNS interno. La Request Route no crea registros PTR; si faltan la zona o los registros en el servidor de destino, la consulta inversa seguirá fallando. Las redes IPv4 que no coinciden con límites de octeto y las zonas inversas IPv6 requieren un diseño de delegación DNS específico; no se deben improvisar invirtiendo sin más el prefijo.

El DNS inverso permite que los registros y servicios asocien una dirección con un nombre. Sin embargo, no corrige un fallo de resolución directa de un FQDN, por lo que debe probarse por separado.

Comprender la ruta del resolver global

En Network > DNS > DNS configuration se define cómo resuelve el firewall las consultas para las que no coinciden ni una Host Entry ni una Request Route. Según la interfaz, SFOS puede obtener resolvers mediante Obtain DNS from DHCP u Obtain DNS from PPPoE. Con Static DNS, se establecen expresamente DNS 1, DNS 2 y, de forma opcional, DNS 3.

⚠️ Si Obtain DNS from DHCP está activo y se deshabilita la última interfaz DHCP coincidente, o se cambia a otro modo de asignación, SFOS pasa a Static DNS. Al volver a habilitar la interfaz, la opción anterior no se restaura automáticamente. Por eso debe comprobarse la selección DNS después de modificar la WAN o las interfaces.

Con Static DNS, el firewall consulta los servidores en el orden configurado. Pasa al servidor siguiente si se agota el tiempo de espera, pero no después de una respuesta NXDOMAIN válida. Las respuestas permanecen en la caché conforme a su TTL. Por tanto, un segundo resolver aporta redundancia de conectividad, no una versión alternativa de la información DNS.

Para los servidores DNS globales, SFOS 22 documenta cuatro opciones de selección. Las dos opciones de prioridad fija requieren que estén configurados servidores DNS tanto IPv4 como IPv6:

• Choose a server based on incoming requests record type selecciona el servidor DNS según el tipo de registro solicitado, A o AAAA.
• Choose IPv6 DNS server over IPv4 da prioridad al servidor DNS IPv6 sobre el servidor DNS IPv4.
• Choose IPv4 DNS server over IPv6 da prioridad al servidor DNS IPv4 sobre el servidor DNS IPv6.
• Choose IPv6 if request originator address is IPv6, else IPv4 utiliza el servidor DNS IPv6 para una consulta procedente de una dirección de origen IPv6 y el servidor DNS IPv4 para una consulta procedente de una dirección de origen IPv4.

El tipo de registro y la familia de la dirección de origen son criterios distintos: una consulta AAAA no es automáticamente una consulta procedente de una dirección de origen IPv6. Por tanto, la selección se realiza según la ruta de resolución prevista, no solo según la dirección deseada en la respuesta DNS. Los resolvers seleccionados deben ser accesibles mediante la familia de direcciones correspondiente. Estas opciones globales no modifican la selección por dominio de los Target servers de una Request Route.

Después de pulsar Apply, Test name lookup comprueba un nombre de host o una dirección IP desde la perspectiva del firewall. Un nombre interno de prueba puede utilizar una Request Route coincidente. Sin embargo, esta prueba no confirma qué resolver está configurado en el cliente ni cuál es su ruta DNS real.

Si WebAdmin no está disponible durante una recuperación planificada, la CLI interactiva muestra los servidores DNS globales IPv4 e IPv6 en 1. Network Configuration > DNS Configuration. Esta opción de menú no modifica las Request Routes. Antes de introducir nada, guarde todos los valores mostrados; si pulsa Enter sin especificar un valor nuevo, se omite el cambio. Para realizar cambios remotos, mantenga disponible una vía de administración independiente.

Combinar DNS Protection con zonas internas

Elegir primero la versión: a partir de SFOS 23.0, utilizar la ruta DoH integrada con DNS Protection en Network > DNS y la asignación de la Filtering Policy al objeto firewall. El artículo sobre DNS Protection enlazado más abajo describe la configuración, la decisión sobre el fallback, el piloto y la reversión. La siguiente secuencia de Location/DDNS y Static DNS se aplica exclusivamente a Traditional DNS en SFOS 22 y versiones anteriores; no ejecutarla además de la ruta integrada de SFOS 23. Las Request Routes internas y las comprobaciones de la ruta del cliente y de NAT siguen siendo relevantes.

Al utilizar Sophos DNS Protection con Sophos Firewall, las consultas públicas se envían a DNS Protection y las Request Routes dirigen las zonas internas a resolvers locales. Primero se registra el firewall como Location en Sophos Fusion (antes Sophos Central). Si hay varias direcciones WAN públicas, deben registrarse todas las direcciones utilizadas o el intervalo correspondiente; si la dirección WAN es dinámica, se utiliza el nombre de host DDNS registrado.

La configuración oficial de Sophos establece las dos direcciones de DNS Protection como DNS 1 y DNS 2 en Network > DNS > DNS configuration, deja DNS 3 vacío, elimina los servidores DNS IPv6 y selecciona Choose IPv4 DNS server over IPv6. Un tercer resolver o un resolver IPv6 no previsto puede hacer que las consultas eludan DNS Protection.

Para DHCP, Sophos especifica una ruta particular: en Network > DHCP > Server > Edit, Use device’s DNS settings debe permanecer deshabilitado. En Primary DNS se introduce la dirección IP del firewall en la interfaz DHCP y, en Secondary DNS, una dirección pública de DNS Protection. Como los clientes pueden utilizar varios resolvers de formas distintas, es necesario comprobar que las consultas internas pasen realmente por el firewall. Las consultas que un cliente envía directamente a DNS Protection no utilizan las Request Routes locales del firewall.

Sophos también describe una regla DNAT que redirige las consultas DNS salientes convencionales de las redes internas a la dirección IP interna del firewall. Esta redirección es una decisión de seguridad independiente: no captura automáticamente DNS over HTTPS ni DNS over TLS y puede afectar a dispositivos especiales. Solo debe implantarse con redes de origen claramente definidas, sin utilizar la WAN como Inbound Interface y con un plan documentado de excepciones y reversión.

Probar el firewall y el cliente por separado

Perspectiva del resolver del firewall

En Network > DNS > Test name lookup, compruebe sucesivamente dc01.ad.example.com y example.net. El nombre interno debe devolver la dirección interna esperada y el nombre público debe seguir resolviéndose por la ruta predeterminada prevista.

En 4. Device Console puede obtenerse la misma perspectiva con el comando documentado oficialmente:

dnslookup host dc01.ad.example.com
dnslookup host example.net

Estas pruebas muestran la perspectiva del resolver DNS del firewall. Aún no demuestran que un cliente consulte al firewall.

Comparar resolvers individuales en Diagnostics

En Diagnostics > Tools, SFOS 22 ofrece Name lookup con los campos IP address or hostname y DNS server IP. Un FQDN comprueba la resolución directa; una dirección IPv4 o IPv6, la resolución inversa. Seleccione un servidor configurado concreto o utilice Lookup using all configured servers para comparar las respuestas y los tiempos de respuesta de todos los resolvers configurados. Un tiempo de respuesta corto no justifica por sí solo cambiar el orden de los servidores; primero, las respuestas deben ser adecuadas para la zona prevista.

En SFOS 23, la sección se llama DNS lookup y los campos son Hostname or IP address y DNS server IP address. Además de un servidor disponible y All configured servers, se ofrecen Custom DNS server y Custom DoH server; en ambos casos se introduce la dirección IP del servidor deseado. DNS Protection solo puede seleccionarse si DNS Protection está habilitado en Network > DNS. Se trata de una opción de diagnóstico, no de una indicación para modificar la configuración DNS existente con el fin de realizar una prueba.

Para los nombres internos de prueba, utilice únicamente resolvers internos autorizados, de modo que los nombres no lleguen a un servicio DNS o DoH público. Una consulta dirigida a un resolver concreto confirma su respuesta, no la ruta real de la Request Route ni la del cliente. Por tanto, sigue siendo necesario validar el funcionamiento mediante consultas a la dirección IP del firewall y Packet Capture.

Comprobar la ruta del cliente

En un cliente de prueba, compruebe primero el servidor DNS configurado y, a continuación, consulte de forma explícita la dirección IP del firewall, 10.20.30.1.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS o Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Repita después las mismas consultas sin especificar un servidor. Si los resultados difieren, el cliente utiliza otra ruta de resolución, como una configuración estática, un perfil de VPN, DNS over HTTPS o un agente de seguridad local. El dominio de búsqueda solo es relevante para nombres cortos sin cualificar; los FQDN usados anteriormente no lo necesitan.

Captura de paquetes de la ruta real

En Diagnostics > Packet capture, aplique un filtro al cliente de prueba, los servidores de destino y el puerto 53 para acotar el tráfico. El procedimiento se explica en Captura de paquetes en Sophos Firewall.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Compruebe la consulta entrante del cliente, la consulta que genera el firewall hacia el Target Server correcto y las respuestas correspondientes. La captura de paquetes permite distinguir un problema de acceso del cliente de un problema de enrutamiento o del servidor de destino. Como el búfer de captura es limitado, utilice un filtro restrictivo y active la grabación únicamente durante la prueba.

Si utiliza DNS Protection, complete la comprobación con el enlace oficial Check your configuration de My Products > DNS Protection > Installers. La página de bienvenida confirma la ruta de DNS Protection, pero aun así debe probar por separado la zona interna, la ruta del cliente y la Request Route.

Acotar los errores por síntoma

El firewall resuelve el nombre interno, pero el cliente no

• Compruebe que el cliente utiliza realmente la dirección IP del firewall como servidor DNS.
• En Administration > Device access, verifique que DNS esté permitido para la zona del cliente o mediante una Local Service ACL Exception adecuada.
• Envíe la consulta de forma explícita a la dirección IP del firewall y confírmela mediante una captura de paquetes.
• Revise DHCP, la VPN, la configuración local del resolver DNS y las posibles rutas alternativas, como DoH o DoT.

El firewall no alcanza el Target Server

• Compruebe Route Lookup y la ruta local o de VPN hacia la dirección de destino.
• Verifique el acceso por UDP y TCP al puerto 53 del servidor de destino, así como la ACL del propio servidor.
• Consulte directamente al resolver DNS y compruebe que acepte consultas procedentes de la dirección IP del firewall.
• En la captura de paquetes, busque la consulta generada, su respuesta o el motivo de descarte.

Si los clientes consultan directamente al servidor DNS interno, se aplica la ruta de tránsito convencional entre zonas y su regla de firewall. Para diferenciar ambos casos, consulte Comprobar reglas de firewall con Log Viewer, Policy Test y Packet Capture.

Respuestas incorrectas o cambiantes

• Dominio demasiado amplio o incorrecto: limite la Request Route a la zona que realmente corresponde.
• Los servidores de destino contienen datos distintos: compruebe directamente en cada servidor la replicación DNS y la autoridad de la zona.
• Respuesta antigua: tenga en cuenta el TTL y las cachés del firewall, del resolver DNS y del cliente.
• Solo fallan los nombres cortos: compruebe el dominio de búsqueda del cliente y pruebe el FQDN por separado.
• Falla la búsqueda inversa: compruebe la zona PTR y el registro PTR en el servidor de destino.
• Solo afecta a los clientes VPN: compruebe los servidores DNS asignados, el enrutamiento de la VPN y el acceso al servicio DNS local. Los campos correspondientes del cliente se describen en Configurar Sophos Connect y Configurar el acceso remoto SSL VPN.

API XML: identificar la ruta por el nombre del objeto

A partir de SFOS 23, la documentación de la API XML exige tanto Name como DomainName al crear y editar una DNS Request Route. Name identifica el objeto configurado y DomainName, la zona DNS que debe reenviarse; por ejemplo, Name = ad-intern y DomainName = ad.example.com. Son valores de campos, no XML ejecutable. Name es un único STRING con un máximo de 64 caracteres, permite UTF-8 y no admite comas. DomainName sigue siendo FQDN con un máximo de 255 caracteres; también deben seguir especificándose los servidores de destino.

Para la eliminación, la clave documentada cambia de DomainName en SFOS 22 a Name en SFOS 23. No repetir sin cambios las solicitudes antiguas ni adoptar automáticamente el nombre de dominio como nombre del objeto. Antes, comprobar la versión instalada y leer el objeto concreto, comparar Name, DomainName, Target Servers y las dependencias con el destino previsto y documentar la reversión. Si hay ambigüedad, detenerse. Después, comprobar la respuesta y el estado de la API y volver a leer el destino exacto: solo debe haberse eliminado la ruta prevista; las demás rutas deben permanecer sin cambios. A continuación, probar la resolución interna y pública como se describe más arriba. Aquí no se inventa ningún sobre de solicitud de eliminación ni esquema REST, ni se afirma haber probado el producto.

La configuración global del protocolo DNS es independiente de lo anterior. El artículo sobre DNS Protection explica los conflictos pendientes del esquema XML de SFOS 23 y la ruta segura mediante WebAdmin; las cuatro opciones de resolver descritas más arriba expresamente para SFOS 22 no demuestran ninguna correspondencia numérica en la API de SFOS 23.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Reversión y operación

Antes del cambio, documente las Request Routes existentes, la selección DNS global, los permisos de Device Access y los resultados de una prueba positiva y otra negativa. Para una reversión normal, elimine la ruta recién creada o restablezca exactamente los valores anteriores documentados. Devuelva también a su estado original cualquier excepción de ACL o redirección DNS temporal.

A continuación, vuelva a comprobar tres aspectos:

1. El firewall resuelve un nombre interno y otro público por las rutas previstas.
2. El cliente afectado utiliza el resolver DNS previsto y recibe las respuestas esperadas.
3. Un dominio no afectado no se envía al Target Server interno.

Una copia de seguridad completa de la configuración no es un método práctico para revertir un único objeto: una restauración sustituye toda la configuración y puede sobrescribir cambios posteriores. Para una sola Request Route, revertir el objeto a partir de la documentación es la opción más segura.

Preguntas frecuentes