Sophos DNS Protection: planificar y configurar la red

Sophos DNS Protection puede proteger un resolutor DNS central de una sede o conectar directamente dispositivos compatibles mediante Secure DNS. Por tanto, la decisión más importante no es el fabricante del firewall, sino dónde se resuelve el DNS, cómo se mantienen las zonas internas y cómo identifica Sophos la sede.

Vía rápida: En una red de sede administrada, el resolutor local existente suele seguir siendo el servidor DNS de los clientes. Solo reenvía las consultas públicas a las dos direcciones IP de DNS Protection que aparecen en Sophos Fusion (antes Sophos Central). Las zonas internas continúan dirigiéndose a los servidores DNS internos autoritativos. Secure DNS es adecuado para dispositivos individuales administrados y usuarios móviles. Pruebe primero ambas vías con un grupo piloto pequeño y no configure nunca un resolutor público sin protección como tercer servidor alternativo.

Arquitectura objetivo y límites de responsabilidad

La ruta de red consta de cuatro funciones separadas:

1. El cliente envía la consulta al resolutor especificado mediante DHCP, VPN, MDM o una configuración local.
2. Un resolutor local decide entre las zonas internas y los nombres públicos.
3. El firewall, el router y NAT determinan la IP de origen pública y la salida real.
4. DNS Protection asigna la consulta a una Location, aplica su Policy y devuelve la respuesta.

Con Secure DNS, el dispositivo envía la consulta a DNS Protection mediante DNS over HTTPS (DoH). Esta ruta omite el reenviador DNS local. La redirección del puerto 53, la caché local y el Conditional Forwarding no tienen efecto en ella.

Este artículo describe la arquitectura independiente del fabricante y los requisitos para firewalls de terceros. La configuración específica del dispositivo se explica en Configurar Sophos DNS Protection con Sophos Firewall.

Requisitos previos, licencia y funciones

Antes de modificar la red, deben existir la Location prevista y el acceso autorizado a Sophos Fusion. Compruebe de antemano los derechos de licencia: Standalone DNS Protection se incluye con Xstream Protection, mientras que Endpoint DNS Protection requiere Workspace Protection y Secure DNS. Estos dos modelos de implementación utilizan rutas de datos distintas y no deben tratarse como intercambiables.

La Location debe crearse antes de implementar los dispositivos. A continuación, la persona responsable de cada plataforma distribuye los valores del tenant siguiendo la guía del dispositivo correspondiente y configura Windows, macOS o Windows Server según el destino. Los dispositivos Windows administrados se entregan a la persona responsable de la Endpoint DNS Protection Policy, en lugar de mantener perfiles manuales. La instalación, renovación y eliminación de la confianza forman parte del proceso independiente del DNS Protection Root Certificate, no de este procedimiento de configuración.

Elegir Traditional DNS o Secure DNS

Local resolver o Firewall forwarder

Elija esta vía si una sede ya utiliza un router, un firewall, Windows DNS u otro Local resolver. El resolutor local o Firewall forwarder envía las consultas públicas a Sophos mediante Traditional DNS over IPv4. DNS Protection identifica la Location por la dirección IPv4 de origen pública o por el FQDN guardado en la Location.

Sus ventajas son las cachés centrales, una ruta uniforme para muchos tipos de dispositivos y el Conditional Forwarding para zonas internas. Su limitación: detrás de la misma IP de origen pública, DNS Protection identifica la sede, pero no automáticamente a cada usuario o dispositivo. Una dirección de salida cambiante, compartida o incorrecta puede impedir la asignación.

Manual device DNS o Secure DNS

Manual device DNS configura las dos direcciones IP de DNS Protection directamente en el dispositivo. Secure DNS, en cambio, utiliza DoH sobre HTTPS y resulta adecuado para dispositivos administrados, clientes itinerantes y redes en las que no puede modificarse el resolutor local. También protege la ruta del dispositivo fuera de la oficina. Sin embargo, deben tenerse en cuenta expresamente los nombres internos, el DNS dividido de la VPN y las aplicaciones con su propio resolutor. La configuración manual de un dispositivo no equivale a la implementación administrada de Workspace mediante una Endpoint Policy.

Para esta vía, abra o cree la Location prevista, active Secure DNS y seleccione Save. Sophos Fusion generará entonces la DNS over HTTPS URL específica de la sede. Entregue la URL completa o el perfil generado a la persona responsable de Windows, macOS o MDM. En Sophos Endpoint, entregue la Location y el grupo piloto a la persona responsable de la Endpoint Policy para que seleccione esa Location en la Policy. No construya la URL manualmente ni reutilice la de otra Location.

