Configurer les routes de requêtes DNS sur Sophos Firewall

Une DNS Request Route transmet les requêtes destinées à un domaine ou à une zone inverse spécifique vers les serveurs DNS sélectionnés. Prenons le cas courant de ad.example.com : le pare-feu résout les noms publics au moyen de ses résolveurs habituels, mais adresse les requêtes concernant cette zone interne aux contrôleurs de domaine.

La route ne s’applique que si Sophos Firewall traite la requête en tant que serveur DNS. Lorsqu’un client interroge directement un serveur DNS interne, c’est la configuration de transfert de ce dernier qui s’applique, et non la route de requête du pare-feu.

La zone cible n’est pas nécessairement interne : une Request Route peut aussi transmettre les requêtes destinées à certains domaines publics à un résolveur du réseau local. Cette approche est pertinente lorsque ce résolveur est délibérément chargé de traiter ces domaines. Un traitement local peut réduire les requêtes DNS externes ; toutefois, un gain de rapidité donné ou une confidentialité accrue ne sont possibles que si le résolveur cible traite les requêtes en conséquence, sans les retransmettre telles quelles sur Internet.

Déterminer le chemin DNS avant toute modification

Trois configurations en apparence similaires répondent à des besoins différents :

• Le client interroge le pare-feu : le serveur DHCP ou le profil VPN fournit l’adresse IP de l’interface du pare-feu comme serveur DNS. Pour accéder au service DNS local, la zone du client doit être autorisée à utiliser DNS sous Administration > Device access > Local service ACL. Les règles de pare-feu ordinaires ne régissent pas l’accès aux services hébergés par le pare-feu lui-même.
• Le client interroge directement un serveur DNS interne : le résolveur interne répond pour ses zones locales et transmet les autres requêtes. Une règle de pare-feu standard peut être nécessaire si le trafic traverse plusieurs zones. Ce chemin client n’utilise aucune route de requête configurée sur le pare-feu.
• Le pare-feu interroge un serveur cible interne : une route de requête sélectionne le serveur cible en fonction du domaine demandé. Le routage vers ce serveur et son accessibilité doivent être opérationnels.

À l’inverse, une DNS Host Entry permet au pare-feu de répondre directement pour un nom donné. Pour quelques enregistrements statiques, consultez Configurer des DNS Host Entries sur Sophos Firewall. Une route de requête convient mieux à une zone entière administrée sur un serveur DNS. Les options DHCP déterminent quant à elles le serveur DNS et le domaine de recherche fournis au client ; voir Configurer les options DHCP sur Sophos Firewall.

⚠️ Une route de requête est sélectionnée d’après le nom de domaine, et non d’après le réseau source du client. Si plusieurs sites doivent recevoir des réponses différentes, ces vues doivent être gérées par les résolveurs concernés ou par des chemins DNS distincts. Une route unique ne peut pas produire des réponses DNS qui dépendent de la source.

Exemple et prérequis

Dans cet exemple, une zone AD interne est transmise à deux résolveurs :

• zone interne : ad.example.com
• serveur cible principal : 10.10.10.10
• serveur cible secondaire : 10.10.10.11
• réseau client : 10.20.30.0/24
• adresse IP du pare-feu utilisée comme résolveur par le client : 10.20.30.1
• test positif : dc01.ad.example.com
• test négatif : example.net

example.com et example.net sont des domaines réservés à la documentation. Dans la configuration de production, remplacez la zone ainsi que les adresses des serveurs et de l’interface par vos propres valeurs. Les deux serveurs cibles doivent faire autorité pour la même zone et contenir les mêmes données. Une longue liste de résolveurs sans rapport entre eux ne constitue pas une stratégie de redondance fiable.

Avant de créer la route, vérifiez les points suivants :

1. Le pare-feu est configuré comme résolveur sous Network > DNS > DNS configuration.
2. Les serveurs cibles sont joignables par le chemin de routage local ou VPN prévu.
3. Les clients concernés utilisent réellement l’adresse IP du pare-feu comme serveur DNS.
4. Sous Administration > Device access, DNS n’est activé que pour les zones clientes nécessaires. Si toute la zone ne doit pas y accéder, utilisez une Local Service ACL Exception plus restrictive.
5. La zone interne existe sur les serveurs cibles et comporte un enregistrement connu pour les tests.
6. Le chemin DNS actuel et les routes de requête existantes sont documentés afin de permettre un retour en arrière.

Créer la DNS Request Route

