Planifier et configurer le réseau pour Sophos DNS Protection

Sophos DNS Protection peut protéger un résolveur DNS central sur un site ou connecter directement des appareils compatibles via Secure DNS. La décision essentielle ne concerne donc pas le fabricant du pare-feu, mais l’endroit où le DNS est résolu, la manière dont les zones internes restent accessibles et celle dont Sophos identifie le site.

Parcours rapide : dans un réseau de site administré, le résolveur local existant reste normalement le serveur DNS des clients. Il transmet uniquement les requêtes publiques aux deux adresses IP DNS Protection affichées dans Sophos Fusion (anciennement Sophos Central). Les zones internes continuent d’être dirigées vers les serveurs DNS internes faisant autorité. Secure DNS convient aux appareils individuels administrés et aux utilisateurs mobiles. Testez d’abord les deux voies avec un petit groupe pilote et n’ajoutez jamais un résolveur public non protégé comme troisième solution de secours.

Architecture cible et périmètre de responsabilité

Le chemin réseau comporte quatre rôles distincts :

Le client envoie la requête au résolveur défini par DHCP, VPN, MDM ou localement.
Un résolveur local choisit entre les zones internes et les noms publics.
Le pare-feu, le routeur et le NAT déterminent l’adresse IP source publique et la sortie réelle.
DNS Protection associe la requête à une Location, applique sa Policy et renvoie la réponse.

Avec Secure DNS, l’appareil envoie plutôt la requête à DNS Protection par DNS over HTTPS (DoH). Ce chemin contourne le redirecteur DNS local. La redirection du port 53, le cache local et le transfert conditionnel ne s’y appliquent pas.

Cet article décrit l’architecture indépendante du fabricant et les exigences applicables aux pare-feu tiers. La configuration propre à l’appareil est présentée dans Configurer Sophos DNS Protection avec Sophos Firewall.

Prérequis, licence et rôles

Avant toute modification du réseau, la Location prévue et un accès Sophos Fusion autorisé doivent être disponibles. Vérifiez au préalable le droit de licence : DNS Protection autonome est inclus avec Xstream Protection, tandis qu’Endpoint DNS Protection nécessite Workspace Protection et Secure DNS. Ces deux modèles de déploiement utilisent des chemins de données différents et ne doivent pas être considérés comme interchangeables.

La Location doit être créée avant le déploiement des appareils. La personne responsable de chaque plateforme distribue ensuite les valeurs du tenant à l’aide du guide correspondant et configure Windows, macOS ou Windows Server selon la cible. Les appareils Windows administrés sont confiés à la personne responsable de l’Endpoint DNS Protection Policy, au lieu de maintenir des profils manuels. L’installation, le renouvellement et le retrait de la confiance relèvent du processus distinct consacré au DNS Protection Root Certificate, et non de cette procédure de configuration.

Choisir Traditional DNS ou Secure DNS

Local resolver ou Firewall forwarder

Choisissez cette voie lorsqu’un site utilise déjà un routeur, un pare-feu, Windows DNS ou un autre Local resolver. Le résolveur local ou Firewall forwarder transmet les requêtes publiques à Sophos via Traditional DNS over IPv4. DNS Protection identifie la Location au moyen de l’adresse source IPv4 publique ou du FQDN enregistré dans la Location.

Cette solution offre des caches centralisés, un chemin commun à de nombreux types d’appareils et le transfert conditionnel des zones internes. Sa limite : derrière une même adresse IP source publique, DNS Protection voit le site, mais pas automatiquement chaque utilisateur ou appareil. Une adresse de sortie changeante, partagée ou incorrecte peut empêcher l’association.

Manual device DNS ou Secure DNS

