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.

Una respuesta local coincidente evita una consulta adicional al DNS autoritativo para esa petición y puede acelerar la resolución. No garantiza un tiempo de respuesta concreto ni ayuda a un cliente cuya consulta no pasa por el resolver del firewall.

Los campos de Host Entry están documentados para SFOS 22.0 y 23.0; esto no demuestra que se hayan probado en un build concreto. SFOS 23 distingue DNS sin cifrar, DNS over HTTPS (DoH) y DNS Protection para la resolución externa. El artículo sobre DNS Request Routes explica la selección global del resolver, la obtención de DNS mediante DHCP/PPPoE y la distinción entre DNS Protection tradicional y la ruta integrada de SFOS 23. No es necesario reconstruir la configuración global para un único nombre local.

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 (SFOS 22) / Test name resolution (SFOS 23).
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. Para el inbound load balancing de un mismo nombre se admiten hasta ocho direcciones; el firewall admite un máximo total de 1024 DNS Host Entries.

Rutas y ámbito de la resolución DNS

Para las consultas que gestiona el propio firewall, se aplican las siguientes configuraciones:

• Si el nombre solicitado coincide con una DNS host entry, el firewall responde con la dirección almacenada en ella.
• Si coincide una DNS request route, el firewall consulta sus Target servers en el orden configurado después de una búsqueda fallida en la caché. Para ese nombre no recurre a los forwarders ni a los servidores raíz.
• Sin una entrada local o una Request Route coincidente, utiliza los servidores definidos en DNS configuration. Los servidores estáticos se consultan en orden hasta recibir una respuesta. NXDOMAIN ya es una respuesta válida, por lo que no se consulta el servidor siguiente.

La ayuda de SFOS 22 describe por separado la coincidencia de Host Entries y Request Routes, pero no especifica el resultado cuando el mismo nombre coincide con ambas. Se debe evitar esta superposición: mantener la Host Entry fuera de una zona reenviada o eliminar la entrada local duplicada. Después, una consulta explícita a la IP del firewall debe confirmar la respuesta prevista.

Estas rutas de resolución solo se aplican cuando el firewall es el resolver de la consulta. Un cliente que utiliza directamente un controlador de dominio, un resolver público o DNS over HTTPS omite estas entradas. Además, en Administration > Device access DNS debe estar permitido para la zona de origen o mediante una Local Service ACL Exception adecuada; una regla de firewall normal no controla el acceso a este servicio local.

Los servidores DNS configurados tienen prioridad sobre los servidores raíz en la resolución DNS general a través de la IP de una interfaz del firewall. Esto no garantiza que toda consulta fallida se resuelva a través de servidores raíz. Las consultas que coinciden con una Request Route permanecen en los Target Servers definidos.

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, en Network > DNS, se usa Test name lookup (SFOS 22) / Test name resolution (SFOS 23) para comprobar si el firewall devuelve la dirección esperada para app01.corp.example. Diagnostics > Tools > Name lookup (SFOS 22) consulta, en cambio, un DNS server IP seleccionado; Lookup using all configured servers compara los servidores DNS configurados y sus tiempos de respuesta. Esta herramienta solo sirve como comparación con los servidores upstream y no demuestra que haya coincidido la Host Entry local o una Request Route. 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.

En SFOS 23, la sección de diagnóstico es DNS lookup, con Hostname or IP address, DNS server IP address y All configured servers. Custom DNS server y Custom DoH server consultan la IP del servidor indicado; DNS Protection solo está disponible si está habilitado en Network > DNS. Para un nombre interno de prueba, seleccionar únicamente un resolver interno autorizado para no exponer el nombre a un servicio DNS o DoH público. Estas opciones de diagnóstico no demuestran que haya coincidido una entrada local; sigue siendo necesaria la consulta explícita desde el cliente descrita a continuación.

Para la prueba de SFOS 23 en Network > DNS > Test name resolution, introducir el FQDN o la dirección en Hostname or IP address y seleccionar Test connection. El resultado muestra el servidor DNS utilizado, el protocolo, el estado de resolución y los tiempos de respuesta; comparar estos datos con la ruta de resolución prevista. La prueba desde el cliente sigue siendo un paso independiente:

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.