1. Dans WebAdmin, ouvrez Network > DNS.
2. Accédez à la section DNS request route.
3. Sélectionnez Add.
4. Dans Host/Domain name, saisissez ad.example.com.
5. Sous Target servers, sélectionnez 10.10.10.10 et 10.10.10.11. Si les objets serveur n’existent pas encore, créez-les comme hôtes IP avec Create.
6. Vérifiez l’ordre. SFOS interroge les hôtes sélectionnés dans l’ordre affiché.
7. Sélectionnez Save.

Sophos accepte jusqu’à huit adresses IP cibles par route de requête. Des serveurs supplémentaires n’améliorent la disponibilité que s’ils répondent correctement pour la même zone et sont joignables par des chemins indépendants qui ont réellement été testés.

Lorsqu’une route de requête correspond au domaine et qu’aucune réponse adéquate ne se trouve dans le cache, SFOS envoie la requête aux Target Servers de cette route. Pour ce domaine, il ne se replie ni sur les redirecteurs globaux ni sur les serveurs racine. Si tous les serveurs cibles sont injoignables ou mal configurés pour la zone, la résolution échoue au lieu de passer discrètement par un résolveur public.

La nouvelle entrée doit ensuite apparaître sous DNS request route, avec le domaine et les serveurs cibles attendus.

Évaluer correctement plusieurs serveurs cibles

L’ordre documenté des serveurs constitue un mécanisme de disponibilité ; il ne permet pas de réconcilier des données DNS contradictoires. Pour les résolveurs statiques globaux, SFOS considère NXDOMAIN comme une réponse valide et n’interroge pas le serveur suivant. L’aide de SFOS 22 ne confirme pas explicitement que les Target Servers d’une route de requête se comportent de la même manière. Il ne faut donc ni compter sur un second serveur contenant des données de zone différentes, ni garantir un comportement de basculement précis après une réponse NXDOMAIN.

Lors de la recette, interrogez chaque serveur cible séparément depuis un système de test autorisé. Les deux serveurs doivent renvoyer la même réponse au test positif. Un nom volontairement inexistant doit également produire le même résultat sur chacun d’eux. Ces contrôles mettent en évidence les problèmes de réplication ou d’autorité de zone avant que le pare-feu ait à basculer d’un serveur à l’autre.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

Ces requêtes directes testent les données de zone et la réponse de chaque serveur, pas la route de requête. Exécutez-les uniquement depuis un réseau autorisé par la conception DNS à joindre les deux résolveurs. Interrogez ensuite 10.20.30.1 afin de confirmer que le pare-feu transmet lui aussi la zone aux serveurs prévus.

Transmettre les recherches inversées

Pour les requêtes PTR, saisissez la zone inverse — et non le réseau — dans Host/Domain name. Pour 172.16.16.0/24, la zone inverse IPv4 classique est :

16.16.172.in-addr.arpa

Pour 172.16.0.0/16, il s’agit de :

16.172.in-addr.arpa

Ne saisissez pas une notation CIDR telle que 172.16.16.0/24 dans le champ du domaine. Seule compte la zone effectivement configurée sur le serveur DNS interne. Une route de requête ne crée aucun enregistrement PTR. Si la zone ou les enregistrements sont absents du serveur cible, la recherche inverse échoue toujours. Les réseaux IPv4 dont le préfixe n’est pas aligné sur un octet et les zones inverses IPv6 nécessitent une conception de délégation DNS spécifique ; il ne suffit pas d’inverser le préfixe.

Le DNS inverse permet aux journaux et aux services d’associer une adresse à un nom. Il ne peut pas corriger l’échec de la résolution directe d’un FQDN et doit donc faire l’objet d’un test distinct.

Comprendre le chemin du résolveur global

Sous Network > DNS > DNS configuration, indiquez comment le pare-feu résout les requêtes qui ne correspondent à aucune Host Entry ni Request Route. Selon l’interface, SFOS peut obtenir les résolveurs via Obtain DNS from DHCP ou Obtain DNS from PPPoE. Avec Static DNS, définissez explicitement DNS 1, DNS 2 et, si nécessaire, DNS 3.

⚠️ Si Obtain DNS from DHCP est actif et que la dernière interface DHCP correspondante est désactivée ou passe à un autre mode d’attribution, SFOS bascule vers Static DNS. La réactivation de l’interface ne rétablit pas automatiquement la sélection précédente. Vérifiez donc le choix DNS après toute modification du WAN ou des interfaces.

