Configurar y probar DNS Host Entries en Sophos Firewall

Una DNS Host Entry permite que Sophos Firewall responda directamente a un nombre de host concreto con una dirección IP configurada. Es adecuada para unos pocos sistemas internos fijos, como un appliance, un servicio de gestión o un nombre de servidor que el propio firewall debe resolver.

La entrada solo surte efecto si la consulta DNS llega realmente al firewall. Si un cliente utiliza un controlador de dominio, un resolver público o DNS over HTTPS, el firewall no ve esa consulta como resolver DNS. Una DNS Host Entry tampoco sustituye un objeto de regla, el routing, NAT ni una regla de firewall.

⚠️ Publish on WAN permanece desactivado para las entradas internas. La publicación pública requiere un diseño DNS autoritativo deliberado, registros NS adecuados, un Device Access estrictamente limitado y una prueba negativa de recursión. Un permiso DNS ACL desde WAN no es por sí solo un motivo para exponer públicamente el servicio DNS.

DNS Host Entry en ocho pasos

1. Confirmar que el nombre es estático y que no se necesita reenviar una zona DNS interna completa.
2. Comprobar si los clientes afectados utilizan realmente Sophos Firewall como servidor DNS.
3. Documentar el FQDN, la dirección de destino, la versión IP, el TTL y un registro PTR opcional.
4. Introducir el nombre y la dirección en Network > DNS > DNS host entry > Add.
5. Dejar Publish on WAN desactivado para una entrada interna.
6. Comprobar la vista del firewall en Network > DNS > Test name lookup.
7. Consultar explícitamente la IP del firewall desde el cliente y probar la resolución directa y, si se necesita, la inversa.
8. Solo entonces probar la aplicación real y documentar la entrada junto con sus dependencias.

Cuándo es adecuada una DNS Host Entry

Una DNS Host Entry es adecuada para un único nombre estable cuya respuesta se mantiene directamente en el firewall. Algunos ejemplos habituales son:

• un appliance interno sin registro DNS propio;
• un FQDN de gestión fijo para LDAP, RADIUS u otro servicio;
• un único nombre de host para una migración controlada;
• un servicio público con inbound DNS load balancing planificado conscientemente sobre varias direcciones WAN.

Para un dominio completo, Active Directory o zonas internas mantenidas dinámicamente, una DNS Request Route es una solución más limpia. Reenvía la zona al servidor DNS responsable en lugar de mantener cada nombre por separado en el firewall.

Un IP Host o FQDN Host también cumple otra función. Estos objetos se utilizan en reglas de firewall y NAT, pero no responden a una consulta DNS de un cliente. Utilizar correctamente IP Hosts, Services y Groups explica los tipos de objetos.

Una configuración de Dynamic DNS, en cambio, actualiza un nombre en un proveedor externo cuando cambia una dirección WAN. El procedimiento completo está en Configurar Dynamic DNS en Sophos Firewall.

SFOS admite los tipos de registro A, AAAA y PTR para DNS Host Entries. Por tanto, la función no es un servidor DNS autoritativo completo para CNAME, MX, TXT o SRV. Cada DNS Host Entry admite hasta ocho direcciones; el firewall admite un máximo total de 1024 DNS Host Entries.

Ejemplo y valores sustituibles

El ejemplo representa un único servidor de aplicaciones interno:

• Nombre de host: app01.corp.example
• Dirección IPv4: 192.0.2.20
• Red de clientes: 10.20.30.0/24
• IP del firewall como servidor DNS: 10.20.30.1
• Cliente de prueba: 10.20.30.50
• TTL: 300 segundos
• Publish on WAN: desactivado
• Reverse DNS: activado de forma opcional

La zona .example y 192.0.2.0/24 están reservadas para documentación. En un entorno productivo, el FQDN, la dirección, la red de clientes y la IP del resolver se sustituyen por los valores reales. El nombre debe ajustarse a la estrategia de nombres interna y no debe sobrescribir involuntariamente una zona autoritativa existente.

El TTL de 300 segundos es un valor de ejemplo controlado para pruebas y migraciones, no una recomendación universal. Un TTL corto acelera los cambios planificados, pero genera más consultas DNS. Un TTL largo reduce las consultas, pero conserva las respuestas antiguas durante más tiempo en las cachés después de un cambio.

Crear la DNS Host Entry

En Network > DNS, desplazarse hasta DNS host entry y seleccionar Add:

1. Introducir app01.corp.example en Host/Domain name.
2. Utilizar una dirección IP como Entry type.
3. Introducir 192.0.2.20 en IP address.
4. Introducir 300 en Time-to-live.
5. No tratar Weight como herramienta de balanceo de carga cuando solo hay una dirección.
6. Dejar Publish on WAN desactivado.
7. Activar Add reverse DNS lookup for this host entry solo si el firewall también debe devolver una respuesta PTR para esta dirección.
8. Guardar con Save.

