Configurer les itinéraires de requêtes DNS sur Sophos Firewall

Avec les itinéraires de requêtes DNS, vous pouvez spécifier sur Sophos Firewall quel serveur DNS doit être utilisé pour certains domaines ou zones inversées. Cela est particulièrement utile lorsque le pare-feu utilise des serveurs DNS publics, mais que les noms internes doivent être résolus via un serveur DNS interne.

Des exemples typiques incluent les domaines Active Directory, les applications internes, les recherches inversées ou les environnements VPN.

Lorsque Sophos DNS Protection est utilisé avec Sophos Firewall, les itinéraires de requêtes DNS deviennent encore plus importants. Les domaines publics sont alors dirigés vers le service de protection DNS, tandis que les domaines internes continuent d’être résolus par le serveur DNS local ou le contrôleur de domaine. Sans cette séparation, les applications internes, les connexions AD ou les recherches inversées peuvent soudainement apparaître comme des problèmes de réseau.

Orientation et conception

Les DNS Request Routes ne fonctionnent de manière fiable que si l’on sait clairement quel résolveur voit quelle requête. Il faut donc d’abord distinguer le design DNS, le DNS client, les zones internes et le chemin de routage.

Itinéraire de requête DNS, serveur DNS ou option DHCP ?

Les itinéraires de requêtes DNS sont souvent confondus avec les serveurs DNS globaux ou les options DHCP. Les fonctions résolvent différents problèmes.

• Serveurs DNS globaux : résolution par défaut du pare-feu pour le DNS Internet, résolution FQDN générale, mises à jour et services cloud.
• DNS Request Route : redirige certains domaines ou zones inversées vers des serveurs DNS définis. Cas typiques : Active Directory, domaines internes, DNS de site et Split DNS.
• Option DHCP : distribue des serveurs DNS ou domaines de recherche aux clients. C’est pertinent lorsque les clients doivent utiliser directement un serveur DNS précis.

Un itinéraire de requête DNS ne modifie donc pas automatiquement la configuration DNS de tous les clients. L’itinéraire contrôle où Sophos Firewall lui-même ou les clients utilisant le pare-feu comme relais DNS redirigent certaines requêtes DNS. Si les clients doivent utiliser directement un serveur DNS interne, une option DHCP sur Sophos Firewall est plus appropriée.

Il faut aussi distinguer cela d’une DNS Host Entry. Une DNS Host Entry répond directement à un nom d’hôte précis avec une adresse IP sur le pare-feu. Une DNS Request Route redirige au contraire un domaine ou une zone vers un autre serveur DNS. Pour Active Directory et les zones internes dynamiques, une Request Route est presque toujours plus propre qu’une multitude de Host Entries individuelles.

Quel design DNS convient ?

Avant de créer un itinéraire de requête DNS, il est important de savoir quel résolveur est utilisé dans chaque réseau. L’itinéraire n’est utile que si Sophos Firewall voit également la requête.

• Les clients interrogent Sophos Firewall : le pare-feu redirige globalement les domaines publics et les domaines internes via une DNS Request Route. Cela convient bien aux petits et moyens sites, à DNS Protection ainsi qu’aux réseaux invités ou clients.
• Les clients interrogent directement les serveurs DNS internes : les Domain Controllers ou serveurs DNS résolvent en interne et redirigent vers l’extérieur. Cela convient aux réseaux Active Directory classiques avec Windows DNS comme résolveur central.
• Les clients VPN interrogent le pare-feu : le pare-feu utilise des Request Routes pour les domaines internes. Cela convient au Remote Access avec un chemin DNS simple via le pare-feu.
• Les clients VPN interrogent directement les serveurs DNS internes : le DNS passe par le VPN vers le Domain Controller ou le serveur DNS. Cela convient aux grands environnements AD lorsque les clients doivent utiliser la même logique DNS que dans le LAN.

Dans les environnements mixtes, un schéma DNS rapide est très utile : réseau client, serveur DNS assigné, domaine de recherche, zones DNS internes, itinéraires de requêtes DNS et chemin de routage vers le serveur cible. Sans cette vue d’ensemble, on travaille souvent sur l’itinéraire de requête alors que le client n’utilise même pas le pare-feu comme résolveur DNS.

