Gérer les Locations Sophos DNS Protection en toute sécurité

Une Location indique à Sophos DNS Protection à quel site, réseau ou ensemble d’appareils appartient une requête DNS. Cette association rend possible l’application de Filtering policies propres à chaque site et la production de rapports pertinents. Pour assurer un fonctionnement stable, une Location doit représenter la sortie Internet, et non chaque VLAN interne.

Le processus complet commence sous My Products > DNS Protection > Locations : choisir la méthode de connexion, créer la Location, vérifier l’affectation sur la page Policies, tester le chemin DNS réel et, seulement ensuite, supprimer les anciennes adresses IP ou Locations. La Default location constitue un point de départ Secure DNS immuable ; les Locations personnalisées représentent des sites, des régions ou des groupes de policies distincts.

Choisir entre Default et une Location personnalisée

La Default location prédéfinie utilise Secure DNS et fonctionne sans adresse publique de site enregistrée. Elle peut être affectée à une Endpoint policy comme à une Filtering policy. Il est possible d’afficher ses détails sous My Products > DNS Protection > Locations > Default, mais ni de la modifier ni de la supprimer.

Une Location personnalisée est utile si au moins l’un des cas suivants s’applique :

un pare-feu, un routeur ou un résolveur DNS local envoie des requêtes DNS classiques ;
des sites ou des groupes d’appareils nécessitent des Filtering policies différentes ;
les rapports doivent distinguer les requêtes DNS par région ou sortie Internet ;
les appareils Endpoint nécessitent une affectation Secure DNS dédiée plutôt que Default.

DNS Protection autorise au maximum 50 Locations. Une Location personnalisée peut utiliser Secure DNS, Traditional DNS over IPv4 ou les deux méthodes. Chaque Location peut contenir au maximum 100 adresses IPv4 publiques ou FQDN.

Choisir la méthode de connexion appropriée

Secure DNS

Secure DNS transporte le DNS via HTTPS. Cette méthode convient aux appareils compatibles et est obligatoire pour Sophos Endpoint avec DNS Protection. Lors de l’enregistrement, Central génère une DNS over HTTPS URL propre à la Location. Sophos Endpoint configure automatiquement les appareils gérés ; l’URL est nécessaire pour configurer manuellement un appareil.

Pour ce déploiement, il faut utiliser et copier exactement les deux adresses IPv4 DNS Protection affichées par Central.

Traditional DNS over IPv4

Traditional DNS over IPv4 envoie les requêtes DNS sans chiffrement aux résolveurs DNS Protection. Cette méthode convient aux pare-feu, aux routeurs et aux serveurs DNS locaux. DNS Protection reconnaît la Location à partir de l’adresse IP source publique. Il faut donc enregistrer l’adresse WAN publique, une plage publique ou un FQDN qui pointe vers cette adresse, jamais une adresse RFC 1918 interne.

La configuration complète du pare-feu, avec les forwarders, les zones internes et le DHCP, relève du guide distinct consacré à Sophos DNS Protection avec Sophos Firewall. La Location seule ne modifie pas encore le chemin DNS du réseau.

Les deux méthodes

Les deux options peuvent être actives dans la même Location personnalisée. Cela est utile si un même contexte de policy comprend à la fois des endpoints gérés via DoH et un résolveur de site utilisant le DNS classique. Il convient de déterminer au préalable si ces deux chemins doivent réellement recevoir le même filtrage et figurer dans les mêmes rapports.

Prérequis et plan d’adressage

Avant la création, noter :

un nom unique, une courte description et le responsable technique ;
la méthode de connexion souhaitée ;
toutes les adresses de sortie publiques en cas de multi-WAN, de SD-WAN et de failover ;
un FQDN DDNS correctement maintenu en cas d’adresse publique dynamique ;
la Filtering policy prévue et, le cas échéant, l’Endpoint policy ;
un appareil de test directement connecté pour chaque chemin DNS.

Default est un nom réservé. ZH-HQ-Egress convient comme exemple ; la description peut préciser le fournisseur, les WAN et le responsable. Le nom d’un site doit rester stable, même en cas de changement de fournisseur.

Pour modifier DNS Protection, il faut disposer d’un rôle d’administration approprié dans Sophos Fusion. Un accès en lecture seule permet d’effectuer des contrôles, mais pas de créer, de modifier ou de supprimer des éléments. La saisie manuelle d’une adresse IP publique ou d’un FQDN ne constitue pas une preuve d’autorisation à utiliser le service.