Manual device DNS inscrit les deux adresses IP DNS Protection directement sur l’appareil. Secure DNS, en revanche, utilise DoH sur HTTPS et convient aux appareils administrés, aux clients mobiles et aux réseaux où le résolveur local ne peut pas être modifié. Il protège également le chemin de l’appareil hors du bureau. Les noms internes, le split DNS des VPN et les applications dotées de leur propre résolveur doivent toutefois être pris en compte explicitement. Une configuration manuelle de l’appareil n’est pas équivalente au déploiement Workspace administré au moyen d’une Endpoint Policy.

Pour ce chemin, ouvrez ou créez la Location prévue, activez Secure DNS, puis sélectionnez Save. Sophos Fusion génère alors la DNS over HTTPS URL propre à la Location. Transmettez l’URL complète ou le profil généré à la personne responsable de Windows, macOS ou MDM. Pour Sophos Endpoint, la personne responsable de l’Endpoint Policy reçoit la Location et le groupe pilote afin de sélectionner cette Location dans la Policy. Ne composez pas vous-même l’URL et ne réutilisez pas celle d’une autre Location.

Choix recommandés

Site avec Active Directory ou zones internes : résolveur local avec transfert conditionnel ; seules les requêtes publiques sont envoyées à DNS Protection.
Réseau simple sans zones internes : DHCP peut distribuer directement les deux adresses DNS Protection, à condition que la Location connaisse l’adresse IP de sortie publique.
Appareils mobiles administrés : Secure DNS, complété par des exceptions internes définies et des tests VPN.
Environnement mixte : exploitez en parallèle le chemin du site et Secure DNS, mais documentez le chemin de référence pour chaque classe d’appareils. Une double interception complique le dépannage.

État des lieux et accès réseau

Avant toute modification, consignez les éléments suivants :

les deux adresses IP DNS Protection indiquées sous My Products > DNS Protection > Installers dans votre propre tenant ;
toutes les adresses IPv4 de sortie publiques réellement utilisées en fonctionnement normal, lors du basculement WAN, par le SD-WAN, le VPN ou les proxys centraux ;
les zones directes et inverses internes, leurs résolveurs faisant autorité et les suffixes de recherche ;
les valeurs DNS fournies par DHCP et VPN ou configurées statiquement pour chaque réseau ;
les appareils ou applications dotés de leur propre DoH, DoT, VPN ou résolveur fixe ;
le résolveur précédent, la durée de vie des options DHCP, les personnes responsables, la fenêtre de maintenance et le chemin de retour arrière.

Sous Installers, cliquez sur Copy à côté de IP addresses et reprenez toujours les deux adresses affichées. Le téléchargement Certificate relève du processus distinct consacré aux certificats ; pour afficher les pages de blocage HTTPS, ce DNS Protection Root Certificate doit être approuvé sur les appareils. Il ne doit pas être confondu avec une autorité de certification utilisée pour l’inspection HTTPS du pare-feu.

Pour Traditional DNS, les deux adresses du tenant doivent être joignables en UDP 53 et TCP 53 : depuis les résolveurs locaux autorisés en mode redirecteur, ou uniquement depuis les sous-réseaux clients ou pilotes autorisés en mode client direct. UDP est utilisé normalement ; TCP est notamment nécessaire pour les réponses volumineuses ou tronquées. DNS Protection est un résolveur basé sur IPv4, mais il peut résoudre les enregistrements AAAA et donc les destinations IPv6. Aucun résolveur IPv6 distinct et non protégé ne doit contourner le chemin prévu.

Pour Secure DNS, les appareils doivent disposer d’un accès sortant en TCP 443 vers les destinations DoH fournies par Sophos. Les pages de blocage HTTPS nécessitent également TCP 443 et l’accès à blockpage.dnsprotection.sophos.com. L’inspection TLS ne doit pas interrompre la connexion sans que cela soit détecté ; l’exception concernée doit être strictement limitée au chemin de destination Sophos documenté.