Pour que les DNS Request Routes agissent pour les clients, Sophos Firewall doit se trouver dans le chemin de requête DNS. Cela peut être direct, si les clients reçoivent l’IP d’interface du pare-feu comme serveur DNS, ou indirect, si un résolveur interne redirige volontairement vers le pare-feu. Si les clients interrogent directement un Domain Controller, le pare-feu ne voit pas cette requête DNS comme résolveur et ne peut pas la rediriger via Request Route.

Quand a-t-on besoin d’itinéraires de requêtes DNS ?

Les itinéraires de requêtes DNS sont utiles lorsque :

• des noms d’hôtes internes comme server01.firma.local doivent être résolus
• les recherches inversées pour les réseaux IP internes doivent fonctionner
• les utilisateurs VPN doivent utiliser des noms internes
• plusieurs sites ont leurs propres zones DNS
• le pare-feu lui-même doit atteindre des systèmes internes via FQDN
• les serveurs DNS publics ne connaissent pas les noms internes

Sans itinéraire de requête DNS, le pare-feu interroge le serveur DNS globalement configuré. Si le domaine interne n’est pas connu là-bas, la résolution échoue.

Cette différence est particulièrement importante pour l’accès à distance. Si les clients VPN utilisent le pare-feu comme serveur DNS, un itinéraire de requête DNS peut garantir que les domaines internes aboutissent toujours au bon contrôleur de domaine ou serveur DNS. Si les clients VPN reçoivent directement des serveurs DNS internes, il faut également vérifier si le routage, les règles de pare-feu et les suffixes DNS sur le client sont corrects.

Prérequis

• Accès à l’interface WebAdmin de Sophos Firewall
• Sophos Firewall est correctement configuré comme résolveur DNS ou forwarder DNS sous Network > DNS > DNS configuration
• Serveur DNS interne accessible
• Domaine ou réseau connu
• Les règles de pare-feu autorisent le trafic DNS vers le serveur cible
• En cas de mise en réseau de site : le routage vers le serveur DNS fonctionne
• Le client concerné utilise soit le pare-feu comme serveur DNS, soit reçoit intentionnellement un autre serveur DNS

⚠️ Les problèmes DNS ressemblent souvent à des problèmes de routage, de VPN ou d’application. Avant de procéder à des modifications importantes, il est conseillé de vérifier si le serveur cible est accessible par IP et si seule la résolution de noms échoue.

Sous Network > DNS > DNS configuration, il faut aussi vérifier comment le pare-feu résout ses requêtes DNS normales. Si DNS Protection est utilisé, les adresses IP DNS Protection s’y trouvent. Si des forwarders classiques ou des résolveurs internes sont utilisés, ces serveurs doivent être joignables. Test name lookup permet de vérifier directement dans la configuration DNS si le pare-feu peut résoudre un nom ou une IP.

Configurer une DNS Request Route

La configuration est techniquement simple, mais devient vite confuse lorsque des domaines, zones inversées, clients VPN et plusieurs sites se combinent.

Créer un itinéraire de requête DNS pour un domaine

Un itinéraire de domaine garantit que les requêtes pour un domaine spécifique sont envoyées à un serveur DNS défini.

Exemple :

• Nom d’hôte/domaine : firma.local
• Serveur DNS : 10.10.10.10

Procédure :

1. Connectez-vous à Sophos Firewall.
2. Ouvrez Network.
3. Sélectionnez DNS.
4. Accédez à la section DNS request route.
5. Ajoutez un nouvel itinéraire de requête DNS.
6. Dans Host/domain name, entrez le domaine interne, par exemple firma.local.
7. Dans Target servers, sélectionnez le serveur DNS interne ou créez-le en tant qu’hôte via Create.
8. Enregistrez.

La valeur dans Host/domain name doit être écrite comme un FQDN ou un nom de zone, pas comme une URL, une règle wildcard ou une description libre. L’API Sophos traite cette valeur comme un champ FQDN avec une longueur maximale de 255 caractères. Pour une route de domaine normale, firma.local suffit par exemple ; pour les recherches inversées, utilisez la zone in-addr.arpa correspondante.

Si aucun hit du cache DNS n’existe sur le pare-feu, la requête correspondante pour ce domaine n’est pas envoyée aux forwarders normaux ou aux serveurs racine, mais aux Target Servers de la Request Route. C’est voulu : les zones internes ne doivent pas être demandées par erreur à l’extérieur. Cela signifie toutefois aussi qu’un Target Server mal choisi peut répondre correctement sur le plan technique, mais donner une réponse fonctionnellement incorrecte.

