Configurar rutas de solicitudes DNS en Sophos Firewall

Con rutas de solicitudes DNS, se puede especificar en Sophos Firewall qué servidor DNS debe usarse para ciertos dominios o zonas inversas. Esto es especialmente útil cuando el firewall utiliza servidores DNS públicos, pero los nombres internos deben resolverse a través de un servidor DNS interno.

Ejemplos típicos incluyen dominios de Active Directory, aplicaciones internas, búsquedas inversas o entornos VPN.

Cuando se utiliza Sophos DNS Protection con Sophos Firewall, las rutas de solicitudes DNS se vuelven aún más importantes. Los dominios públicos van al servicio de DNS Protection, pero los dominios internos siguen yendo al servidor DNS local o al controlador de dominio. Sin esta separación, las aplicaciones internas, los inicios de sesión de AD o las búsquedas inversas pueden parecer problemas de red.

Orientación y diseño

Las DNS Request Routes solo funcionan de forma fiable cuando está claro qué resolutor ve qué consulta. Por eso conviene separar primero diseño DNS, DNS del cliente, zonas internas y ruta de enrutamiento.

¿Ruta de solicitud DNS, servidor DNS o opción DHCP?

Las rutas de solicitudes DNS a menudo se confunden con servidores DNS globales u opciones DHCP. Las funciones resuelven diferentes problemas.

• Servidores DNS globales: Resolución estándar del firewall DNS de Internet, resolución general de FQDN, actualizaciones y servicios en la nube.
• Ruta de solicitud DNS: enviar un dominio específico o zona inversa a un servidor DNS definido Active Directory, dominios internos, DNS de ubicación, DNS dividido.
• Opción DHCP: distribuir servidores DNS o dominios de búsqueda a clientes Los clientes deben usar directamente un servidor DNS específico.

Una ruta de solicitud DNS no cambia automáticamente la configuración DNS de todos los clientes. La ruta controla a dónde la propia Sophos Firewall o los clientes que usan el firewall como reenviador DNS redirigen ciertas consultas DNS. Si los clientes deben usar directamente un servidor DNS interno, es más adecuada una opción DHCP en Sophos Firewall.

También es importante la diferencia con una DNS Host Entry: una DNS Host Entry responde directamente a un nombre de host concreto con una dirección IP en el firewall. Una DNS Request Route, en cambio, reenvía un dominio o zona a otro servidor DNS. Para Active Directory y zonas internas dinámicas, una Request Route casi siempre es más limpia que muchas Host Entries individuales.

¿Qué diseño DNS es adecuado?

Antes de crear una ruta de solicitud DNS, debe estar claro qué resolutor se utiliza en cada red. La ruta solo ayuda si Sophos Firewall también ve la consulta.

• Los clientes consultan a Sophos Firewall: El firewall redirige los dominios públicos globalmente y los dominios internos mediante DNS Request Route. Esto encaja en sedes pequeñas y medianas, DNS Protection y redes de invitados o clientes.
• Los clientes consultan directamente a servidores DNS internos: Los controladores de dominio o servidores DNS resuelven internamente y reenvían externamente. Esto encaja en redes Active Directory clásicas con Windows DNS como resolver central.
• Los clientes VPN consultan al firewall: El firewall utiliza Request Routes para dominios internos. Esto encaja en Remote Access con una ruta DNS sencilla a través del firewall.
• Los clientes VPN consultan directamente a servidores DNS internos: DNS pasa por VPN al controlador de dominio o servidor DNS. Esto encaja en entornos AD más grandes cuando los clientes deben usar la misma lógica DNS que en la LAN.

En entornos mixtos, un esquema DNS breve es muy útil: red de clientes, servidor DNS asignado, dominio de búsqueda, zonas DNS internas, rutas de solicitud DNS y ruta de enrutamiento al servidor de destino. Sin esta visión general, a menudo se trabaja en la ruta de solicitud más tarde, aunque el cliente no use el firewall como resolutor DNS.