Avec Static DNS, le pare-feu interroge les serveurs dans l’ordre configuré. Il passe au suivant après un délai d’attente, mais pas après une réponse NXDOMAIN valide. Les réponses restent en cache conformément à leur TTL. Le second résolveur assure donc une solution de repli en cas d’indisponibilité, et non une autre version de la vérité DNS.

Pour les serveurs DNS globaux, SFOS 22 documente quatre options de sélection. Les deux options de priorité fixe nécessitent que des serveurs DNS IPv4 et IPv6 soient configurés :

• Choose a server based on incoming requests record type sélectionne le serveur DNS en fonction du type d’enregistrement demandé, A ou AAAA.
• Choose IPv6 DNS server over IPv4 donne la priorité au serveur DNS IPv6 par rapport au serveur DNS IPv4.
• Choose IPv4 DNS server over IPv6 donne la priorité au serveur DNS IPv4 par rapport au serveur DNS IPv6.
• Choose IPv6 if request originator address is IPv6, else IPv4 utilise le serveur DNS IPv6 pour une requête provenant d’une adresse source IPv6, et le serveur DNS IPv4 pour une requête provenant d’une adresse source IPv4.

Le type d’enregistrement et la famille de l’adresse source sont deux critères distincts : une requête AAAA ne provient pas automatiquement d’une adresse source IPv6. La sélection s’effectue donc selon le chemin de résolution prévu, et non uniquement selon l’adresse souhaitée dans la réponse DNS. Les résolveurs sélectionnés doivent être joignables via leur famille d’adresses respective. Ces options globales ne modifient pas la sélection des Target servers d’une Request Route en fonction du domaine.

Après avoir sélectionné Apply, utilisez Test name lookup pour résoudre un nom d’hôte ou une adresse IP du point de vue du pare-feu. Un nom de test interne peut correspondre à une route de requête. Ce test ne confirme toutefois ni le résolveur configuré sur le client ni le chemin réellement emprunté par ses requêtes.

Si WebAdmin est indisponible pendant une opération de récupération planifiée, l’interface CLI interactive, sous 1. Network Configuration > DNS Configuration, affiche les serveurs DNS IPv4 et IPv6 globaux. Ce menu ne modifie pas les routes de requête. Relevez toutes les valeurs affichées avant toute saisie ; appuyer sur Enter sans fournir de nouvelle valeur ignore la modification. Pour une intervention à distance, conservez un chemin de gestion indépendant.

Associer DNS Protection aux zones internes

Choisir d’abord la version : à partir de SFOS 23.0, utiliser le chemin DoH intégré avec DNS Protection sous Network > DNS et l’attribution de la Filtering Policy à l’objet pare-feu. L’article DNS Protection lié ci-dessous décrit la configuration, la décision de repli, le pilote et le retour en arrière. La séquence suivante de Location/DDNS et de Static DNS s’applique exclusivement à Traditional DNS sur SFOS 22 et versions antérieures ; ne pas l’exécuter en plus du chemin intégré de SFOS 23. Les Request Routes internes et les vérifications du chemin client et du NAT restent pertinentes.

Avec Sophos DNS Protection et Sophos Firewall, les requêtes publiques sont envoyées à DNS Protection, tandis que les routes de requête dirigent les zones internes vers les résolveurs locaux. Commencez par enregistrer le pare-feu en tant qu’emplacement dans Sophos Fusion (anciennement Sophos Central). Si plusieurs adresses WAN publiques sont utilisées, enregistrez toutes les adresses concernées ou la plage appropriée. Pour une adresse WAN dynamique, utilisez le nom d’hôte DDNS enregistré.

La configuration officielle de Sophos définit les deux adresses DNS Protection comme DNS 1 et DNS 2 sous Network > DNS > DNS configuration, laisse DNS 3 vide, supprime les serveurs DNS IPv6 et sélectionne Choose IPv4 DNS server over IPv6. Un troisième résolveur ou un résolveur IPv6 non prévu peut permettre à des requêtes de contourner DNS Protection.

Sophos préconise une configuration DHCP particulière : sous Network > DHCP > Server > Edit, laissez Use device’s DNS settings désactivé. Définissez comme Primary DNS l’adresse IP du pare-feu sur l’interface DHCP, et comme Secondary DNS une adresse publique de DNS Protection. Les clients ne gèrent pas tous plusieurs résolveurs de la même façon ; vérifiez donc que les requêtes internes passent réellement par le pare-feu. Les requêtes envoyées directement par un client à DNS Protection n’utilisent pas les routes de requête locales du pare-feu.