Limitez la règle du port 53 aux adresses affichées dans le tenant comme destinations et distinguez les sources selon l’architecture : les résolveurs locaux prévus en mode redirecteur, ou les sous-réseaux clients ou pilotes autorisés en mode client direct. Aucune règle WAN entrante n’est nécessaire. Un proxy DNS en amont, une redirection DNS du fournisseur d’accès ou un portail captif transparent peut modifier les réponses et doit être détecté pendant le pilote.

Planifier la Location, la sortie et la redondance

Traditional DNS ne fonctionne que si l’adresse IP source publique visible de la requête correspond à une Location dans Sophos Fusion. Les adresses privées RFC 1918 ne doivent pas servir à cette association. En cas de sortie dynamique, un FQDN DDNS stable peut être utilisé ; il doit publiquement pointer vers l’adresse actuelle. Avec le CGNAT ou une adresse IP partagée avec d’autres clients, une association unique n’est pas garantie ; une adresse IP publique dédiée constitue la solution appropriée.

Dans un environnement multi-WAN, inventoriez chaque adresse de sortie possible et enregistrez-la dans la Location appropriée. Basculez ensuite de manière contrôlée et testez les deux chemins. Le routage par Policy ne doit pas envoyer le DNS vers une sortie inconnue. Si des adresses IP publiques se chevauchent entre des tenants, Sophos indique que l’association créée en premier est prioritaire.

Sophos fournit deux adresses de résolveur. Configurez-les toutes deux comme une paire primaire/secondaire équivalente. Un troisième résolveur public ne constitue pas une redondance, mais un contournement : les résolveurs ne réservent pas toujours les serveurs de remplacement à une panne complète et peuvent utiliser en parallèle celui qui répond le plus vite. Une véritable résilience comprend également deux résolveurs locaux, une distribution DHCP/VPN redondante et un chemin de basculement WAN testé.

Procédure de configuration indépendante du fabricant

Dans Sophos Fusion, sous My Products > DNS Protection > Network setup, déterminez la branche appropriée parmi Local resolver, Firewall forwarder, Windows DNS, Manual device DNS et Secure DNS. Confirmez ensuite la Location et la méthode de connexion prévues. Pour Traditional DNS, toutes les adresses de sortie publiques de production doivent être connues.
Pour Traditional DNS, copiez les deux adresses de résolveur de votre propre tenant sous My Products > DNS Protection > Installers. N’utilisez aucune valeur d’exemple ni adresse d’un autre tenant.
Pour Secure DNS, créez ou modifiez la Location, activez Secure DNS, sélectionnez Save, puis copiez la DNS over HTTPS URL générée propre au site. Transmettez précisément cette URL ou le profil généré à la personne responsable de Windows, macOS ou MDM. La personne responsable de la Sophos Endpoint Policy reçoit la Location et le groupe pilote afin de sélectionner cette Location dans l’Endpoint Policy.
En mode redirecteur, configurez les deux adresses Sophos comme seuls redirecteurs des requêtes publiques sur le résolveur local ou le pare-feu tiers : l’une comme Primary DNS server, l’autre comme Secondary DNS server. Conservez les redirecteurs conditionnels ou les zones stub des zones directes et inverses internes. Si le produit propose un troisième serveur DNS, n’y ajoutez pas de résolveur public tiers, car son utilisation contournerait la protection.
Distinguez la règle du pare-feu de sortie selon l’architecture : en mode redirecteur, autorisez UDP/TCP 53 uniquement depuis les résolveurs locaux autorisés vers les deux adresses Sophos ; en mode client direct, uniquement depuis les sous-réseaux pilotes ou clients autorisés vers les deux adresses. Bloquez le port 53 pour toutes les autres sources conformément à la conception documentée de la protection contre le contournement.
Pour Secure DNS, autorisez TCP 443 uniquement depuis les appareils autorisés vers la destination DoH générée et la destination requise pour les pages de blocage. Limitez strictement les exceptions à l’inspection TLS.
En mode redirecteur, configurez les étendues DHCP et VPN du pilote pour utiliser le résolveur local. En mode client direct, distribuez les deux adresses Sophos au sous-réseau pilote autorisé. Inventoriez séparément les appareils configurés de manière statique.
Faites déployer l’URL ou le profil Secure DNS généré uniquement au groupe pilote par la personne responsable de Windows, macOS ou MDM. Pour Sophos Endpoint, la personne responsable de la Policy sélectionne la Location transmise dans l’Endpoint Policy et affecte cette Policy au groupe pilote transmis. Documentez la Location, la Policy, le groupe et la méthode de retrait.
Renouvelez les caches et les baux existants uniquement dans le pilote et de manière contrôlée. Une purge globale du cache génère une charge inutile et complique les comparaisons.
Ne limitez les autres chemins DNS qu’après une validation réussie.