Para entregar información al soporte o comparar el estado anterior y posterior al cambio, también se puede descargar dnsd.log en Diagnostics > Tools > Troubleshooting logs. Un Consolidated troubleshooting report (CTR) contiene además datos de estado y registros. Como estos archivos pueden incluir detalles de configuración y del entorno, solo deben compartirse mediante un canal de soporte seguro.

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.

⚠️ No combinar la ponderación y DNAT sin aclarar el diseño: La ayuda de Host Entry describe Weight en relación con WAN link manager, mientras que el flujo Multi-WAN vincula la respuesta a la interfaz WAN de entrada. Además, la ayuda de DNAT prohíbe una regla DNAT junto con weighted load balancing para la misma DNS Host Entry. Estas indicaciones no demuestran una proporción concreta de respuestas DNS ni un diseño DNAT combinado que funcione. Si el servicio público depende de esta combinación, detenerse antes de publicar en WAN y aclarar el diseño concreto para la versión instalada; no suponer que otros pesos constituyen una solución alternativa.

Para dos direcciones WAN, se mantiene el mismo nombre en una única Host Entry: introducir, por ejemplo, www.example.com en Host/Domain name y 192.0.2.10 como primera IP address; después, utilizar Add dentro del formulario para añadir una segunda dirección e introducir 198.51.100.10. Son direcciones de documentación y deben sustituirse por las direcciones WAN reales. Activar Publish on WAN para ambas direcciones previstas solo cuando se cumplan los requisitos del siguiente apartado y guardar con Save. Dos nombres de host distintos no proporcionarían balanceo de carga para el mismo servicio.

En el flujo Multi-WAN documentado, el resolver externo sigue la delegación NS y consulta al firewall a través de un enlace WAN activo. El firewall devuelve la dirección WAN de la interfaz por la que llegó esa consulta, y el resolver transmite dicha dirección al cliente. El acceso posterior a la aplicación es un flujo de datos independiente. Durante la validación, consultar ambas rutas WAN por separado y comparar las direcciones devueltas; tras un fallo de enlace, realizar una nueva consulta DNS. Esto no elimina las respuestas ya almacenadas en caché antes de que expire su TTL.

Weight es el peso relativo del enlace frente a los demás enlaces del WAN link manager. No es un Health Check de la aplicación. Durante la validación, las nuevas consultas DNS externas solo deben devolver direcciones WAN activas; después hay que probar una conexión nueva a la aplicación para cada dirección devuelta. Una respuesta 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.

Según Sophos, una regla DNAT y el weighted load balancing no pueden configurarse simultáneamente para la misma DNS Host Entry. Por tanto, 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.

Un nombre permanece en caché como localhost durante demasiado tiempo

Para los dominios que resuelven a localhost, Sophos Firewall no utiliza simplemente la TTL del registro DNS. El firewall vuelve a consultar estos nombres según el intervalo localhost-ttl. El valor predeterminado es de 655360 segundos y el rango permitido va de 60 a 655360 segundos. Por tanto, cuando un registro cambia de localhost a otro host, el firewall puede conservar la respuesta antigua durante más tiempo que un cliente normal.

Primero se confirma mediante una consulta directa al resolver autoritativo o previsto que el registro ya no apunta a localhost. Después se lee el valor actual de SFOS en la Device Console:

show dns

⚠️ Antes de cambiar el intervalo, guardar el valor inicial leído con show dns y mantener disponible un acceso de gestión independiente. El cambio es global, no se limita a esta Host Entry. Un valor menor genera consultas DNS más frecuentes y no vacía la caché de inmediato.

Solo si se ha demostrado exactamente este caso debe reducirse temporalmente el intervalo global. Los 300 segundos son aquí un ejemplo para una prueba de migración controlada, no una recomendación general:

set dns localhost-ttl 300

Tras el cambio, comprobar show dns y volver a probar la resolución desde el firewall y desde un cliente real. Restaurar el valor predeterminado del producto de esta forma solo si ya se utilizaba antes:

set dns localhost-ttl default