Sophos décrit également une règle DNAT qui redirige les requêtes DNS sortantes classiques des réseaux internes vers l’adresse IP interne du pare-feu. Cette redirection relève d’une décision de sécurité distincte : elle n’intercepte pas automatiquement DNS over HTTPS ou DNS over TLS et peut perturber certains équipements spécialisés. Ne la mettez en place que pour des réseaux sources clairement définis, jamais avec le WAN comme Inbound Interface, et prévoyez des exceptions ainsi qu’un plan de retour en arrière documenté.

Tester séparément le pare-feu et le client

Vue du résolveur du pare-feu

Sous Network > DNS > Test name lookup, testez successivement dc01.ad.example.com et example.net. Le nom interne doit renvoyer l’adresse interne attendue ; le nom public doit continuer à être résolu par le chemin par défaut prévu.

Dans 4. Device Console, la commande officiellement documentée offre le même point de vue :

dnslookup host dc01.ad.example.com
dnslookup host example.net

Ces contrôles montrent le résultat obtenu par le résolveur du pare-feu. Ils ne prouvent pas encore qu’un client interroge celui-ci.

Comparer les résolveurs individuellement sous Diagnostics

Sous Diagnostics > Tools, SFOS 22 propose Name lookup avec les champs IP address or hostname et DNS server IP. Un FQDN permet de tester la résolution directe, tandis qu’une adresse IPv4 ou IPv6 permet de tester la résolution inverse. Sélectionnez un serveur configuré en particulier ou utilisez Lookup using all configured servers pour comparer les réponses et les temps de réponse de tous les résolveurs configurés. Un temps de réponse court ne justifie pas à lui seul de modifier l’ordre des serveurs ; vérifiez d’abord que les réponses correspondent à la zone prévue.

Dans SFOS 23, la section s’appelle DNS lookup et les champs Hostname or IP address et DNS server IP address. Outre la sélection d’un serveur disponible et l’option All configured servers, les options Custom DNS server et Custom DoH server sont proposées ; dans les deux cas, saisissez l’adresse IP du serveur souhaité. DNS Protection ne peut être sélectionné que si DNS Protection est activé sous Network > DNS. Il s’agit d’une option de diagnostic, et non d’une invitation à modifier la configuration DNS existante pour effectuer un test.

Pour les noms de test internes, utilisez uniquement des résolveurs internes approuvés afin de ne pas transmettre ces noms à un service DNS ou DoH public. Une requête adressée à un résolveur précis confirme sa réponse, mais pas le chemin réellement emprunté via la Request Route ou par le client. La recette au moyen de requêtes adressées à l’adresse IP du pare-feu et de Packet Capture reste donc nécessaire.

Vérifier le chemin du client

Sur un client de test, contrôlez d’abord le serveur DNS configuré, puis interrogez explicitement l’adresse IP 10.20.30.1 du pare-feu.

Windows :

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS ou Linux :

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Répétez ensuite les mêmes requêtes sans préciser de serveur. Si les résultats diffèrent, le client emprunte un autre chemin de résolution : paramètre statique, profil VPN, DNS over HTTPS ou agent de sécurité local, par exemple. Un domaine de recherche n’intervient que pour les noms courts et non qualifiés ; les FQDN ci-dessus n’en ont pas besoin.

Capturer les paquets sur le chemin réel

Sous Diagnostics > Packet capture, limitez le trafic à l’aide d’un filtre portant sur le client de test, les serveurs cibles et le port 53. Effectuer une capture de paquets sur Sophos Firewall décrit la procédure en détail.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Recherchez la requête entrante du client, la requête émise par le pare-feu vers le bon Target Server et les réponses correspondantes. La capture permet ainsi de distinguer un problème d’accès du client d’un problème de routage ou de serveur cible. La mémoire tampon étant limitée, utilisez un filtre précis et n’enregistrez que pendant le test.

Avec DNS Protection, le lien officiel Check your configuration, sous My Products > DNS Protection > Installers, apporte un contrôle supplémentaire. La page d’accueil confirme le chemin DNS Protection, mais la zone interne, le chemin du client et la route de requête doivent toujours être testés séparément.

Diagnostiquer selon le symptôme

Le pare-feu résout le nom interne, mais pas le client

• Confirmez que le client utilise bien l’adresse IP du pare-feu comme serveur DNS.
• Sous Administration > Device access, vérifiez que DNS est autorisé pour la zone du client ou au moyen d’une Local Service ACL Exception adaptée.
• Envoyez explicitement la requête à l’adresse IP du pare-feu et vérifiez-la avec Packet Capture.
• Recherchez d’autres chemins possibles dans les paramètres DHCP, VPN et du résolveur local, ainsi que dans la configuration DoH ou DoT.