Limites de la protection contre le contournement

Le DNS classique peut être limité en n’autorisant les connexions UDP/TCP 53 sortantes qu’aux résolveurs locaux autorisés en mode redirecteur, ou uniquement aux sous-réseaux clients ou pilotes autorisés en mode client direct. La redirection des destinations inconnues du port 53 vers votre propre résolveur peut aider avec les appareils difficiles à administrer, mais elle doit exclure les serveurs DNS internes, les VPN, les réseaux invités et les appareils qui exigent des résolveurs précis. Lorsque les clients sont administrables, le blocage est plus transparent que la redirection.

Ce contrôle ne couvre ni DoH sur TCP 443, ni DoT sur TCP 853, ni la résolution de noms dans un tunnel VPN tiers. Ne bloquez pas TCP 443 sans discernement. Les stratégies du navigateur, du système d’exploitation, du MDM et de l’Endpoint doivent contrôler le Secure DNS non autorisé ; les utilisations connues de DoT peuvent être traitées de manière ciblée. Apple Private Relay et les services de confidentialité similaires constituent également une décision d’architecture distincte.

Si seuls des iPhone ne parviennent pas à accéder à Internet alors que la résolution fonctionne sur les autres appareils, désactivez temporairement Limit IP Address Tracking pour le réseau concerné, puis effectuez un nouveau test. Appliquez délibérément cette modification uniquement aux appareils pilotes, car elle concerne une fonction de confidentialité de l’appareil.

La protection contre le contournement s’arrête à la limite administrative. Dans un réseau BYOD ou invité, une Policy documentée et moins stricte est souvent plus robuste qu’une tentative d’imposer chaque résolveur chiffré sans gestion des appareils.

Pilote, validation et recette

Commencez avec un VLAN représentatif ou quelques appareils. Testez au minimum les noms publics, les FQDN internes, les recherches inverses, le VPN, l’accès invité, le basculement WAN et un blocage de test inoffensif.

Avant la modification, définissez une période d’observation et des critères de retour arrière explicites. Annulez le pilote si la résolution interne ou VPN échoue, si une mauvaise Location ou Policy apparaît, si la connexion DoH/TLS reste instable ou si une destination métier nécessaire est perturbée ; ne poursuivez pas le déploiement tant qu’un déclencheur reste actif.

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

Avec dig installé :

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

Remplacez <resolver-ip> par le résolveur local ou, en cas d’utilisation directe, par une adresse du tenant. corp.example est une zone de documentation et doit être remplacé par votre propre zone interne. Le test TCP confirme que le fonctionnement ne se limite pas à UDP.

Ouvrez ensuite dans un navigateur l’URL de test copiée sous Installers > Check your configuration. Le message de bienvenue confirme le chemin DNS Protection, mais pas à lui seul la bonne Policy. Bloquez également de manière ciblée un domaine de test inoffensif et vérifiez dans Sophos Fusion que la requête, la Location et la Policy apparaissent comme prévu. Les rapports ne sont pas nécessairement produits en temps réel ; ne concluez donc pas à une erreur immédiatement après une seule requête.