Para que las DNS Request Routes afecten a los clientes, Sophos Firewall debe estar en la ruta de consulta DNS. Esto puede ser directo, si los clientes reciben la IP de interfaz del firewall como servidor DNS, o indirecto, si un resolutor interno reenvía conscientemente al firewall. Si los clientes consultan directamente a un controlador de dominio, el firewall no ve esta consulta DNS como resolutor y no puede redirigirla mediante una Request Route.

¿Cuándo se necesitan rutas de solicitudes DNS?

Las rutas de solicitudes DNS son útiles cuando:

• se deben resolver nombres de host internos como server01.firma.local
• las búsquedas inversas para redes IP internas deben funcionar
• los usuarios de VPN deben usar nombres internos
• múltiples ubicaciones tienen sus propias zonas DNS
• el propio firewall debe alcanzar sistemas internos mediante FQDN
• los servidores DNS públicos no conocen nombres internos

Sin una ruta de solicitud DNS, el firewall consulta al servidor DNS configurado globalmente. Si el dominio interno no es conocido allí, la resolución falla.

Esta diferencia es especialmente importante en el acceso remoto. Si los clientes VPN usan el firewall como servidor DNS, una ruta de solicitud DNS puede asegurar que los dominios internos lleguen al controlador de dominio o servidor DNS correcto. Si los clientes VPN reciben directamente servidores DNS internos, también se debe verificar si el enrutamiento, las reglas del firewall y los sufijos DNS en el cliente son correctos.

Requisitos

• Acceso al WebAdmin de Sophos Firewall
• Sophos Firewall está configurado correctamente como resolver DNS o reenviador DNS en Network > DNS > DNS configuration
• El servidor DNS interno es accesible
• El dominio o red es conocido
• Las reglas del firewall permiten el tráfico DNS al servidor de destino
• En la conexión de sitio a sitio: el enrutamiento al servidor DNS funciona
• El cliente afectado usa el firewall como servidor DNS o recibe intencionadamente otro servidor DNS

⚠️ Los problemas de DNS a menudo parecen problemas de enrutamiento, VPN o aplicaciones. Antes de realizar cambios importantes, se debe verificar si el servidor de destino es accesible por IP y si solo falla la resolución de nombres.

En Network > DNS > DNS configuration también se debe comprobar cómo resuelve el firewall sus consultas DNS normales. Si se utiliza DNS Protection, allí figuran las direcciones IP de DNS Protection. Si se usan forwarders clásicos o resolutores internos, esos servidores deben ser accesibles. Con Test name lookup se puede comprobar directamente en la configuración DNS si el firewall puede resolver en principio un nombre o una IP.

Configurar una DNS Request Route

La configuración es técnicamente sencilla, pero se vuelve rápidamente confusa cuando se combinan dominios, zonas inversas, clientes VPN y varias sedes.

Crear una ruta de solicitud DNS para un dominio

Una ruta de dominio asegura que las consultas para un dominio específico se envíen a un servidor DNS definido.

Ejemplo:

• Nombre de host/dominio: firma.local
• Servidor DNS: 10.10.10.10

Procedimiento:

1. Iniciar sesión en Sophos Firewall.
2. Abrir Network > DNS.
3. Cambiar a la sección DNS request route.
4. Seleccionar Add.
5. En Host/domain name, introducir el dominio interno, por ejemplo firma.local.
6. En Target servers, seleccionar el servidor DNS interno o crearlo como host mediante Create.
7. Guardar.

El valor en Host/domain name debe escribirse como un FQDN o nombre de zona, no como una URL, una regla wildcard ni una descripción libre. La API de Sophos trata este valor como un campo FQDN con una longitud máxima de 255 caracteres. Para rutas de dominio normales basta, por ejemplo, firma.local; para búsquedas inversas se usa la zona in-addr.arpa correspondiente.

Si falta un acierto de caché DNS en el firewall, la consulta correspondiente para este dominio no se envía a los forwarders normales ni a los root servers, sino a los Target Servers de la Request Route. Esto es intencionado: las zonas internas no deben consultarse accidentalmente fuera. Pero también significa que un Target Server mal elegido puede responder limpiamente la consulta y aun así ser funcionalmente incorrecto.

Usar varios servidores de destino