Le pare-feu ne parvient pas à joindre le serveur cible

• Vérifiez Route Lookup et le chemin local ou VPN vers l’adresse cible.
• Contrôlez les ports UDP et TCP 53 jusqu’au serveur cible, y compris l’ACL propre au serveur.
• Interrogez directement le résolveur et confirmez qu’il accepte les requêtes provenant de l’adresse IP du pare-feu.
• Dans Packet Capture, recherchez la requête émise, une réponse ou le motif d’un abandon.

Si les clients interrogent directement le serveur DNS interne, examinez plutôt le chemin de transit standard, notamment les zones et la règle de pare-feu concernée. Tester les règles de pare-feu avec Log Viewer, Policy Test et Packet Capture permet de différencier ce cas.

Les réponses sont incorrectes ou incohérentes

• Domaine trop large ou incorrect : limitez la route de requête à la zone pour laquelle le serveur fait réellement autorité.
• Données différentes selon le serveur cible : vérifiez directement la réplication DNS et l’autorité de zone sur chaque serveur.
• Réponse obsolète : tenez compte du TTL et des caches du pare-feu, du résolveur et du client.
• Échec limité aux noms courts : contrôlez le domaine de recherche du client et testez le FQDN séparément.
• Échec de la recherche inverse : contrôlez la zone PTR et l’enregistrement PTR sur le serveur cible.
• Seuls les clients VPN sont concernés : vérifiez les serveurs DNS attribués, le routage VPN et l’accès au service DNS local. Les paramètres client correspondants sont décrits dans Configurer Sophos Connect et Configurer l’accès distant SSL VPN.

API XML : identifier la route par son nom d’objet

À partir de SFOS 23, la documentation de l’API XML exige à la fois Name et DomainName lors de la création et de la modification d’une DNS Request Route. Name identifie l’objet configuré, DomainName la zone DNS à transmettre ; par exemple, Name = ad-intern et DomainName = ad.example.com. Il s’agit de valeurs de champs, et non de XML exécutable. Name est une valeur STRING unique de 64 caractères maximum ; UTF-8 est autorisé et les virgules sont interdites. DomainName reste de type FQDN, avec un maximum de 255 caractères ; les serveurs cibles doivent également toujours être renseignés.

Pour la suppression, la clé documentée passe de DomainName dans SFOS 22 à Name dans SFOS 23. Ne pas rejouer telles quelles les anciennes requêtes et ne pas reprendre automatiquement le nom de domaine comme nom d’objet. Au préalable, vérifier la version installée et lire l’objet concerné, comparer Name, DomainName, les Target Servers et les dépendances avec la cible prévue, puis documenter le retour en arrière. En cas d’ambiguïté, arrêter l’opération. Après la suppression, vérifier la réponse de l’API et son statut, puis relire la cible exacte : seule la route prévue doit avoir été supprimée ; les autres routes doivent rester inchangées. Tester ensuite la résolution interne et publique comme décrit plus haut. Aucune enveloppe de suppression ni aucun schéma REST ne sont inventés ici, et aucun test sur le produit n’est revendiqué.

La configuration globale du protocole DNS est distincte. L’article DNS Protection explique les conflits non résolus du schéma XML de SFOS 23 et le chemin sûr dans WebAdmin ; les quatre options de sélection du résolveur décrites plus haut explicitement pour SFOS 22 ne prouvent aucune correspondance numérique dans l’API de SFOS 23.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Retour en arrière et exploitation

Avant la modification, consignez les routes de requête existantes, la sélection DNS globale, les autorisations Device Access ainsi que le résultat d’un test positif et d’un test négatif. Pour un retour en arrière normal, supprimez la route nouvellement créée ou rétablissez exactement les valeurs précédemment documentées. Restaurez également l’état initial de toute exception ACL ou redirection DNS temporaire.

Vérifiez ensuite à nouveau les trois points suivants :

1. Le pare-feu résout un nom interne et un nom public par les chemins prévus.
2. Le client concerné utilise le résolveur prévu et reçoit les réponses attendues.
3. Un domaine non concerné par la route n’est pas envoyé au Target Server interne.

Une sauvegarde complète de la configuration n’est pas un moyen pratique d’annuler la modification d’un seul objet. Sa restauration remplace toute la configuration et risque d’écraser des changements ultérieurs. Pour une seule route de requête, l’annulation de la modification documentée au niveau de l’objet est plus sûre.

Questions fréquentes