La recette exige que :

les deux résolveurs Sophos fonctionnent séparément en UDP et TCP ;
les zones directes et inverses internes restent internes ;
la sortie attendue soit associée à la bonne Location ;
le blocage et les destinations métier autorisées fonctionnent ;
le basculement WAN, le VPN et les clients compatibles IPv6 ne créent aucun chemin parallèle ;
le DNS non autorisé sur le port 53 soit bloqué ou redirigé conformément à l’architecture ;
les pilotes Secure DNS manuels pour Windows, macOS et MDM utilisent exactement l’URL ou le profil généré, tandis que les pilotes Sophos Endpoint sont affectés à une Policy contenant la Location prévue ; les deux apparaissent sous la Location et la Policy prévues et réussissent les tests au bureau, en mobilité, via VPN, pour les domaines internes et lors du retrait ;
la supervision et un chemin de retour arrière testé soient documentés.

Exploitation et contrôles réguliers

Après le pilote, procédez au déploiement par vagues, par site ou par VLAN. Pour chaque vague, surveillez les erreurs DNS, les signalements au support, les domaines métier bloqués et l’association de sortie. Migrez en dernier les serveurs statiques et les appareils OT/IoT, dans une fenêtre de maintenance distincte.

Après toute modification du WAN, du NAT, du DHCP, du VPN, d’IPv6 ou des résolveurs locaux, contrôlez de nouveau le chemin DNS. Il en va de même après un changement de fournisseur d’accès ou d’adresse de sortie publique. Vérifiez régulièrement que les deux résolveurs du tenant sont toujours configurés, que les zones internes sont résolues localement et qu’aucun serveur DNS supplémentaire ne contourne la protection. Intégrez au processus d’exploitation les notifications produit sous My Environment > Alerts et l’état sous My Products > DNS Protection.

Retour arrière sécurisé ou mise hors service

Pour revenir en arrière, commencez par désactiver les nouvelles règles de blocage ou de redirection DNS. Exécutez ensuite la branche correspondant au mode de déploiement :

Mode redirecteur : restaurez activement les redirecteurs précédents documentés sur le résolveur local. Vérifiez ensuite la résolution interne et publique.
Mode client direct : restaurez les valeurs DNS précédentes documentées dans DHCP, VPN et les clients statiques. Renouvelez les baux des appareils de test, puis vérifiez la résolution interne et publique.
Secure DNS : la personne responsable de Windows, macOS ou MDM retire le profil pilote ; la personne responsable de la Sophos Endpoint Policy retire quant à elle l’affectation du groupe pilote. Restaurez ensuite l’état DNS précédent et vérifiez que le chemin DoH n’est plus utilisé.

Conservez dans un premier temps les redirecteurs conditionnels et la Sophos Fusion Location, sauf si la Location elle-même a provoqué l’incident.

Dépannage par symptôme

Aucun nom public n’est résolu

Testez d’abord explicitement les deux adresses Sophos en UDP et TCP. Vérifiez ensuite la règle de sortie, le NAT, la route et l’adresse IP source publique visible. Si l’adresse source n’est associée à aucune Location ou entre en conflit avec un autre tenant, DNS Protection peut rejeter les requêtes. Avec DDNS, vérifiez également la résolution publique du FQDN.

Les noms internes ou Active Directory ne fonctionnent plus

Vérifiez quel résolveur le client utilise réellement. Contrôlez ensuite les redirecteurs conditionnels, les serveurs cibles faisant autorité, les zones inverses, les suffixes de recherche et le split DNS du VPN. Un résolveur DNS Protection distribué directement ne connaît pas les zones privées.

Seules les réponses volumineuses ou certains domaines échouent

Testez TCP 53. Si UDP fonctionne, mais pas dig +tcp, la règle TCP est généralement absente ou un équipement intermédiaire rejette la connexion. Si un domaine autorisé reste bloqué, vérifiez également la cible CNAME et la classification de sécurité.