En Target servers, se pueden añadir más de un servidor DNS. Esto es útil si hay varios servidores DNS internos o si el DNS debe ser accesible de manera redundante a través de una conexión de sitio.

Posibles servidores de destino:

• Servidores DNS internos en la red local
• Servidores DNS al otro lado de una conexión VPN
• Servidores DNS en otra ubicación
• Servidores DNS públicos, si se desea resolver externamente un dominio específico

El orden es relevante. El firewall consulta a los hosts seleccionados en el orden en que aparecen en la lista. Se pueden registrar hasta ocho direcciones IP por ruta de solicitud DNS. Sin embargo, más servidores de destino no significan automáticamente mejor redundancia si los servidores tienen diferentes estados de zona, diferentes redirecciones o diferente accesibilidad a través de VPN.

Con varios servidores de destino, no solo se debe registrar la redundancia, sino también verificar la responsabilidad. Si el primer servidor DNS conoce la zona pero proporciona entradas obsoletas, la ruta de solicitud funcionará técnicamente pero dará respuestas incorrectas desde el punto de vista funcional.

Un NXDOMAIN es una respuesta DNS válida. Si el primer servidor DNS accesible dice que un nombre no existe, el firewall no pregunta automáticamente al siguiente servidor esperando otra respuesta. Por eso, los Target Servers para la misma DNS Request Route deberían tener el mismo estado de zona y los mismos reenvíos.

DNS dividido para VPN y ubicaciones

DNS dividido significa que el mismo nombre se resuelve de manera diferente según la ubicación o la red. Un portal interno puede, por ejemplo, apuntar a una IP privada internamente, mientras que el mismo nombre externamente apunta a una dirección pública o no se resuelve en absoluto.

En Sophos Firewall, tres puntos son cruciales:

1. La ruta de solicitud DNS adecuada para el dominio interno.
2. Una regla de firewall que permita DNS desde el firewall o el cliente al servidor DNS interno.
3. Una ruta de enrutamiento al servidor DNS, especialmente en VPN de sitio a sitio, SSL VPN o Sophos Connect.

Para entornos de acceso remoto, también se debe verificar qué servidores DNS y dominios de búsqueda recibe el cliente. Para Sophos Connect, consulte Configurar Sophos Connect en Sophos Firewall. Para configuraciones clásicas de SSL VPN, consulte Configurar acceso remoto SSL VPN en Sophos Firewall.

Con DNS Protection se añade una pregunta de diseño adicional: Sophos recomienda configurar los dispositivos de red para que usen el firewall como resolutor DNS. Para ello, normalmente se distribuye en los servidores DHCP del firewall la IP de interfaz del firewall como servidor DNS. Si aun así los dispositivos usan resolutores externos, puede planificarse una regla NAT dirigida para tráfico DNS saliente hacia el firewall. Esto debe hacerse de forma consciente y no global, porque las redirecciones DNS duras pueden afectar la resolución de problemas, dispositivos BYOD, DoH/DoT y dispositivos especiales.

Si el propio firewall utiliza DNS Protection como reenviador, las direcciones IP de DNS Protection copiadas desde Sophos Central deben introducirse en Network > DNS > DNS configuration como servidor DNS primario y secundario. Un tercer servidor DNS diferente o una ruta DNS IPv6 no deseada puede hacer que las solicitudes eludan DNS Protection. Por eso, DNS Request Routes, opciones DNS de DHCP, ajustes DNS IPv6 y reglas NAT DNS opcionales deben revisarse como un diseño común.

DNS inverso para redes internas

Una ruta de solicitud DNS inversa redirige las consultas PTR para una red IP interna al servidor DNS que conoce la zona de búsqueda inversa adecuada. Esto es útil cuando los registros, informes o servicios deben convertir una dirección IP nuevamente en un nombre de host.

Ejemplo:

• Red: 172.16.16.0/24
• Servidor DNS: 172.16.16.10
• Zona inversa: 16.16.172.in-addr.arpa

Para búsquedas inversas, también se crea una ruta de solicitud DNS en Network > DNS > DNS request route. En Host/domain name, no se ingresa el dominio normal, sino la zona inversa.