Utiliser plusieurs serveurs cibles

Dans Target servers, vous pouvez ajouter plus d’un serveur DNS. Cela est utile s’il y a plusieurs serveurs DNS internes ou si le DNS doit être accessible de manière redondante via une connexion de site.

Serveurs cibles possibles :

• Serveurs DNS internes dans le réseau local
• Serveurs DNS de l’autre côté d’une connexion VPN
• Serveurs DNS à un autre emplacement
• Serveurs DNS publics, si un domaine spécifique doit être résolu intentionnellement à l’externe

L’ordre est important. Le pare-feu interroge les hôtes sélectionnés dans l’ordre dans lequel ils apparaissent dans la liste. Jusqu’à huit adresses IP peuvent être enregistrées par itinéraire de requête DNS. Cependant, plus de serveurs cibles ne signifient pas automatiquement une meilleure redondance si les serveurs ont des états de zone différents, des redirections différentes ou une accessibilité différente via VPN.

Avec plusieurs serveurs cibles, il ne suffit pas d’entrer la redondance, mais il faut aussi vérifier la responsabilité. Si le premier serveur DNS connaît la zone mais fournit des entrées obsolètes, l’itinéraire de requête fonctionnera techniquement mais donnera néanmoins des réponses incorrectes.

Un NXDOMAIN est une réponse DNS valide. Si le premier serveur DNS joignable indique qu’un nom n’existe pas, le pare-feu ne demande pas automatiquement au serveur suivant dans l’espoir d’une autre réponse. Les Target Servers d’une même DNS Request Route doivent donc avoir le même état de zone et les mêmes forwardings.

DNS fractionné pour VPN et sites

Le DNS fractionné signifie que le même nom est résolu différemment selon l’emplacement ou le réseau. Un portail interne peut, par exemple, pointer vers une IP privée en interne, tandis que le même nom pointe vers une adresse publique ou n’est pas résolu du tout en externe.

Sur Sophos Firewall, trois points sont essentiels :

1. L’itinéraire de requête DNS approprié pour le domaine interne.
2. Une règle de pare-feu qui autorise le DNS du pare-feu ou du client vers le serveur DNS interne.
3. Un chemin de routage vers le serveur DNS, en particulier pour les VPN site-à-site, SSL VPN ou Sophos Connect.

Pour les environnements d’accès à distance, il est également conseillé de vérifier quels serveurs DNS et domaines de recherche le client reçoit. Pour Sophos Connect, consultez Configurer Sophos Connect sur Sophos Firewall. Pour les configurations SSL VPN classiques, consultez Configurer l’accès à distance SSL VPN sur Sophos Firewall.

Avec DNS Protection, une question de design supplémentaire apparaît : Sophos recommande de configurer les équipements réseau pour utiliser le pare-feu comme résolveur DNS. Pour cela, les serveurs DHCP du pare-feu distribuent normalement l’IP d’interface du pare-feu comme serveur DNS. Si des appareils utilisent tout de même des résolveurs externes, une règle NAT ciblée pour le trafic DNS sortant vers le pare-feu peut être planifiée. Cela doit être fait consciemment et non globalement, car les redirections DNS strictes peuvent influencer le dépannage, les appareils BYOD, DoH/DoT et les équipements spéciaux.

Si le pare-feu utilise lui-même DNS Protection comme forwarder, les adresses IP DNS Protection copiées depuis Sophos Central doivent être saisies sous Network > DNS > DNS configuration comme serveurs DNS primaire et secondaire. Un troisième serveur DNS différent ou un chemin DNS IPv6 involontaire peut faire passer des requêtes à côté de DNS Protection. Les DNS Request Routes, les options DNS DHCP, les paramètres DNS IPv6 et les règles NAT DNS optionnelles doivent donc être vérifiés comme une conception commune.

DNS inversé pour les réseaux internes

Un itinéraire de requête DNS inversé redirige les requêtes PTR pour un réseau IP interne vers le serveur DNS qui connaît la zone de recherche inversée appropriée. Cela aide lorsque les journaux, rapports ou services doivent convertir une adresse IP en un nom d’hôte.

Exemple :

• Réseau : 172.16.16.0/24
• Serveur DNS : 172.16.16.10
• Zone inversée : 16.16.172.in-addr.arpa

