Configurer et tester les DNS Host Entries sur Sophos Firewall

Une DNS Host Entry permet à Sophos Firewall de répondre directement à un nom d’hôte précis avec une adresse IP configurée. Cette méthode convient à quelques systèmes internes fixes, par exemple une appliance, un service de gestion ou un nom de serveur que le pare-feu doit lui-même résoudre.

L’entrée n’agit que si la requête DNS parvient réellement au pare-feu. Si un client utilise un contrôleur de domaine, un résolveur public ou DNS over HTTPS, le pare-feu ne voit pas cette requête en tant que résolveur DNS. Une DNS Host Entry ne remplace pas non plus un objet de règle, le routage, le NAT ou une règle de pare-feu.

⚠️ Publish on WAN reste désactivé pour les entrées internes. Une publication publique exige une architecture DNS autoritative volontaire, des enregistrements NS adaptés, un Device Access strictement limité et un test de récursion négatif. Une autorisation DNS ACL depuis WAN ne justifie pas à elle seule l’exposition publique du service DNS.

DNS Host Entry en huit étapes

1. Confirmer que le nom est statique et qu’il n’est pas nécessaire de transférer une zone DNS interne entière.
2. Vérifier que les clients concernés utilisent réellement Sophos Firewall comme serveur DNS.
3. Documenter le FQDN, l’adresse cible, la version IP, le TTL et un éventuel enregistrement PTR.
4. Saisir le nom et l’adresse sous Network > DNS > DNS host entry > Add.
5. Laisser Publish on WAN désactivé pour une entrée interne.
6. Vérifier la vue du pare-feu sous Network > DNS > Test name lookup.
7. Depuis le client, interroger explicitement l’adresse IP du pare-feu et tester la résolution directe ainsi que, si nécessaire, la résolution inverse.
8. Tester seulement ensuite l’application réelle et documenter l’entrée et ses dépendances.

Quand utiliser une DNS Host Entry

Une DNS Host Entry convient à un nom unique et stable dont la réponse doit être gérée directement sur le pare-feu. Exemples courants :

• une appliance interne dépourvue de son propre enregistrement DNS ;
• un FQDN de gestion fixe pour LDAP, RADIUS ou un autre service ;
• un nom d’hôte unique pour une migration contrôlée ;
• un service public avec un inbound DNS load balancing volontairement planifié sur plusieurs adresses WAN.

Pour un domaine complet, Active Directory ou des zones internes mises à jour dynamiquement, une DNS Request Route est plus propre. Elle transfère la zone vers le serveur DNS responsable au lieu de gérer chaque nom individuellement sur le pare-feu.

Un IP Host ou un FQDN Host répond également à un autre besoin. Ces objets sont utilisés dans les règles de pare-feu et de NAT ; ils ne répondent pas à la requête DNS d’un client. Utiliser correctement les IP Hosts, Services et Groups explique ces types d’objets.

Une configuration Dynamic DNS met en revanche à jour un nom chez un fournisseur externe lorsque l’adresse WAN change. La procédure complète figure dans Configurer Dynamic DNS sur Sophos Firewall.

SFOS prend en charge les types d’enregistrements A, AAAA et PTR pour les DNS Host Entries. Cette fonction n’est donc pas un serveur DNS autoritatif complet pour CNAME, MX, TXT ou SRV. Une DNS Host Entry peut contenir au maximum huit adresses ; le pare-feu prend en charge jusqu’à 1024 DNS Host Entries au total.

Exemple et valeurs à remplacer

L’exemple représente un seul serveur applicatif interne :

• Nom d’hôte : app01.corp.example
• Adresse IPv4 : 192.0.2.20
• Réseau client : 10.20.30.0/24
• Adresse IP du pare-feu comme serveur DNS : 10.20.30.1
• Client de test : 10.20.30.50
• TTL : 300 secondes
• Publish on WAN : désactivé
• Reverse DNS : activé en option

La zone .example et le réseau 192.0.2.0/24 sont réservés à la documentation. Dans un environnement de production, le FQDN, l’adresse, le réseau client et l’adresse IP du résolveur sont remplacés par les valeurs réelles. Le nom doit correspondre à la stratégie de nommage interne et ne doit pas remplacer involontairement une zone autoritative existante.

Le TTL de 300 secondes est une valeur d’exemple contrôlée pour les tests et les migrations, et non une recommandation universelle. Un TTL court accélère les changements planifiés, mais génère davantage de requêtes DNS. Un TTL long réduit les requêtes, mais maintient les anciennes réponses plus longtemps dans les caches après une modification.

Ajouter la DNS Host Entry

Sous Network > DNS, faire défiler jusqu’à DNS host entry et sélectionner Add :

1. Saisir app01.corp.example sous Host/Domain name.
2. Utiliser une adresse IP comme Entry type.
3. Saisir 192.0.2.20 sous IP address.
4. Saisir 300 sous Time-to-live.
5. Ne pas traiter Weight comme un outil d’équilibrage de charge lorsqu’une seule adresse est présente.
6. Laisser Publish on WAN désactivé.
7. Activer Add reverse DNS lookup for this host entry uniquement si le pare-feu doit également renvoyer une réponse PTR pour cette adresse.
8. Enregistrer avec Save.