Selección recomendada

• Sede con Active Directory o zonas internas: resolutor local con Conditional Forwarding; solo las consultas públicas se envían a DNS Protection.
• Red sencilla sin zonas internas: DHCP puede distribuir directamente las dos direcciones de DNS Protection, siempre que la Location conozca la IP pública de salida.
• Dispositivos móviles administrados: Secure DNS, complementado con excepciones internas definidas y pruebas de VPN.
• Entorno mixto: utilice en paralelo la ruta de sede y Secure DNS, pero documente qué ruta corresponde a cada clase de dispositivo. La interceptación doble dificulta la resolución de problemas.

Inventario y reglas de red

Antes del cambio, recopile estos valores:

• las dos direcciones IP de DNS Protection de My Products > DNS Protection > Installers en su propio tenant;
• todas las direcciones IPv4 públicas de salida que utilicen realmente el funcionamiento normal, el failover de WAN, SD-WAN, la VPN o los proxies centrales;
• las zonas de búsqueda directa e inversa internas, sus resolutores autoritativos y los sufijos de búsqueda;
• los valores DNS configurados mediante DHCP, VPN o de forma estática en cada red;
• los dispositivos o aplicaciones con DoH, DoT, VPN o un resolutor propio configurado de forma fija;
• el resolutor anterior, el TTL de las opciones de DHCP, las personas responsables, la ventana de mantenimiento y la vía de reversión.

En Installers, haga clic en Copy junto a IP addresses y utilice siempre las dos direcciones mostradas. La descarga Certificate pertenece al proceso de certificados independiente; para que las páginas de bloqueo HTTPS sean visibles, los dispositivos deben confiar en este DNS Protection Root Certificate. No debe confundirse con una CA utilizada por el firewall para la inspección HTTPS.

Para Traditional DNS, ambas direcciones del tenant deben ser accesibles mediante UDP 53 y TCP 53: en modo Forwarder, desde los resolutores locales autorizados; en modo Direct Client, solo desde las subredes de clientes o piloto autorizadas. UDP es el caso habitual; TCP se necesita, entre otros casos, para respuestas grandes o truncadas. DNS Protection es un resolutor basado en IPv4, pero puede resolver registros AAAA y, por tanto, destinos IPv6. Ningún resolutor IPv6 independiente y sin protección debe poder omitir la ruta prevista.

Para Secure DNS, los dispositivos necesitan acceso saliente mediante TCP 443 a los destinos DoH proporcionados por Sophos. Las páginas de bloqueo HTTPS también requieren TCP 443 y acceso a blockpage.dnsprotection.sophos.com. La inspección TLS no debe interrumpir inadvertidamente la conexión; la excepción concreta debe limitarse estrictamente a la ruta de destino de Sophos documentada.

Limite la regla del puerto 53 a las direcciones mostradas en el tenant como destinos y separe los orígenes según el diseño: en modo Forwarder, los resolutores locales previstos; en modo Direct Client, las subredes de clientes o piloto autorizadas. No se requiere ninguna regla de entrada en la WAN. Un proxy DNS intermedio, una redirección DNS del proveedor o un portal cautivo transparente pueden alterar las respuestas y deben detectarse durante el piloto.

Planificar la Location, la salida y la redundancia

Traditional DNS solo funciona cuando la IP de origen pública visible de la consulta coincide con una Location de Sophos Fusion. Las direcciones privadas RFC 1918 no deben utilizarse en esta asignación. Con una salida dinámica, puede emplearse un FQDN de DDNS estable; debe resolver públicamente a la dirección actual. Con CGNAT o una IP compartida con otros clientes, no se garantiza una asignación única, por lo que una IP pública propia es la solución adecuada.

En entornos multi-WAN, inventaríe todas las direcciones de salida posibles y guárdelas en la Location correspondiente. Después, cambie de ruta de forma controlada y pruebe ambas vías. El Policy Routing no debe enviar el DNS por una salida desconocida. Si se solapan IP públicas entre tenants, según Sophos tiene prioridad la asignación que se creó primero.

Sophos proporciona dos direcciones de resolutor. Configúrelas como un par primario/secundario equivalente. Un tercer resolutor público no aporta redundancia, sino una vía de omisión: los resolutores no siempre esperan a que se produzca una interrupción total antes de utilizar servidores alternativos y pueden usar en paralelo el más rápido. La alta disponibilidad real también incluye dos resolutores locales, una distribución redundante mediante DHCP/VPN y una ruta de failover de WAN verificada.