Ejemplo para 172.16.16.0/24:

16.16.172.in-addr.arpa

El orden de los octetos está invertido. Por lo tanto, de la red 172.16.16.0/24 se convierte en 16.16.172.in-addr.arpa. Importante: en Host/domain name no se introduce una notación CIDR como 172.16.16.0/24, sino una zona DNS. Por tanto, el valor debe parecer un nombre de dominio o de zona inversa, no una descripción libre.

Para redes más grandes, la zona inversa puede ser más amplia. Ejemplo: Para 172.16.0.0/16 sería 16.172.in-addr.arpa. Lo importante es cómo se configuró la zona de búsqueda inversa en el servidor DNS interno.

Si en el servidor DNS interno no existe una zona PTR o registros PTR, la ruta de solicitud no ayudará. El firewall solo puede enviar la consulta al servidor DNS correcto, pero no genera entradas DNS inversas en el servidor DNS.

En entornos IPv6 con prefijo del proveedor, también se debe considerar DNS desde el principio. Cómo los clientes obtienen su dirección IPv6 y qué papel juegan el anuncio de enrutador y DHCPv6 se detalla en Configurar delegación de prefijo IPv6 en Sophos Firewall.

Pruebas y operación

Después de la configuración se deben probar por separado la accesibilidad IP, la resolución DNS y el DNS del cliente. Así se identifica más rápido si el problema está realmente en la Request Route.

Pruebas y validación

Después de la configuración, se debe probar la resolución de nombres:

• ¿Puede el firewall resolver el nombre interno?
• ¿Funciona Network > DNS > Test name lookup para un nombre interno y uno público?
• ¿Funciona la resolución desde zonas de VPN o usuarios?
• ¿Es el servidor DNS accesible por ping o TCP/UDP 53?
• ¿Hay entradas en el registro DNS o del firewall?

Si la resolución no funciona, primero se debe verificar:

• ¿Está el dominio escrito correctamente?
• ¿El cliente realmente usa Sophos Firewall o el servidor DNS correcto?
• ¿Una regla del firewall bloquea DNS?
• ¿Falta una ruta al servidor DNS?
• ¿El servidor DNS responde a consultas del firewall?

Una prueba útil separa la accesibilidad IP y la resolución DNS:

1. Probar el sistema de destino por IP, por ejemplo, ping, puerto TCP o aplicación.
2. Alcanzar el servidor DNS por IP.
3. Resolver nombres a través de la fuente DNS esperada.
4. Luego probar la aplicación por el nombre.

Si el acceso por IP funciona, pero por nombre no, el enfoque está en la ruta de solicitud DNS, el sufijo DNS, el DNS del cliente o la búsqueda inversa. Si el acceso por IP ya falla, primero se debe verificar el enrutamiento, la regla del firewall, NAT o VPN. Para esta delimitación, ayudan Probar regla del firewall con Log Viewer, Policy Test y Packet Capture y La regla de Sophos Firewall no coincide: verificar causas.

Comandos de prueba para firewall y clientes

En Sophos Firewall, la consola del dispositivo puede ayudar a probar DNS desde la perspectiva del firewall:

dnslookup server01.firma.local
dnslookup example.com

En los clientes, también se debe verificar qué resolutor realmente se está utilizando.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> representa la dirección de interfaz interna de Sophos Firewall en la red respectiva. Si la consulta contra el firewall funciona, pero la consulta normal del cliente no, el problema generalmente está en DHCP, el perfil VPN, el sufijo DNS, el resolutor local o el comportamiento DNS del navegador/sistema. Si también falla la consulta contra el firewall, los siguientes puntos a verificar son la ruta de solicitud, el servidor de destino, el enrutamiento o la regla del firewall.

En clientes con navegadores modernos o agentes Endpoint, se debe comprobar además si DNS-over-HTTPS o un agente de seguridad local evita la consulta DNS normal. En ese caso, puede que el firewall no vea ninguna solicitud DNS clásica en UDP/TCP 53 aunque la configuración de red parezca correcta.

Definir pruebas positivas y negativas