Pour une adresse IPv4, le pare-feu renvoie une réponse A ; pour une adresse IPv6, il renvoie une réponse AAAA. La résolution inverse facultative associe à nouveau l’adresse au nom sous forme de PTR. Elle ne crée cependant aucun enregistrement PTR sur un contrôleur de domaine ou un serveur DNS externe.

Si plusieurs noms d’hôtes pointent vers la même adresse IP, un seul peut servir de cible inverse. Avant d’activer l’option, il faut donc déterminer quel nom est attendu comme réponse PTR canonique.

Utiliser une interface plutôt qu’une adresse fixe

Une interface peut être sélectionnée comme Entry Type au lieu d’une adresse IP fixe. Ce choix convient lorsque la réponse doit volontairement suivre l’adresse actuelle de cette interface, par exemple dans une architecture Multi-WAN publique planifiée.

La sélection d’une interface ne remplace pas la vérification du chemin WAN réel. Après un changement d’adresse, une bascule de lien ou un failover HA, la réponse DNS, le service accessible et le chemin retour doivent être à nouveau testés avec une nouvelle connexion.

Tester la résolution sur le pare-feu et le client

Vérifier d’abord sous Network > DNS > Test name lookup que le pare-feu renvoie l’adresse attendue pour app01.corp.example. Si Reverse DNS est activé, interroger également 192.0.2.20.

Ce test confirme uniquement la vue du résolveur du pare-feu. Le client concerné doit ensuite interroger explicitement l’adresse IP 10.20.30.1 du pare-feu.

Windows :

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux ou macOS :

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

La réponse doit contenir l’enregistrement attendu, la bonne adresse et, pour la résolution inverse, le nom prévu. Tester ensuite l’application via son FQDN. Une réponse DNS correcte ne prouve pas encore le bon fonctionnement du routage, de la règle de pare-feu, du NAT, du certificat TLS et du service.

S’il n’est pas certain que la requête atteigne le pare-feu, utiliser un filtre précis sous Diagnostics > Packet capture, par exemple :

host 10.20.30.50 and port 53

La requête et la réponse doivent être visibles sur l’interface attendue. Packet Capture sur Sophos Firewall explique en détail la capture et l’analyse en toute sécurité.

Utiliser plusieurs adresses et pondérations volontairement

Une DNS Host Entry peut contenir jusqu’à huit adresses. Cette fonction est destinée à l’inbound DNS load balancing ou au failover sur plusieurs liens WAN, et non à une collection aléatoire de serveurs internes.

Les valeurs Weight déterminent la proportion selon laquelle les réponses sont réparties entre les liens indiqués. Ce comportement doit être vérifié par des requêtes DNS répétées et de véritables connexions applicatives. La répartition des réponses DNS ne confirme à elle seule ni la disponibilité du service publié ni la validité du DNAT et du chemin retour.

Plusieurs adresses ne constituent pas automatiquement un Health Check général des applications internes. Pour une architecture publique, Sophos documente le failover d’une interface inaccessible ou hors service. Cela ne garantit pas qu’une interface WAN accessible fournisse correctement le service applicatif situé derrière elle.

Weighted DNS et la configuration DNAT générée par Server Access Assistant ne doivent pas être planifiés simultanément comme un mécanisme commun pour la même DNS Host Entry. La publication exige une architecture cohérente comprenant la réponse DNS, l’adresse WAN, le DNAT, la règle de pare-feu, TLS et le chemin retour. Publier un serveur avec DNAT décrit séparément le chemin des données.

Utiliser Publish on WAN uniquement pour les architectures autoritatives

Publish on WAN ne suffit pas à lui seul pour fournir une réponse publique. Pour que Sophos Firewall réponde comme Name Server d’un service publié, la zone autoritative doit être déléguée à des noms de serveurs DNS dont les enregistrements A/AAAA ou glue pointent vers les adresses WAN prévues.

Les conditions suivantes sont également nécessaires :

1. Le domaine public et la zone DNS responsable sont clairement documentés.
2. La délégation NS et les enregistrements d’adresse ou glue associés mènent aux adresses WAN prévues.
3. Sous Administration > Device access, DNS n’est autorisé que via la zone WAN nécessaire ou une Local Service ACL Exception restrictive.
4. Publish on WAN est activé uniquement pour les adresses prévues.
5. Le nom publié est testé positivement depuis un résolveur externe.
6. Les noms non autoritatifs et les requêtes récursives font l’objet de tests négatifs depuis l’extérieur.
7. Le DNAT, la règle de pare-feu, le certificat et le chemin retour du service réel sont validés séparément.

Une exception DNS ACL supplémentaire ne restreint pas une autorisation de zone WAN étendue déjà active. Soit DNS reste désactivé pour WAN dans la matrice et est autorisé par une exception ciblée, soit l’autorisation plus large est documentée comme une exposition volontaire. Device Access et Local Service ACL explique comment gérer cette couche sans risquer de verrouillage administratif.