Pour les recherches inversées, créez également un itinéraire de requête DNS sous Network > DNS > DNS request route. Dans Host/domain name, entrez la zone inversée au lieu du domaine normal.

Exemple pour 172.16.16.0/24 :

16.16.172.in-addr.arpa

L’ordre des octets est inversé. Ainsi, le réseau 172.16.16.0/24 devient 16.16.172.in-addr.arpa. Important : ne pas saisir une notation CIDR comme 172.16.16.0/24 dans Host/domain name, mais une zone DNS. La valeur doit donc ressembler à un nom de domaine ou de zone inversée, pas à une description libre.

Pour les réseaux plus grands, la zone inversée peut être plus large. Exemple : pour 172.16.0.0/16, ce serait 16.172.in-addr.arpa. Ce qui est crucial, c’est comment la zone de recherche inversée est configurée sur le serveur DNS interne.

Si le serveur DNS interne ne possède pas de zone PTR ou d’enregistrements PTR, l’itinéraire de requête ne sera pas utile. Le pare-feu peut uniquement envoyer la requête au bon serveur DNS, mais il ne crée pas d’entrées DNS inversées sur le serveur DNS.

Dans les environnements IPv6 avec préfixe de fournisseur, il est également conseillé de penser au DNS dès le début. Comment les clients obtiennent leur adresse IPv6 et quel rôle jouent les annonces de routeur et DHCPv6 est expliqué dans Configurer la délégation de préfixe IPv6 sur Sophos Firewall.

Tests et exploitation

Après la configuration, il faut tester séparément l’accessibilité IP, la résolution DNS et le DNS client. Cela permet de voir plus vite si le problème vient réellement de la Request Route.

Tests et validation

Après la configuration, il est conseillé de tester la résolution de noms :

• Le pare-feu peut-il résoudre le nom interne ?
• Network > DNS > Test name lookup fonctionne-t-il pour un nom interne et un nom public ?
• La résolution fonctionne-t-elle depuis les zones VPN ou utilisateur ?
• Le serveur DNS est-il accessible par ping ou TCP/UDP 53 ?
• Y a-t-il des entrées dans le journal DNS ou le journal du pare-feu ?

Si la résolution ne fonctionne pas, il est conseillé de vérifier d’abord :

• Le domaine est-il correctement écrit ?
• Le client utilise-t-il vraiment Sophos Firewall ou le bon serveur DNS ?
• Une règle de pare-feu bloque-t-elle le DNS ?
• Une route vers le serveur DNS manque-t-elle ?
• Le serveur DNS répond-il aux requêtes du pare-feu ?

Un test judicieux sépare l’accessibilité IP et la résolution DNS :

1. Tester le système cible par IP, par exemple ping, port TCP ou application.
2. Atteindre le serveur DNS lui-même par IP.
3. Résoudre le nom via la source DNS attendue.
4. Ensuite, tester l’application via le nom.

Si l’accès par IP fonctionne, mais pas par nom, le problème se situe au niveau de l’itinéraire de requête DNS, du suffixe DNS, du DNS client ou de la recherche inversée. Si l’accès par IP échoue déjà, il est conseillé de vérifier d’abord le routage, la règle de pare-feu, le NAT ou le VPN. Pour cette délimitation, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture et La règle de Sophos Firewall ne s’applique pas : vérifier les causes.

Commandes de test pour le pare-feu et les clients

Sur Sophos Firewall, la console de l’appareil peut aider à tester le DNS du point de vue du pare-feu :

dnslookup server01.firma.local
dnslookup example.com

Sur les clients, il est également conseillé de vérifier quel résolveur est réellement utilisé.

Windows :

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS :

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux :

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> représente l’adresse de l’interface interne de Sophos Firewall dans le réseau concerné. Si la requête contre le pare-feu fonctionne, mais pas la requête normale du client, le problème se situe généralement au niveau de DHCP, du profil VPN, du suffixe DNS, du résolveur local ou du comportement DNS du navigateur/système. Si la requête contre le pare-feu échoue également, les prochains points à vérifier sont l’itinéraire de requête, le serveur cible, le routage ou la règle de pare-feu.

Pour les clients avec des navigateurs modernes ou des agents Endpoint, il faut aussi vérifier si DNS-over-HTTPS ou un agent de sécurité local contourne la requête DNS normale. Dans ce cas, le pare-feu peut ne voir aucune requête DNS classique sur UDP/TCP 53, même si la configuration réseau semble correcte.