Le DNS autonome ou basé sur le réseau nécessite au moins un pare-feu valide, associé à Central et doté de Xstream Protection. En revanche, le DNS Endpoint géré est une fonction Workspace ; Xstream seul ne suffit pas. Add known IPs détecte uniquement les adresses publiques des Sophos Firewalls sous licence dotées de Xstream Protection. Secure DNS nécessite un appareil capable de traiter le DNS via HTTPS ; Sophos Endpoint exige expressément cette méthode de connexion pour DNS Protection.

Créer une Location personnalisée

Ouvrir My Products > DNS Protection > Locations > Add location. Dans la liste des Locations, le bouton Add ouvre cette boîte de dialogue.
Sous Location name, saisir un nom unique et, sous Description, indiquer son rôle.
Sous Connection method, activer Secure DNS, Traditional DNS over IPv4 ou les deux.
Pour Secure DNS, noter les adresses IPv4 affichées. La DNS over HTTPS URL n’est générée qu’avec Save.
Pour Traditional DNS over IPv4, ajouter les valeurs publiques sous IPv4 addresses or FQDNs. Valider chaque entrée avec Enter ou Tab. Lorsque plusieurs valeurs sont collées, chacune doit être placée sur une ligne distincte.
Sélectionner Save.
Pour Secure DNS, copier la DNS over HTTPS URL générée et la conserver en lieu sûr avant de sélectionner Close.

Utiliser les adresses détectées

Add known IPs affiche des suggestions :

Your Current Location correspond à l’adresse d’origine de la session Central en cours. Si la session passe par un VPN, il s’agit de l’adresse publique du serveur VPN, qui n’est peut-être pas l’adresse du site recherchée.
Your Firewalls affiche l’adresse par laquelle une Sophos Firewall sous licence accède à Central. Seuls les pare-feu dotés de Xstream Protection sont détectés automatiquement.

Une valeur détectée n’est qu’une suggestion. DNS Protection ne la met pas automatiquement à jour lors de changements d’adresse ultérieurs. En cas de multi-WAN, les adresses de sortie non détectées doivent être ajoutées manuellement.

IP, FQDN, multi-WAN et DDNS

Pour une connexion fixe, l’adresse IPv4 publique est généralement le choix le plus clair. En cas de multi-WAN, il faut enregistrer toutes les adresses par lesquelles les requêtes DNS peuvent réellement sortir ; il est également possible d’utiliser une plage publique appropriée. Si l’adresse de failover est absente, DNS Protection ne fonctionnera pas pour cette Location après le basculement de la connexion.

Pour une adresse dynamique, saisir le FQDN d’un service DDNS tiers. Le client DDNS doit mettre l’enregistrement à jour de manière fiable. Si Sophos Firewall est utilisé à cette fin, Configurer et vérifier le DNS dynamique sur Sophos Firewall explique la configuration sous Network > Dynamic DNS > Add. DNS Protection vérifie les changements d’adresse chaque minute, puis a besoin de huit secondes pour actualiser son cache. La résolution de noms peut être brièvement interrompue pendant les mises à jour du fournisseur, du DDNS et du cache.

Les services pris en charge sont DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS et Cloudflare. Avec Cloudflare, Proxy status doit être réglé sur DNS only ; un enregistrement proxifié renvoie des adresses Cloudflare au lieu de l’adresse IP de sortie publique.

CGNAT et conflits d’adresses

Traditional DNS nécessite une adresse IP source publique unique. Avec le CGNAT ou des adresses de sortie de fournisseur, de proxy ou de VPN partagées, la même adresse IP peut apparaître dans plusieurs comptes clients. DNS Protection donne la priorité à l’utilisateur qui a créé la Location en premier. Un autre FQDN ne résout pas le problème s’il pointe vers la même adresse IP partagée.

La solution fiable consiste à obtenir une adresse publique unique auprès du fournisseur ou à utiliser Secure DNS pour les appareils compatibles. Les adresses privées telles que 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16 n’identifient pas la sortie Internet et ne doivent pas être ajoutées à la Location.

Finaliser l’affectation des policies

Une Location permet certes d’associer les requêtes DNS entrantes, mais elle ne définit pas encore le filtrage souhaité.

Sous My Products > DNS Protection > Policies > Filtering policies, déplacer la Location de Available vers Assigned to this policy. Une Location ne peut être associée qu’à une Filtering policy.
Dans une Endpoint policy, affecter une Location aux appareils Windows sélectionnés. Elle doit utiliser Secure DNS ; Default location est également autorisée.