Procedimiento de configuración independiente del fabricante

1. En Sophos Fusion, en My Products > DNS Protection > Network setup, seleccione la rama adecuada para Local resolver, Firewall forwarder, Windows DNS, Manual device DNS o Secure DNS. A continuación, confirme la Location y el método de conexión previstos. Para Traditional DNS, deben conocerse todas las direcciones públicas de salida de producción.
2. Para Traditional DNS, copie en My Products > DNS Protection > Installers las dos direcciones de resolutor de su propio tenant. No utilice valores de ejemplo ni direcciones de otro tenant.
3. Para Secure DNS, cree o edite la Location, active Secure DNS, seleccione Save y copie la DNS over HTTPS URL específica de la sede que se ha generado. Entregue exactamente esa URL o el perfil generado a la persona responsable de Windows, macOS o MDM. La persona responsable de la Sophos Endpoint Policy recibe la Location y el grupo piloto para seleccionar esa Location en la Endpoint Policy.
4. En modo Forwarder, configure las dos direcciones de Sophos como los únicos reenviadores de consultas públicas en el resolutor local o el firewall de terceros: una como Primary DNS server y la otra como Secondary DNS server. Mantenga los Conditional Forwarder o las zonas stub para las zonas internas de búsqueda directa e inversa. Si el producto permite configurar un tercer servidor DNS, no añada un resolutor público externo, ya que el cambio a este omitiría la protección.
5. Separe la regla del firewall de salida según el diseño: en modo Forwarder, permita UDP/TCP 53 únicamente desde los resolutores locales autorizados hacia ambas direcciones de Sophos; en modo Direct Client, únicamente desde las subredes de clientes o piloto autorizadas hacia ambas direcciones. Bloquee el puerto 53 para todos los demás orígenes conforme al diseño de prevención de omisiones documentado.
6. Para Secure DNS, permita TCP 443 únicamente desde los dispositivos autorizados hacia el destino DoH generado y el destino necesario para las páginas de bloqueo. Limite estrictamente las excepciones de la inspección TLS.
7. En modo Forwarder, cambie los ámbitos DHCP y VPN del piloto para que utilicen el resolutor local. En modo Direct Client, distribuya las dos direcciones de Sophos a la subred piloto autorizada. Inventaríe por separado los dispositivos con configuración estática.
8. La persona responsable de Windows, macOS o MDM debe distribuir la URL de Secure DNS generada o el perfil únicamente al grupo piloto. Para Sophos Endpoint, la persona responsable de la Policy selecciona en la Endpoint Policy la Location que se le ha proporcionado y asigna dicha Policy al grupo piloto indicado. Documente la Location, la Policy, el grupo y el método de eliminación.
9. Renueve la caché y los leases existentes de forma controlada y solo en el piloto. Vaciar globalmente la caché genera una carga innecesaria y dificulta la comparación.
10. Restrinja las rutas DNS alternativas solo después de una validación correcta.

Límites de la protección contra omisiones

El DNS clásico puede restringirse permitiendo UDP/TCP 53 saliente únicamente a los resolutores locales autorizados en modo Forwarder o solo a las subredes de clientes o piloto autorizadas en modo Direct Client. Redirigir destinos externos del puerto 53 al resolutor propio puede ser útil para dispositivos difíciles de administrar, pero deben excluirse los servidores DNS internos, las VPN, las redes de invitados y los dispositivos que esperan utilizar resolutores específicos. Si los clientes se pueden administrar, bloquear es más transparente que redirigir.

Este control no abarca DoH en TCP 443, DoT en TCP 853 ni la resolución de nombres dentro de un túnel VPN externo. No bloquee TCP 443 de forma general. Las políticas del navegador, el sistema operativo, MDM y Endpoint deben controlar el Secure DNS no autorizado; el uso conocido de DoT puede tratarse específicamente. Apple Private Relay y otros servicios de privacidad similares también requieren una decisión de diseño independiente.

Si solo los iPhone no pueden acceder a Internet aunque la resolución funcione en otros dispositivos, desactive temporalmente Limit IP Address Tracking para la red afectada y vuelva a realizar la prueba. Aplique este cambio deliberadamente en dispositivos piloto, ya que afecta a una función de privacidad del dispositivo.

La protección contra omisiones termina en el límite administrativo. En una red BYOD o de invitados, una Policy documentada y menos estricta suele ser más fiable que intentar imponer el bloqueo de todos los resolutores cifrados sin administrar los dispositivos.