Si la délégation, l’étendue des réponses ou la protection contre l’utilisation récursive ne peuvent pas être clairement vérifiées, Publish on WAN n’est pas activé. Pour les zones DNS publiques ordinaires, un service DNS autoritatif dédié est généralement la solution la plus claire.

Isoler les erreurs par symptôme

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

• Vérifier quel serveur DNS est réellement configuré sur le client. DHCP peut distribuer l’adresse IP du pare-feu ; la procédure est décrite dans Configurer DHCP Server sur Sophos Firewall.
• Vérifier DNS over HTTPS, les paramètres du client VPN et les résolveurs statiques du client comme chemins alternatifs.
• Sous Administration > Device access, vérifier si DNS est autorisé depuis la zone du client.
• Utiliser Packet Capture pour confirmer que la requête et la réponse traversent le pare-feu.
• Ne pas modifier le routage ou le NAT tant que le client n’interroge pas du tout le pare-feu.

Le client reçoit encore l’ancienne adresse

• Vérifier l’entrée actuelle afin de détecter les fautes de frappe, les noms d’hôtes en double et les adresses multiples.
• Tenir compte de l’ancien TTL encore valide et des caches locaux, de navigateur ou d’application.
• Envoyer une nouvelle requête explicite à l’adresse IP du pare-feu plutôt que de simplement recharger l’application.
• Avant une migration planifiée, réduire suffisamment tôt le TTL et attendre l’expiration complète du TTL précédent.

Vider un cache peut corriger un client de test isolé, mais ne modifie pas les réponses présentes dans d’autres résolveurs ou caches d’application. Cette action ne remplace donc ni un délai contrôlé ni un test sur la chaîne DNS réellement utilisée.

La résolution inverse manque ou affiche le mauvais nom

• Vérifier que Add reverse DNS lookup for this host entry est activé.
• S’assurer que plusieurs noms ne revendiquent pas la même adresse comme cible PTR.
• Envoyer explicitement la requête inverse à l’adresse IP du pare-feu.
• Pour une zone inverse interne hébergée sur un contrôleur de domaine, utiliser la DNS Request Route correspondante plutôt qu’une entrée PTR locale.

La requête publique ne reçoit aucune réponse

• Vérifier depuis l’extérieur la délégation NS et l’accessibilité des adresses WAN.
• Vérifier Publish on WAN pour chaque adresse prévue.
• Contrôler Device Access, Local Service ACL, les filtres en amont ainsi que le port 53 en UDP et TCP.
• Enregistrer un Packet Capture pendant une requête externe précise.
• Ne pas activer une autorisation DNS étendue comme tentative de correction.

DNS est correct, mais l’application reste inaccessible

DNS fournit uniquement l’adresse de destination. Viennent ensuite le routage, la règle de pare-feu, le NAT, TLS et le service réel. Le test doit donc vérifier successivement l’adresse IP, le port et le protocole applicatif. Pour les problèmes de règle et de chemin, voir Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Modifications, HA et rollback

Avant une modification, documenter le nom, la réponse actuelle, le TTL, la résolution inverse, les résolveurs utilisés par les clients et les services dépendants. Pour plusieurs adresses, intégrer également à l’état initial la pondération, l’association WAN, la délégation NS, le DNAT et le chemin retour.

Dans un cluster HA, effectuer une nouvelle requête DNS après un failover planifié. Pour une publication publique, tester également les deux chemins WAN et un nouveau flux applicatif. Cet article ne suppose ni la synchronisation des caches DNS ni le maintien sans interruption d’une connexion active.

Pour le rollback :

1. Avant une migration planifiée, réduire le TTL et attendre l’expiration du TTL précédent.
2. Documenter les applications dépendantes et le chemin DNS public.
3. Restaurer l’adresse, l’interface ou la Host Entry à l’état initial confirmé.
4. Supprimer toute exception Device Access temporaire et toute publication WAN devenue inutile.
5. Interroger à nouveau explicitement depuis le pare-feu et le client.
6. Retester la résolution directe, le PTR facultatif, l’accessibilité et l’application réelle.

Checklist

• Sophos Firewall voit la requête DNS du client concerné.
• Un nom statique unique convient mieux qu’une DNS Request Route.
• Le FQDN, la version IP, l’adresse et le TTL sont documentés.
• Publish on WAN reste désactivé pour les entrées internes.
• Une entrée PTR n’est activée que pour le nom canonique de l’adresse.
• Le pare-feu et le client renvoient la même réponse attendue.
• L’accès DNS est limité aux sources nécessaires dans Device Access.
• Pour plusieurs adresses, la pondération, l’état des liens et le chemin applicatif ont été testés.
• Pour la publication WAN, la délégation NS, les adresses des serveurs DNS et un test de récursion négatif sont documentés.
• Le rollback et le délai d’attente des caches sont connus avant la modification.

Questions fréquentes