Le chemin Endpoint, les Domain Exclusions internes et le composant de l’agent relèvent du guide Endpoint distinct. Une affectation Endpoint ne remplace pas une Filtering policy : la première détermine quels appareils utilisent la Location, tandis que la seconde définit le traitement de leurs domaines et catégories.

Modifier une Location

Avant toute modification, commencer par documenter le nom, les méthodes, la liste IP/FQDN, l’utilisation de DoH et les deux affectations de policy. Ouvrir ensuite la Location personnalisée sous My Products > DNS Protection > Locations, modifier les valeurs et enregistrer avec Save.

Pour migrer une sortie en toute sécurité :

Ajouter la nouvelle adresse publique sans retirer l’ancienne.
Attendre que le nouveau chemin Internet soit actif.
Vérifier la résolution DNS et les correspondances de policy via le nouveau chemin.
Ne supprimer l’ancienne adresse qu’ensuite.

Pour passer de Traditional DNS à Secure DNS, commencer par configurer et valider le chemin DoH sur un groupe pilote. Traditional DNS reste actif jusqu’à la réussite du test. Cela évite une migration non testée et permet de revenir rapidement au chemin précédent.

Validation après création ou modification

Sous My Products > DNS Protection > Locations, vérifier que les valeurs Location, Description et le nombre affiché sous IP addresses/FQDNs sont corrects.
Ouvrir la Location et vérifier dans ses détails que la Connection method prévue et les valeurs IP/FQDN attendues sont enregistrées.
Sous Policies, vérifier que la Location est affectée à la Filtering policy prévue et, le cas échéant, à l’Endpoint policy.
Depuis le chemin DNS concerné, résoudre un domaine dont on sait qu’il est autorisé et un domaine de test délibérément bloqué par la policy affectée. Tenir compte du cache et du TTL DNS.
Vérifier dans le Dashboard ou les rapports que la requête apparaît sous la Location attendue.

La réussite de la résolution de noms ne prouve à elle seule ni que la bonne policy est appliquée ni que la bonne Location est utilisée. Seule la combinaison d’un test positif, d’un test bloqué et d’une entrée de rapport correspondante confirme le chemin complet. Si la requête est absente, comparer d’abord l’adresse IP source publique réelle à IP addresses/FQDNs ; en cas de FQDN non valide ou de conflit d’adresses IP, vérifier ensuite My Environment > Alerts.

Dépanner par symptôme

La Location refuse l’adresse

Les entrées statiques et les noms d’hôte ne sont pris en charge que pour IPv4. Une adresse privée ou IPv6 n’est pas une sortie de site valide. Saisir l’adresse WAN publique ou un FQDN qui pointe vers celle-ci, et valider chaque valeur avec Enter ou Tab.

La résolution s’arrête ou la Location n’apparaît pas dans les rapports

Comparer la sortie réelle à la liste IP/FQDN enregistrée. En cas de multi-WAN, une adresse de failover non enregistrée peut être active. Pour un FQDN, vérifier d’abord qu’il se résout en une adresse IPv4 publique valide. Central signale les FQDN non valides et les conflits d’adresses IP sous My Environment > Alerts.

Conflit IP ou CGNAT

Si la même adresse IP publique appartient déjà à un autre client, la Location créée en premier reste prioritaire. Un alias pointant vers la même adresse IP ne change rien. Demander une adresse IPv4 publique unique au fournisseur ou utiliser Secure DNS pour les appareils adaptés.

Panne DDNS après un changement d’adresse

Vérifier que l’enregistrement DDNS renvoie déjà la nouvelle adresse publique. Tenir ensuite compte au minimum du cycle de mise à jour de DNS Protection et de l’actualisation du cache. Avec Cloudflare, contrôler DNS only. Ne supprimer l’ancienne adresse IP qu’une fois que la nouvelle valeur et la sortie réelle correspondent.

La policy ne s’applique pas

Vérifier à quelle Location la requête a réellement été associée et à quelle Filtering policy cette Location appartient. Une seule Filtering policy s’applique par Location. Après une modification de policy, un enregistrement DNS déjà en cache peut continuer de fonctionner jusqu’à l’expiration de son TTL ; effectuer donc un nouveau test avec un nom inédit ou après l’expiration du cache.

D’autres résolveurs contournent DNS Protection