Si el intervalo anterior estaba personalizado, utilizar en su lugar set dns localhost-ttl <previous-seconds> y sustituir <previous-seconds> por el número guardado; no introducir literalmente el marcador. Después, verificar el valor restaurado con show dns y la resolución mediante una nueva consulta. Si se desconoce el valor inicial, default no es una reversión comprobada.

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.

API XML: nombre del objeto y nombre DNS a partir de SFOS 23

En la automatización, Name y HostName son campos distintos: Name identifica el objeto configurado y HostName, el nombre DNS que debe resolverse. La documentación de SFOS 23 exige ambos campos al crear y editar. Name es un único STRING con un máximo de 64 caracteres; se permite UTF-8, pero no las comas. HostName sigue siendo DOMAINNAMELOOKUP con un máximo de 253 caracteres. Por ejemplo, Name = app01-intern y HostName = app01.corp.example pueden tener valores distintos; esto es una correspondencia de campos, no XML ejecutable.

Para la eliminación, SFOS 22 documenta HostName como clave, mientras que SFOS 23 documenta Name. Por tanto, no repetir sin cambios las solicitudes antiguas de SFOS 22 ni utilizar automáticamente el nombre DNS como nombre del objeto. Antes de una llamada de eliminación, comprobar la versión instalada, leer el objeto concreto y comparar el nombre del objeto, el nombre DNS, las direcciones y las dependencias con el destino documentado. Si la identidad no es inequívoca, detenerse. Después, comprobar la respuesta de la API junto con su estado y volver a leer el destino exacto: solo debe faltar el objeto previsto; las demás entradas deben permanecer sin cambios. El éxito del transporte por sí solo no demuestra que la eliminación se haya realizado correctamente. Aquí no se proporciona ningún sobre de solicitud de eliminación ni se afirma haber probado el producto.

Conflicto pendiente sobre DNS inverso: en ambas versiones, el ejemplo de la API muestra Enable/Disable para AddReverseDNSLookUp, pero la tabla de parámetros solo permite Enable y, al mismo tiempo, indica Disable como valor predeterminado. Esto no permite deducir una solicitud segura con Disable ni con omisión del campo. Hasta que el fabricante lo aclare, no utilizar una receta de API de este tipo; configurar en su lugar Reverse DNS de forma consciente mediante el procedimiento de WebAdmin descrito más arriba y comprobar el PTR por separado. Las instrucciones de la interfaz no confirman la semántica de los valores enumerados de la API.

También se aplican los siguientes límites documentados a la validación de campos XML en SFOS 22 y 23; no garantizan los valores predeterminados de WebAdmin:

• Como máximo ocho elementos Address por AddressList. IPFamily, EntryType, IPAddress, TTL, Weight y PublishOnWAN se documentan como obligatorios para Add/Edit; sus valores en la tabla son arrays y los duplicados no se ignoran.
• IPFamily: IPv4 o IPv6; EntryType: Manual o InterfaceIP. Para InterfaceIP, el ejemplo XML espera el nombre de la interfaz en IPAddress, no una dirección IP fija.
• IPAddress es STRING; la tabla excluye las clases MULTICAST, RESERVED, UNSPECIFIED, BROADCAST y LINKLOCAL. Por tanto, no copiar las direcciones de documentación de este artículo en una llamada API de producción sin validarlas.
• TTL es INTEGER de 1 a 604800 segundos, con un máximo de seis cifras; la tabla indica 3600 como valor predeterminado. Aun así, establecer expresamente este campo obligatorio. Weight es INTEGER de 0 a 255, con un máximo de tres cifras; este límite no demuestra un efecto concreto para el peso 0.
• PublishOnWAN permite Enable o Disable. Estos valores inequívocos no deben aplicarse por analogía a la definición contradictoria de AddReverseDNSLookUp descrita más arriba.

Las tablas de estado distinguen Add, Edit y Delete, pero no explican todos los códigos de error enumerados. Ante un error, guardar la respuesta API completa y el estado actual del objeto antes de repetir una llamada que lo modifique; no deducir el éxito ni una causa solo del transporte HTTP.

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