Una DNS Request Route solo queda correctamente probada cuando no solo resuelve el nombre interno deseado, sino también se comprueba un contraejemplo. De lo contrario, no queda claro si la ruta afecta exactamente a la zona interna o si DNS se redirige demasiado ampliamente.

Normalmente basta un plan de prueba breve:

• Prueba positiva: un nombre interno de la zona objetivo resuelve a la IP privada esperada, por ejemplo server01.ad.firma.local.
• Prueba negativa: un dominio público no afectado sigue usando la ruta predeterminada prevista, por ejemplo DNS global, DNS Protection o un reenviador interno.
• Prueba desde cliente: ejecutar la prueba desde la VLAN, perfil VPN o sede afectada, no solo directamente en el firewall.
• Revisión de logs: firewall log, DNS log o Packet Capture muestran que la consulta llega al resolver esperado.
• Regresión: repetir la misma prueba después de cambios en VPN, DHCP, DNS Protection o routing de la sede.

Esta pequeña prueba negativa evita efectos secundarios típicos: dominios públicos respondidos internamente, DNS Protection omitido, Split-DNS que solo funciona desde algunas redes o un cliente VPN que sigue usando un resolver antiguo.

Verificación operativa

Las rutas de solicitudes DNS deben ser lo más específicas posible. Una ruta para el dominio interno exacto es mejor que una configuración demasiado amplia. Para entornos más grandes, vale la pena tener una pequeña tabla con el dominio, el servidor DNS, la ubicación y el propósito, para que los cambios posteriores sean rastreables.

Documentación práctica:

• Dominio o zona inversa: ad.firma.local
• Servidores de destino: 10.10.10.10, 10.10.10.11
• Propósito: DNS de Active Directory para la ubicación principal.
• Redes afectadas: LAN, VPN de administración, ubicación Zúrich.
• Dependencias: VPN de sitio a sitio, controlador de dominio, regla del firewall DNS.
• Prueba: server01.ad.firma.local se resuelve en la IP interna esperada.
• Prueba negativa: por ejemplo, example.com sigue usando la ruta predeterminada prevista.

Troubleshooting

Si DNS no funciona, no se debe cambiar directamente la Request Route. A menudo el cliente usa otro resolutor, una regla de firewall bloquea DNS o la zona inversa no existe en el servidor de destino.

Errores típicos

• El nombre interno no se resuelve: dominio incorrecto, por ejemplo, firma.local en lugar de ad.firma.local Verificar el dominio en la ruta de solicitud y el dominio de búsqueda del cliente.
• El cliente VPN no resuelve nombres internos: El cliente no usa el firewall o el servidor DNS incorrecto Verificar configuraciones DNS de VPN, DNS del cliente y regla del firewall.
• El firewall no puede alcanzar el servidor DNS: Falta ruta, VPN o regla del firewall Verificar ping, captura de paquetes y búsqueda de rutas.
• El firewall resuelve externamente, pero no internamente: comprobar DNS Request Route, Target Server y Test name lookup. Después usar Packet Capture hacia el servidor DNS interno.
• La búsqueda inversa no funciona: Falta zona PTR o registros PTR Verificar la zona de búsqueda inversa en el servidor DNS interno.
• Ubicaciones individuales dan respuestas incorrectas: Servidor de destino incorrecto o datos de zona obsoletos Verificar el orden de los servidores de destino y la replicación DNS.
• Los nombres públicos se responden repentinamente internamente: La ruta de solicitud es demasiado amplia Usar un dominio más específico y evitar el pensamiento de comodines.
• El primer servidor DNS responde NXDOMAIN: el firewall trata esta respuesta como válida y no consulta automáticamente todos los demás Target Servers. Comprobar estado de zona y orden de servidores.
• DNS Protection no se aplica a todos los clientes: comprobar si los clientes usan realmente el firewall como resolutor DNS o si hay resolutores externos, DoH/DoT, agentes locales o ajustes DNS manuales de por medio.

En entornos VPN, también se debe verificar si los clientes VPN reciben los servidores DNS y dominios de búsqueda correctos.

Preguntas frecuentes