Piloto, validación y aceptación

Empiece con una VLAN representativa o unos pocos dispositivos. Compruebe, como mínimo, nombres públicos, FQDN internos, búsquedas inversas, VPN, acceso de invitados, failover de WAN y un bloqueo de prueba inofensivo.

Antes del cambio, defina un periodo de observación y criterios inequívocos de reversión. Revierta el piloto si falla la resolución interna o por VPN, aparece una Location o Policy incorrecta, DoH/TLS permanece inestable o se interrumpe un destino empresarial necesario; no amplíe el despliegue mientras quede sin resolver alguno de estos desencadenantes.

nslookup example.com <resolver-ip>
nslookup internal-host.corp.example <resolver-ip>

Con dig instalado:

dig @<resolver-ip> example.com A
dig @<resolver-ip> example.com AAAA
dig @<resolver-ip> internal-host.corp.example
dig +tcp @<resolver-ip> example.com

Sustituya <resolver-ip> por el resolutor local o, si se utiliza directamente, por una dirección del tenant. corp.example es una zona de documentación y debe sustituirse por su propia zona interna. La prueba TCP confirma que no solo funciona UDP.

A continuación, abra en el navegador la URL de prueba copiada en Installers > Check your configuration. El mensaje de bienvenida confirma la ruta de DNS Protection, pero no demuestra por sí solo que la Policy sea correcta. Además, bloquee de forma específica un dominio de prueba inofensivo y compruebe en Sophos Fusion si la consulta, la Location y la Policy aparecen como se esperaba. Los informes no siempre se actualizan en tiempo real; por tanto, no deduzca que existe un error inmediatamente después de una sola consulta.

La aceptación implica que:

• ambos resolutores de Sophos funcionan por separado mediante UDP y TCP;
• las zonas internas de búsqueda directa e inversa permanecen en la red interna;
• la salida esperada se asigna a la Location correcta;
• funcionan tanto el bloqueo como los destinos empresariales permitidos;
• el failover de WAN, la VPN y los clientes compatibles con IPv6 no generan una ruta alternativa;
• el DNS no autorizado por el puerto 53 está bloqueado o redirigido según el diseño;
• los pilotos manuales de Secure DNS para Windows, macOS y MDM utilizan exactamente la URL o el perfil generado, mientras que los pilotos de Sophos Endpoint están asignados a una Policy con la Location prevista; ambos aparecen bajo la Location y la Policy previstas y superan las pruebas en la oficina, en itinerancia, mediante VPN, con dominios internos y durante la eliminación;
• están documentados la supervisión y un procedimiento de reversión probado.

Operación y comprobaciones periódicas

Después del piloto, realice el despliegue por fases según la sede o la VLAN. En cada fase, supervise los errores de DNS, los avisos al soporte técnico, los dominios empresariales bloqueados y la asignación de salida. Migre al final los servidores estáticos y los dispositivos OT/IoT, en una ventana de mantenimiento independiente.

Tras cualquier cambio en WAN, NAT, DHCP, VPN, IPv6 o los resolutores locales, vuelva a comprobar la ruta DNS. Lo mismo se aplica al cambiar de proveedor o utilizar una nueva dirección pública de salida. Compruebe periódicamente que ambos resolutores del tenant siguen configurados, que las zonas internas se resuelven localmente y que ningún servidor DNS adicional omite la protección. Incorpore al proceso operativo las notificaciones del producto en My Environment > Alerts y el estado en My Products > DNS Protection.

Reversión segura o retirada

Para revertir el cambio, desactive primero las reglas nuevas de bloqueo o redirección de DNS. A continuación, siga la rama correspondiente al método de implementación:

• Modo Forwarder: Restaure activamente en el resolutor local los reenviadores anteriores documentados. Después, compruebe la resolución interna y pública.
• Modo Direct Client: Restaure los valores DNS anteriores documentados en DHCP, VPN y los clientes estáticos. Renueve los leases en los dispositivos de prueba y compruebe después la resolución interna y pública.
• Secure DNS: La persona responsable de Windows, macOS o MDM elimina el perfil piloto; la persona responsable de la Sophos Endpoint Policy elimina, en cambio, la asignación del grupo piloto. A continuación, restaure el estado DNS anterior y compruebe que ya no se utiliza la ruta DoH.

Mantenga inicialmente los Conditional Forwarder y la Location de Sophos Fusion, salvo que la propia Location haya causado el incidente.

Resolución de problemas según el síntoma