Si les clients reçoivent des serveurs DNS classiques ou IPv6 supplémentaires, les requêtes peuvent contourner DNS Protection. Pour la résolution publique, distribuer exclusivement le chemin DNS Protection prévu. DNS Protection repose sur IPv4, mais peut également résoudre les enregistrements AAAA ; aucun résolveur IPv6 distinct n’est nécessaire à cette fin.

Exploitation et cycle de vie

Les Locations doivent être vérifiées après tout changement de fournisseur, de WAN, de DDNS ou de policy, ainsi que régulièrement en cours d’exploitation. Dans la liste, comparer Location, Description et le nombre indiqué sous IP addresses/FQDNs à l’état cible documenté. Vérifier la Connection method dans les détails de la Location, et l’affectation sur la page Policies. Les adresses suggérées automatiquement ne sont pas synchronisées en permanence : si une adresse IP précédemment détectée change, il faut adapter la Location ou le nom DDNS maintenu, puis procéder à une nouvelle validation.

Pour les opérations, les pages d’aide actuelles font foi. Les notes de version permettent de situer dans le temps des changements tels que les adresses IP suggérées automatiquement, la fonction de copie des adresses IP et des FQDN ou l’affichage des Locations affectées dans les policies ; elles ne remplacent pas un guide de configuration à jour. Au 24 septembre 2026, les pages d’aide et les notes de version actuelles n’indiquent aucune date précise de mise hors service de DNS Protection.

Supprimer une Location personnalisée en toute sécurité

La Default location ne peut pas être supprimée. Pour une Location personnalisée, respecter l’ordre suivant :

Sauvegarder le nom, la description, les méthodes de connexion activées, les valeurs IP/FQDN, les affectations de policies et l’URL DoH existante. Documenter également tous les pare-feu, résolveurs et appareils configurés manuellement qui utilisent la Location.
Si le chemin DNS reste nécessaire, créer et configurer une Location de remplacement. Celle-ci ne peut fonctionner en parallèle de l’ancienne Location que si elle utilise une identité propre, routable sans ambiguïté, ou un nouveau chemin Secure DNS.
Si une Location de remplacement est utilisée, l’affecter aux Filtering policies et Endpoint policies prévues. Basculer ensuite d’abord un chemin pilote contrôlable vers la Location de remplacement, par exemple des appareils pilotes, un résolveur ou, lorsque les contraintes d’exploitation le permettent, un pare-feu.
Dans le cas d’une Location de remplacement, résoudre via le chemin pilote un domaine autorisé et un domaine bloqué par la policy affectée. Vérifier dans les rapports que les deux requêtes sont associées à la Location de remplacement. Ce n’est qu’après une vérification réussie qu’il faut basculer les autres pare-feu, résolveurs et appareils configurés manuellement. Si le chemin DNS est supprimé sans être remplacé, mettre plutôt fin à son utilisation sur tous les systèmes documentés. Retirer ensuite l’ancienne Location de ses policies précédentes et vérifier qu’elle n’est plus utilisée.
Alors seulement, sélectionner l’ancienne Location sous My Products > DNS Protection > Locations, puis choisir Delete.
Dans le cas d’une Location de remplacement, vérifier à nouveau, via le nouveau chemin, les résolutions autorisée et bloquée ainsi que l’affectation dans les rapports. En cas de suppression sans remplacement, vérifier que les chemins DNS restants fonctionnent comme prévu.

Si une Location de remplacement utilisant Traditional DNS doit employer la même identité publique et ne peut donc pas coexister sans ambiguïté avec l’ancienne Location, il faut s’arrêter avant Delete. La migration prévue et le risque de conflit doivent être documentés ; la suppression ne peut être effectuée qu’au moment de la bascule expressément autorisée. Dans ce cas, la Location de remplacement n’est explicitement pas considérée comme ayant été validée en parallèle.

La recréation avec le nom, la description, les méthodes, les valeurs IP/FQDN et les affectations de policies sauvegardés constitue uniquement une tentative de récupération au mieux, et non une garantie de retour à l’état antérieur. En présence d’une identité publique Traditional DNS contestée, elle ne rétablit notamment pas de manière fiable la priorité de la Location créée en premier. Avec Secure DNS, la recréation génère une nouvelle DNS over HTTPS URL ; celle-ci doit être redistribuée à tous les appareils configurés manuellement. Le cas échéant, reconnecter les pare-feu et les résolveurs au chemin traditionnel. Tester ensuite à nouveau les résolutions autorisée et bloquée ainsi que les rapports.