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 réseaux. 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 n’ont de sens que lorsque le comportement DNS attendu et les serveurs DNS responsables sont clairement définis.

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 DNS Internet, résolution FQDN générale, mises à jour et services cloud.
Itinéraire de requête DNS: envoyer un domaine spécifique ou une zone inversée à un serveur DNS défini Active Directory, domaines internes, DNS de site, DNS fractionné.
Option DHCP: distribuer des serveurs DNS ou des domaines de recherche aux clients Les clients doivent utiliser directement un serveur DNS spécifique.

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.

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 les domaines publics globalement et les domaines internes via un itinéraire de requête DNS Petits et moyens sites, protection DNS, réseaux invités/clients.
Les clients interrogent directement les serveurs DNS internes: Le contrôleur de domaine ou le serveur DNS résout en interne et redirige en externe Réseaux Active Directory classiques avec Windows DNS comme résolveur central.
Les clients VPN interrogent le pare-feu: Le pare-feu utilise des itinéraires de requêtes pour les domaines internes Accès à distance avec chemin DNS simple via le pare-feu.
Les clients VPN interrogent directement les serveurs DNS internes: Le DNS passe par le VPN vers le contrôleur de domaine ou le serveur DNS Grandes 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.

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
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.

Configurer une DNS Request Route

La route définit quels serveurs DNS sont interrogés pour un domaine ou une zone reverse spécifique.

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 :

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

Ensuite, le pare-feu interrogera le serveur DNS spécifié pour ce domaine.

Sophos Firewall - Ajouter un itinéraire de requête DNS avec un serveur DNS interne — Sophos Firewall - Network > DNS > Add DNS request route

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.

Sophos Firewall - Vue d'ensemble d'un itinéraire de requête DNS pour avanet.local — Sophos Firewall - Network > DNS > DNS request route

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.

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 :

L’itinéraire de requête DNS approprié pour le domaine interne.
Une règle de pare-feu qui autorise le DNS du pare-feu ou du client vers le serveur DNS interne.
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.

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.

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

Les modifications DNS doivent toujours être vérifiées depuis la firewall et depuis de vrais clients.

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 ?
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 :

Tester le système cible par IP, par exemple ping, port TCP ou application.
Atteindre le serveur DNS lui-même par IP.
Résoudre le nom via la source DNS attendue.
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.

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
Serveurs cibles: 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.

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 la firewall.
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.

Test négatif : par exemple, example.com continue à utiliser le chemin standard prévu.

Dépannage

Si le résultat attendu manque, il faut vérifier pas à pas les logs, le matching des règles et le comportement des policies.

Erreurs typiques

Le nom interne ne se résout pas: Domaine incorrect, par exemple firma.local au lieu de ad.firma.local Vérifier le domaine dans l’itinéraire de requête et le domaine de recherche du client.
Le client VPN ne résout pas les noms internes: Le client n’utilise pas le pare-feu ou 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: Route, VPN ou règle de pare-feu manquante Vérifier le ping, la capture de paquets et la recherche de route.
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: Serveur cible incorrect ou données de zone obsolètes Vérifier l’ordre des serveurs cibles et la réplication DNS.
Les noms publics sont soudainement résolus en interne: L’itinéraire de requête est trop large Utiliser un domaine plus spécifique et éviter la pensée en termes de joker.

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

Quand a-t-on besoin d'un itinéraire de requête DNS sur Sophos Firewall ?

Un itinéraire de requête DNS est utile lorsque certains domaines ou zones inversées ne doivent pas être résolus via les serveurs DNS globaux du pare-feu, mais via des serveurs DNS internes. Les cas typiques incluent Active Directory, les applications internes, le VPN et la mise en réseau de site.

Un itinéraire de requête DNS remplace-t-il les options DHCP DNS ?

Non. Un itinéraire de requête DNS contrôle la redirection de certaines requêtes DNS. Les options DHCP distribuent quant à elles des serveurs DNS ou des domaines de recherche aux clients. Selon le design, les deux fonctions sont combinées.

Pourquoi le DNS ne fonctionne-t-il pas via VPN bien que l'itinéraire de requête existe ?

Dans ce cas, le client VPN n’utilise peut-être pas la source DNS attendue, n’a pas de domaine de recherche approprié, n’atteint pas le serveur DNS ou est bloqué par le routage et les règles de pare-feu. Il est conseillé de vérifier séparément si l’accès par IP fonctionne et si la requête DNS aboutit vraiment au bon serveur.

A-t-on besoin d'itinéraires de requêtes DNS pour les recherches inversées ?

Oui, si les requêtes PTR pour les réseaux internes doivent aller à un serveur DNS interne. Pour cela, la zone in-addr.arpa appropriée est entrée comme nom d’hôte/domaine. La zone doit cependant exister sur le serveur DNS interne.

A-t-on besoin d'itinéraires de requêtes DNS avec Sophos DNS Protection ?

Oui, si les clients ou le pare-feu doivent résoudre des domaines internes. DNS Protection ne connaît pas les zones AD locales, les domaines d’applications internes et les zones inversées. Ces requêtes doivent être dirigées vers des serveurs DNS internes via un itinéraire de requête DNS.

Pourquoi le pare-feu ne voit-il pas la requête DNS ?

La plupart du temps, le client n’utilise pas Sophos Firewall comme serveur DNS. Dans ce cas, les itinéraires de requêtes DNS sur le pare-feu n’aident pas directement. Il est conseillé de vérifier les options DHCP, le profil VPN, les paramètres DNS manuels du client, les relais DNS internes et les résolveurs alternatifs.