Los nombres públicos no se resuelven

Pruebe primero de forma explícita las dos direcciones de Sophos mediante UDP y TCP. Después, compruebe la regla de salida, NAT, la ruta y la IP de origen pública visible. Si la IP de origen no está asignada a ninguna Location o entra en conflicto con otro tenant, DNS Protection puede rechazar las consultas. Si utiliza DDNS, compruebe también la resolución pública del FQDN.

Fallan los nombres internos o Active Directory

Compruebe qué resolutor utiliza realmente el cliente. Después, revise los Conditional Forwarder, los servidores autoritativos de destino, las zonas inversas, los sufijos de búsqueda y el DNS dividido de la VPN. Un resolutor de DNS Protection distribuido directamente no conoce las zonas privadas.

Solo fallan las respuestas grandes o algunos dominios

Pruebe TCP 53. Si UDP funciona, pero dig +tcp no, normalmente falta la regla TCP o un producto intermedio descarta la conexión. Si un dominio permitido sigue bloqueado, compruebe también el destino CNAME y la clasificación de seguridad.

Sophos Fusion no muestra ninguna Location o muestra una incorrecta

Determine la salida real, no solo la dirección WAN configurada. SD-WAN, las puertas de enlace NAT centrales, los proxies y el failover pueden cambiar la IP de origen. Después, conceda tiempo suficiente a los informes y compruebe que la prueba utilizó realmente el resolutor previsto, en lugar de DoH del navegador o la VPN.

Para una Location definida mediante FQDN, compruebe también la resolución pública. En un registro DNS de Cloudflare, Proxy status: DNS only debe estar activo; un registro con proxy no devuelve la dirección pública de salida real. Una dirección privada o IPv6 no es válida para una Location. Si el mismo valor público ya está asignado a otro cliente o el FQDN no es válido, corrija la asignación antes de continuar el despliegue.

No aparece la página de bloqueo, pero el bloqueo DNS funciona

Esto no demuestra que el dominio esté permitido. Compruebe el acceso a blockpage.dnsprotection.sophos.com, la confianza en el DNS Protection Root Certificate, Pharming Protection, el proxy o filtro web y la inspección TLS. Si el firewall descifra la ruta de la página de bloqueo, utilice la acción estrictamente limitada Do not decrypt para la ruta de destino de Sophos documentada. Gestione siempre la instalación y eliminación del certificado mediante el proceso de la plataforma responsable.

Un dominio permitido sigue bloqueado

Compruebe primero el nombre de destino CNAME y su categoría: un dominio de origen permitido puede apuntar a un nombre que esté bloqueado por su categoría o Threat Score. Después de cambiar una Policy, espere además a que transcurra el TTL de DNS y caduquen las cachés locales, o renuévelas de forma controlada. No acelere el despliegue mediante excepciones generales demasiado amplias.

El bloqueo contra omisiones no funciona

Busque en los registros UDP/TCP 53 saliente, TCP 853 y conexiones conocidas de Secure DNS. Después, revise el navegador, el sistema operativo, la VPN y el software de seguridad local. Un filtro del puerto 53 no puede detectar ni impedir DNS cifrado en el puerto 443.

DNS resuelve, pero no aparecen la Policy ni los informes

Compruebe primero con ipconfig, nslookup o, en Linux y macOS, con dig, qué resolutores utiliza realmente el dispositivo. Después, ejecute una prueba Standard o Extended en https://www.dnsleaktest.com/. Cuando se utiliza DNS Protection, todos los valores de la columna Hostname incluyen el patrón gw-<número>.<región>.dnsprotection.sophos.com; como ISP aparece Amazon o una denominación equivalente. Otros resolutores indican una fuga de DNS o una redirección por parte del ISP.

Si https://dns.access.sophos.com muestra un error del navegador en lugar de la página de bienvenida y, al mismo tiempo, el dashboard muestra No queries received from locations o un Sophos Firewall informa de DNS Protection: Connectivity Error, corrija primero la ruta de resolutor divergente. Revise para ello el DNS del router, DHCP y DHCPv6, las entradas DNS estáticas, la redirección del proveedor y los resolutores IPv6 paralelos. Solo después debe investigar la Policy o los informes; esta comprobación es válida para la ruta de red, no debe aplicarse sin más a Endpoint DoH.

Guías relacionadas

• Configurar Sophos DNS Protection con Sophos Firewall muestra la integración concreta en SFOS.
• Endpoint DNS Protection Policy describe la ruta administrada e independiente de Workspace para endpoints.