Sophos Fusion n’affiche aucune Location ou affiche la mauvaise

Déterminez la sortie réelle au lieu de vous fier uniquement à l’adresse WAN configurée. Le SD-WAN, les passerelles NAT centrales, les proxys et le basculement peuvent modifier l’adresse IP source. Accordez ensuite suffisamment de temps à la génération des rapports et vérifiez que le test utilisait bien le résolveur prévu, et non le DoH du navigateur ou un VPN.

Pour une Location définie par FQDN, vérifiez également la résolution publique. Dans le cas d’une entrée DNS Cloudflare, Proxy status: DNS only doit être défini ; une entrée avec proxy ne renvoie pas l’adresse de sortie publique réelle. Une adresse privée ou IPv6 n’est pas une adresse valide pour une Location. Si la même valeur publique est déjà associée à un autre client ou si le FQDN n’est pas valide, corrigez l’association avant de poursuivre le déploiement.

La page de blocage est absente alors que le blocage DNS fonctionne

Cela ne prouve pas que le domaine est autorisé. Vérifiez l’accès à blockpage.dnsprotection.sophos.com, la confiance accordée au DNS Protection Root Certificate, Pharming Protection, le proxy Web ou le filtre Web et l’inspection TLS. Si le pare-feu déchiffre le chemin des pages de blocage, utilisez l’action strictement limitée Do not decrypt pour le chemin de destination Sophos documenté. Gérez toujours l’installation et le retrait du certificat au moyen du processus de la plateforme responsable.

Un domaine autorisé reste bloqué

Vérifiez d’abord le nom cible CNAME et sa catégorie : un domaine initial autorisé peut toujours pointer vers un nom bloqué en raison de sa catégorie ou de son Threat Score. Après une modification de Policy, attendez également l’expiration du TTL DNS et des caches locaux ou renouvelez-les de manière contrôlée. N’accélérez pas le déploiement en créant des exceptions générales trop larges.

La protection contre le contournement ne fonctionne pas

Recherchez dans les journaux les connexions sortantes UDP/TCP 53, TCP 853 et les connexions Secure DNS connues. Contrôlez ensuite le navigateur, le système d’exploitation, le VPN et le logiciel de sécurité local. Un filtre sur le port 53 ne peut ni détecter ni empêcher le DNS chiffré sur le port 443.

Le DNS est résolu, mais la Policy et les rapports sont absents

Commencez par vérifier avec ipconfig, nslookup ou, sous Linux et macOS, avec dig, quels résolveurs l’appareil utilise réellement. Effectuez ensuite un test Standard ou Extended sur https://www.dnsleaktest.com/. Lorsque DNS Protection est utilisé, toutes les valeurs de la colonne Hostname contiennent le motif gw-<numéro>.<région>.dnsprotection.sophos.com ; Amazon ou une désignation correspondante apparaît comme FAI. D’autres résolveurs indiquent une fuite DNS ou une redirection par le fournisseur d’accès.

Si https://dns.access.sophos.com affiche une erreur de navigateur au lieu de la page de bienvenue, tandis que le tableau de bord indique No queries received from locations, ou si une Sophos Firewall signale DNS Protection: Connectivity Error, commencez par éliminer le chemin de résolveur divergent. Pour ce faire, vérifiez le DNS du routeur, DHCP et DHCPv6, les entrées DNS statiques, la redirection du fournisseur d’accès et les résolveurs IPv6 parallèles. N’examinez qu’ensuite la Policy ou les rapports ; cette procédure de vérification s’applique au chemin réseau, et non sans validation préalable au DoH des Endpoints.

Guides connexes existants

Configurer Sophos DNS Protection avec Sophos Firewall décrit l’intégration concrète dans SFOS.
Endpoint DNS Protection Policy décrit le chemin Workspace administré distinct pour les Endpoints.