Définir un test positif et un test négatif

Une DNS Request Route n’est correctement testée que si le nom interne souhaité fonctionne et qu’un contre-exemple a également été vérifié. Sinon, on ne sait pas si la route cible précisément la zone interne ou si DNS est redirigé trop largement.

Un petit plan de test suffit généralement :

• Test positif : un nom interne de la zone cible se résout vers l’IP privée attendue, par exemple server01.ad.firma.local.
• Test négatif : un domaine public non concerné continue à utiliser le chemin standard prévu, par exemple DNS global, DNS Protection ou un forwarder interne.
• Test client : exécuter le test depuis le VLAN, le profil VPN ou le site concerné, pas seulement directement sur le pare-feu.
• Contrôle des logs : le log firewall, le log DNS ou Packet Capture montre que la requête atteint le résolveur attendu.
• Régression : répéter le même test après une modification de VPN, DHCP, DNS Protection ou du routage de site.

Ce petit test négatif évite les effets de bord typiques : domaines publics résolus en interne, contournement de DNS Protection, Split-DNS fonctionnant seulement depuis certains réseaux ou client VPN utilisant encore un ancien résolveur.

Vérification opérationnelle

Les itinéraires de requêtes DNS doivent être aussi spécifiques que possible. Un itinéraire pour le domaine interne exact est préférable à une configuration trop large. Pour les environnements plus grands, un petit tableau avec le domaine, le serveur DNS, l’emplacement et l’objectif est utile pour que les modifications ultérieures soient traçables.

Documentation pratique :

• Domaine ou zone inversée: ad.firma.local
• Target Servers: 10.10.10.10, 10.10.10.11
• Objectif: DNS Active Directory pour le site principal.
• Réseaux concernés: LAN, VPN admin, site de Zurich.
• Dépendances: VPN site-à-site, contrôleur de domaine, règle de pare-feu DNS.
• Test: server01.ad.firma.local se résout en IP interne attendue.
• Test négatif: par exemple, example.com continue à utiliser le chemin standard prévu.

Dépannage

Si DNS ne fonctionne pas, il ne faut pas modifier directement la Request Route. Souvent, le client utilise un autre résolveur, une règle de pare-feu bloque DNS ou la zone inversée n’existe pas sur le serveur cible.

Erreurs typiques

• Le nom interne ne se résout pas: le domaine est souvent incorrect, par exemple firma.local au lieu de ad.firma.local. Vérifier le domaine dans la Request Route et le domaine de recherche du client.
• Le client VPN ne résout pas les noms internes: le client n’utilise peut-être pas le pare-feu ou utilise le mauvais serveur DNS. Vérifier les paramètres DNS du VPN, le DNS client et la règle de pare-feu.
• Le pare-feu ne peut pas atteindre le serveur DNS: une route, un VPN ou une règle de pare-feu manque probablement. Vérifier avec Ping, Packet Capture et Route Lookup.
• Le pare-feu résout en externe, mais pas en interne: vérifier la DNS Request Route, le Target Server et Test name lookup. Utiliser ensuite Packet Capture vers le serveur DNS interne.
• La recherche inversée ne fonctionne pas: Zone PTR ou enregistrements PTR manquants Vérifier la zone de recherche inversée sur le serveur DNS interne.
• Certains sites fournissent des réponses incorrectes: un Target Server incorrect ou des données de zone obsolètes sont probables. Vérifier l’ordre des Target Servers et la réplication DNS.
• Les noms publics sont soudainement résolus en interne: la Request Route est trop large. Utiliser un domaine plus spécifique et éviter la logique wildcard.
• Le premier serveur DNS répond NXDOMAIN: le pare-feu traite cette réponse comme valide et ne demande pas automatiquement à tous les autres Target Servers. Vérifier l’état des zones et l’ordre des serveurs.
• DNS Protection ne s’applique pas à tous les clients: vérifier si les clients utilisent réellement le pare-feu comme résolveur DNS ou si des résolveurs externes, DoH/DoT, agents locaux ou paramètres DNS manuels sont en cause.

Dans les environnements VPN, il est également conseillé de vérifier si les clients VPN reçoivent les bons serveurs DNS et domaines de recherche.

FAQ