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 redes. 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 tienen sentido cuando el comportamiento DNS deseado y los servidores DNS responsables están definidos con claridad.

¿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.

¿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 ruta de solicitud DNS sitios pequeños y medianos, DNS Protection, redes de invitados/clientes.
Los clientes consultan directamente a servidores DNS internos: El controlador de dominio o servidor DNS resuelve internamente y redirige externamente redes clásicas de Active Directory con Windows DNS como resolutor central.
Los clientes VPN consultan al firewall: El firewall utiliza rutas de solicitud para dominios internos Acceso remoto con una ruta DNS simple 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 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.

¿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
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.

Configurar una DNS Request Route

La ruta define qué servidores DNS se consultan para un dominio o una zona reverse específica.

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:

Iniciar sesión en Sophos Firewall.
Abrir Network.
Seleccionar DNS.
Cambiar a la sección DNS request route.
Añadir una nueva ruta de solicitud DNS.
En Host/domain name, ingresar el dominio interno, por ejemplo, firma.local.
En Target servers, seleccionar el servidor DNS interno o crearlo como host mediante Create.
Guardar.

Después, el firewall consulta al servidor DNS especificado para este dominio.

Sophos Firewall - Añadir ruta de solicitud DNS con servidor DNS interno — Sophos Firewall - Network > DNS > Add DNS request route

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.

Sophos Firewall - Vista general de una ruta de solicitud DNS para avanet.local — Sophos Firewall - Network > DNS > DNS request route

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.

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:

La ruta de solicitud DNS adecuada para el dominio interno.
Una regla de firewall que permita DNS desde el firewall o el cliente al servidor DNS interno.
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.

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.

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

Los cambios de DNS siempre deben verificarse desde la firewall y desde clientes reales.

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 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:

Probar el sistema de destino por IP, por ejemplo, ping, puerto TCP o aplicación.
Alcanzar el servidor DNS por IP.
Resolver nombres a través de la fuente DNS esperada.
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.

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 falta el resultado esperado, conviene revisar paso a paso los logs, el rule matching y el comportamiento de las policies.

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.
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.

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

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.

Preguntas frecuentes

¿Cuándo se necesita una ruta de solicitud DNS en Sophos Firewall?

Una ruta de solicitud DNS es útil cuando ciertos dominios o zonas inversas no deben resolverse a través de los servidores DNS globales del firewall, sino a través de servidores DNS internos. Casos típicos son Active Directory, aplicaciones internas, VPN y conexión de sitios.

¿Reemplaza una ruta de solicitud DNS las opciones DHCP-DNS?

No. Una ruta de solicitud DNS controla la redirección de ciertas consultas DNS. Las opciones DHCP distribuyen servidores DNS o dominios de búsqueda a los clientes. Dependiendo del diseño, ambas funciones se combinan.

¿Por qué no funciona DNS a través de VPN aunque exista la ruta de solicitud?

Entonces, es posible que el cliente VPN no esté usando la fuente DNS esperada, no tenga un dominio de búsqueda adecuado, no pueda alcanzar el servidor DNS o esté bloqueado por enrutamiento y reglas del firewall. Primero se debe verificar por separado si el acceso por IP funciona y si la consulta DNS realmente llega al servidor correcto.

¿Se necesitan rutas de solicitud DNS para búsquedas inversas?

Sí, si las consultas PTR para redes internas deben ir a un servidor DNS interno. Para ello, se ingresa la zona in-addr.arpa adecuada como nombre de host/dominio. Sin embargo, la zona debe estar presente en el servidor DNS interno.

¿Se necesitan rutas de solicitud DNS con Sophos DNS Protection?

Sí, si los clientes o el firewall deben resolver dominios internos. DNS Protection no conoce zonas AD locales, dominios de aplicaciones internas y zonas inversas. Estas consultas deben ir a servidores DNS internos mediante rutas de solicitud DNS.

¿Por qué el firewall no ve la consulta DNS?

Generalmente, el cliente no usa Sophos Firewall como servidor DNS. En ese caso, las rutas de solicitud DNS en el firewall no ayudan directamente. Se deben verificar las opciones DHCP, el perfil VPN, las configuraciones DNS manuales del cliente, los reenviadores DNS internos y los resolutores alternativos.