Para una dirección IPv4, el firewall devuelve una respuesta A; para una dirección IPv6, una respuesta AAAA. La resolución inversa opcional vuelve a asignar la dirección al nombre como PTR. Sin embargo, no crea un registro PTR en un controlador de dominio ni en un servidor DNS externo.

Si varios nombres de host apuntan a la misma dirección IP, solo uno de ellos puede servir como destino inverso. Antes de activar la opción, debe quedar claro qué nombre se espera como respuesta PTR canónica.

Utilizar una interfaz en lugar de una dirección fija

Como Entry Type se puede seleccionar una interfaz en lugar de una IP fija. Esto es adecuado cuando la respuesta debe seguir de forma deliberada la dirección actual de esa interfaz, por ejemplo en un diseño público Multi-WAN planificado.

Seleccionar una interfaz no sustituye la comprobación de la ruta WAN real. Después de un cambio de dirección, un cambio de enlace o un failover de HA, hay que volver a probar la respuesta DNS, el servicio accesible y la ruta de retorno con una conexión nueva.

Probar la resolución en el firewall y en el cliente

Primero se comprueba en Network > DNS > Test name lookup si el firewall devuelve la dirección esperada para app01.corp.example. Si Reverse DNS está activado, se consulta también 192.0.2.20.

Esta prueba solo confirma la vista del resolver del firewall. A continuación, el cliente afectado debe consultar expresamente la IP del firewall 10.20.30.1.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux o macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

La respuesta debe contener el registro esperado, la dirección correcta y, en la resolución inversa, el nombre previsto. Después se prueba la aplicación mediante el FQDN. Una respuesta DNS correcta todavía no demuestra que funcionen el routing, la regla de firewall, NAT, el certificado TLS y el servicio.

Si no está claro si la consulta llega al firewall, se puede utilizar un filtro estricto en Diagnostics > Packet capture, como:

host 10.20.30.50 and port 53

La consulta y la respuesta deben aparecer en la interfaz esperada. Packet Capture en Sophos Firewall explica en detalle la captura y evaluación seguras.

Utilizar varias direcciones y la ponderación de forma consciente

Una DNS Host Entry puede contener hasta ocho direcciones. Esto está pensado para inbound DNS load balancing o failover mediante varios enlaces WAN, no para una colección aleatoria de servidores internos.

Los valores de Weight determinan la proporción con la que se distribuyen las respuestas entre los enlaces indicados. Este comportamiento debe comprobarse mediante consultas DNS repetidas y conexiones reales a la aplicación. La distribución de respuestas DNS no confirma por sí sola ni la disponibilidad del servicio publicado ni una ruta DNAT y de retorno correcta.

Varias direcciones no se convierten automáticamente en un Health Check general de las aplicaciones internas. En un diseño público, Sophos documenta el failover para una interfaz inaccesible o caída. Esto no garantiza que una interfaz WAN accesible también entregue correctamente el servicio de aplicación que se encuentra detrás.

Weighted DNS y la configuración DNAT generada por Server Access Assistant no deben planificarse al mismo tiempo como un mecanismo conjunto para la misma DNS Host Entry. La publicación necesita un diseño coherente de respuesta DNS, dirección WAN, DNAT, regla de firewall, TLS y ruta de retorno. Publicar un servidor mediante DNAT explica por separado la ruta de datos.

Utilizar Publish on WAN solo en diseños autoritativos

Publish on WAN por sí solo no basta para una respuesta pública. Para que Sophos Firewall responda como Name Server de un servicio publicado, la zona autoritativa debe delegarse en nombres de servidores DNS cuyos registros A/AAAA o glue apunten a las direcciones WAN previstas.

También se necesitan los siguientes puntos:

1. El dominio público y la zona DNS responsable están documentados de forma inequívoca.
2. La delegación NS y los registros de dirección o glue asociados conducen a las direcciones WAN previstas.
3. En Administration > Device access, DNS solo está permitido a través de la zona WAN necesaria o de una Local Service ACL Exception estricta.
4. Publish on WAN solo está activado en las direcciones previstas.
5. El nombre publicado se prueba correctamente desde un resolver externo.
6. Los nombres no autoritativos y las consultas recursivas se prueban negativamente desde el exterior.
7. DNAT, la regla de firewall, el certificado y la ruta de retorno del servicio real se validan por separado.

Una excepción DNS ACL adicional no restringe un permiso amplio de zona WAN que ya esté activo. O bien DNS permanece desactivado para WAN en la matriz y se permite mediante una excepción específica, o bien el permiso más amplio se documenta como una exposición deliberada. Device Access y Local Service ACL explica cómo gestionar esta capa sin provocar un bloqueo administrativo.

Si la delegación, el alcance de las respuestas o la protección frente al uso recursivo no pueden comprobarse claramente, Publish on WAN no se activa. Para zonas DNS públicas normales, un servicio DNS autoritativo dedicado suele ser la solución más clara.

Delimitar errores por síntoma

El firewall resuelve, pero el cliente no

• Comprobar qué servidor DNS está configurado realmente en el cliente. DHCP puede distribuir la IP del firewall; el procedimiento está en Configurar DHCP Server en Sophos Firewall.
• Comprobar DNS over HTTPS, la configuración del cliente VPN y los resolvers estáticos del cliente como rutas alternativas.
• En Administration > Device access, comprobar si DNS está permitido desde la zona del cliente.
• Utilizar Packet Capture para confirmar si la consulta y la respuesta pasan por el firewall.
• No cambiar el routing ni NAT mientras el cliente ni siquiera esté consultando al firewall.

El cliente sigue recibiendo la dirección antigua

• Comprobar la entrada actual en busca de errores tipográficos, nombres de host duplicados y varias direcciones.
• Tener en cuenta el antiguo TTL todavía válido y las cachés locales, del navegador o de la aplicación.
• Enviar una nueva consulta explícita a la IP del firewall en lugar de limitarse a recargar la aplicación.
• Antes de una migración planificada, reducir el TTL con suficiente antelación y dejar que expire por completo el TTL anterior.

Vaciar una caché puede limpiar un único cliente de prueba, pero no cambia las respuestas en otros resolvers ni en las cachés de las aplicaciones. Por tanto, no sustituye una espera controlada ni una prueba a través de la cadena DNS realmente utilizada.

Falta la resolución inversa o muestra un nombre incorrecto

• Comprobar si Add reverse DNS lookup for this host entry está activado.
• Asegurarse de que varios nombres no reclamen la misma dirección como destino PTR.
• Enviar la consulta inversa expresamente a la IP del firewall.
• Si una zona inversa interna está alojada en un controlador de dominio, utilizar la DNS Request Route correspondiente en lugar de una entrada PTR local.

La consulta pública no obtiene respuesta

• Comprobar desde el exterior la delegación NS y la accesibilidad de las direcciones WAN.
• Comprobar Publish on WAN en cada dirección prevista.
• Comprobar Device Access, Local Service ACL, los filtros upstream y el puerto 53 UDP y TCP.
• Registrar un Packet Capture durante una única consulta externa concreta.
• No activar un permiso DNS amplio como intento de solución.

DNS es correcto, pero la aplicación sigue sin estar accesible

DNS solo proporciona la dirección de destino. Después vienen el routing, la regla de firewall, NAT, TLS y el servicio real. Por tanto, la prueba debe comprobar sucesivamente la dirección IP, el puerto y el protocolo de aplicación. Para problemas de reglas y rutas, ayuda Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Cambios, HA y rollback

Antes de un cambio se documentan el nombre, la respuesta actual, el TTL, la resolución inversa, los resolvers utilizados por los clientes y los servicios dependientes. Si hay varias direcciones, también se incluyen en el estado inicial la ponderación, la asociación WAN, la delegación NS, DNAT y la ruta de retorno.

En un clúster HA se realiza una nueva consulta DNS después de un failover planificado. En una publicación pública se prueban además ambas rutas WAN y un nuevo flujo de aplicación. Este artículo no presupone cachés DNS sincronizadas ni una conexión activa sin interrupciones.

Para el rollback:

1. Antes de una migración planificada, reducir el TTL y esperar a que expire el TTL anterior.
2. Documentar las aplicaciones dependientes y la ruta DNS pública.
3. Restaurar la dirección, la interfaz o la Host Entry al estado inicial confirmado.
4. Eliminar una excepción temporal de Device Access y la publicación WAN que ya no se necesite.
5. Volver a consultar expresamente desde el firewall y el cliente.
6. Volver a probar la resolución directa, el PTR opcional, la accesibilidad y la aplicación real.

Lista de comprobación

• Sophos Firewall ve la consulta DNS del cliente afectado.
• Un único nombre estático es más adecuado que una DNS Request Route.
• FQDN, versión IP, dirección y TTL están documentados.
• Publish on WAN permanece desactivado para las entradas internas.
• Una entrada PTR solo está activada para el nombre canónico de la dirección.
• El firewall y el cliente devuelven la misma respuesta esperada.
• El acceso DNS está limitado a las fuentes necesarias en Device Access.
• Con varias direcciones se han probado la ponderación, el estado del enlace y la ruta de la aplicación.
• En la publicación WAN están documentadas la delegación NS, las direcciones de los servidores DNS y una prueba negativa de recursión.
• El rollback y el tiempo de espera de la caché se conocen antes del cambio.

Preguntas frecuentes