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.

Une réponse locale correspondante évite une requête supplémentaire au DNS faisant autorité pour cette demande et peut accélérer la résolution. Elle ne garantit pas un temps de réponse précis et n’aide pas un client dont la requête contourne le résolveur du pare-feu.

Les champs Host Entry sont documentés pour SFOS 22.0 et 23.0 ; cela ne prouve pas qu’ils ont été testés sur un build précis. SFOS 23 distingue le DNS non chiffré, DNS over HTTPS (DoH) et DNS Protection pour la résolution externe. L’article sur les DNS Request Routes explique le choix global des résolveurs, l’obtention du DNS par DHCP/PPPoE et la distinction entre DNS Protection traditionnel et le parcours intégré de SFOS 23. Il n’est pas nécessaire de reconstruire la configuration globale pour un seul nom local.

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 (SFOS 22) / Test name resolution (SFOS 23).
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. L’inbound load balancing d’un même nom accepte au maximum huit adresses ; le pare-feu prend en charge jusqu’à 1024 DNS Host Entries au total.

Chemins et portée de la résolution DNS

Pour les requêtes traitées par le pare-feu lui-même, les configurations suivantes s’appliquent :

• Si le nom demandé correspond à une DNS host entry, le pare-feu répond avec l’adresse qui y est enregistrée.
• Si une DNS request route correspond, le pare-feu interroge ses Target servers dans l’ordre après un échec de recherche dans le cache. Pour ce nom, il ne revient pas aux forwarders ni aux serveurs racine.
• En l’absence d’entrée locale ou de Request Route correspondante, il utilise les serveurs définis sous DNS configuration. Les serveurs statiques sont interrogés dans l’ordre jusqu’à réception d’une réponse. NXDOMAIN est déjà une réponse valide ; le serveur suivant n’est alors pas interrogé.

L’aide de SFOS 22 décrit séparément la correspondance des Host Entries et des Request Routes, mais ne précise pas le résultat lorsque le même nom correspond aux deux. Il faut éviter ce chevauchement : conserver la Host Entry en dehors d’une zone transférée ou supprimer l’entrée locale en double. Interroger ensuite explicitement l’adresse IP du pare-feu pour confirmer la réponse attendue.

Ces chemins de résolution ne s’appliquent que lorsque le pare-feu est le résolveur de la requête. Un client qui utilise directement un contrôleur de domaine, un résolveur public ou DNS over HTTPS contourne ces entrées. Sous Administration > Device access, DNS doit aussi être autorisé pour la zone source ou par une Local Service ACL Exception adaptée ; une règle de pare-feu ordinaire ne contrôle pas l’accès à ce service local.

Les serveurs DNS configurés ont priorité sur les serveurs racine pour la résolution DNS générale via l’IP d’une interface du pare-feu. Cela ne garantit pas que toute requête infructueuse sera résolue via les serveurs racine. Les requêtes correspondant à une Request Route restent dirigées vers les Target Servers définis.

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

Sous Network > DNS, utiliser d’abord Test name lookup (SFOS 22) / Test name resolution (SFOS 23) pour vérifier que le pare-feu renvoie l’adresse attendue pour app01.corp.example. Diagnostics > Tools > Name lookup (SFOS 22) interroge au contraire un DNS server IP sélectionné ; Lookup using all configured servers compare les serveurs DNS configurés et leurs temps de réponse. Utiliser cet outil uniquement pour comparer les serveurs upstream, et non pour prouver qu’une Host Entry locale ou une Request Route a été sélectionnée. 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.

Dans SFOS 23, la section de diagnostic est DNS lookup, avec Hostname or IP address, DNS server IP address et All configured servers. Custom DNS server et Custom DoH server interrogent l’IP du serveur indiqué ; DNS Protection n’est disponible que s’il est activé sous Network > DNS. Pour un nom de test interne, sélectionner uniquement un résolveur interne approuvé afin de ne pas exposer le nom à un service DNS ou DoH public. Ces options de diagnostic ne prouvent pas qu’une entrée locale a été sélectionnée ; la requête explicite depuis le client décrite ci-dessous reste nécessaire.

Pour le test SFOS 23 sous Network > DNS > Test name resolution, saisir le FQDN ou l’adresse dans Hostname or IP address, puis sélectionner Test connection. Le résultat indique le serveur DNS utilisé, le protocole, le statut de résolution et les temps de réponse ; comparer ces informations au chemin de résolution prévu. Le test depuis le client reste une étape distincte :

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

Pour une transmission au support ou une comparaison avant/après, dnsd.log peut également être téléchargé sous Diagnostics > Tools > Troubleshooting logs. Un Consolidated troubleshooting report (CTR) contient en plus des données d’état et de journalisation. Ces fichiers pouvant contenir des détails de configuration et d’environnement, ils ne doivent être transmis que par un canal de support sécurisé.

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.

⚠️ Ne pas combiner pondération et DNAT sans clarifier l’architecture : L’aide Host Entry décrit Weight par rapport à WAN link manager, tandis que le parcours Multi-WAN lie la réponse à l’interface WAN d’entrée. L’aide DNAT interdit également une règle DNAT associée au weighted load balancing pour la même DNS Host Entry. Ces indications ne prouvent ni une proportion précise de réponses DNS ni le bon fonctionnement d’une architecture DNAT combinée. Si le service public dépend de cette combinaison, arrêter avant la publication WAN et clarifier l’architecture pour la version installée ; ne pas supposer que d’autres poids constituent un contournement.

Pour deux adresses WAN, conserver le même nom dans une seule Host Entry : saisir, par exemple, www.example.com sous Host/Domain name et 192.0.2.10 comme première IP address, puis utiliser Add dans le formulaire pour ajouter une seconde adresse et saisir 198.51.100.10. Ces adresses sont des valeurs de documentation à remplacer par les adresses WAN réelles. N’activer Publish on WAN pour les deux adresses prévues que si les conditions de la section suivante sont remplies, puis enregistrer avec Save. Deux noms d’hôtes différents ne permettraient pas de répartir la charge d’un même service.

Dans le déroulement Multi-WAN documenté, le résolveur externe suit la délégation NS et interroge le pare-feu via un lien WAN actif. Le pare-feu renvoie l’adresse WAN de l’interface par laquelle cette requête est arrivée, puis le résolveur transmet cette adresse au client. L’accès ultérieur à l’application constitue un flux de données distinct. Lors de la validation, interroger séparément les deux chemins WAN et comparer les adresses renvoyées ; après une panne de lien, effectuer une nouvelle requête DNS. Cela ne supprime pas les réponses déjà en cache avant l’expiration de leur TTL.

Weight est le poids relatif du lien par rapport aux autres liens du WAN link manager. Il ne constitue pas un Health Check applicatif. Lors de la validation, de nouvelles requêtes DNS externes ne doivent renvoyer que des adresses WAN actives ; il faut ensuite tester une nouvelle connexion applicative pour chaque adresse renvoyée. Une réponse 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.

Selon Sophos, une règle DNAT et le weighted load balancing ne peuvent pas être configurés simultanément pour la même DNS Host Entry. La publication exige donc 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.

Un nom reste trop longtemps en cache comme localhost

Pour les domaines qui se résolvent vers localhost, Sophos Firewall n’utilise pas simplement la TTL de l’enregistrement DNS. Le pare-feu interroge à nouveau ces noms selon l’intervalle localhost-ttl. La valeur par défaut est de 655360 secondes et la plage autorisée va de 60 à 655360 secondes. Lorsqu’un enregistrement passe de localhost à un autre hôte, le pare-feu peut donc conserver l’ancienne réponse plus longtemps qu’un client normal.

Il faut d’abord confirmer, par une requête directe au resolver autoritatif ou prévu, que l’enregistrement ne pointe plus vers localhost. Lire ensuite la valeur SFOS actuelle dans la Device Console :

show dns

⚠️ Avant de modifier l’intervalle, conserver la valeur initiale lue avec show dns et garder un accès de gestion indépendant. La modification est globale, et non limitée à cette Host Entry. Une valeur plus faible génère davantage de requêtes DNS et ne vide pas immédiatement le cache.

Ce n’est que si ce cas précis est confirmé qu’il convient de réduire temporairement l’intervalle global. Les 300 secondes constituent ici un exemple pour un test de migration contrôlé, et non une recommandation générale :

set dns localhost-ttl 300

Après la modification, vérifier show dns et tester à nouveau la résolution depuis le pare-feu et un client réel. Ne rétablir la valeur par défaut du produit de cette manière que si elle était utilisée auparavant :

set dns localhost-ttl default

Si l’intervalle était personnalisé, utiliser plutôt set dns localhost-ttl <previous-seconds> et remplacer <previous-seconds> par le nombre conservé ; ne pas saisir le marqueur littéralement. Vérifier ensuite la valeur rétablie avec show dns et la résolution par une nouvelle requête. Si la valeur initiale est inconnue, default n’est pas un retour arrière vérifié.

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.

API XML : nom d’objet et nom DNS à partir de SFOS 23

Pour l’automatisation, Name et HostName sont deux champs distincts : Name désigne l’objet configuré, HostName le nom DNS à résoudre. La documentation de SFOS 23 exige les deux champs lors de la création et de la modification. Name est une valeur STRING unique de 64 caractères maximum ; UTF-8 est autorisé, mais pas la virgule. HostName reste de type DOMAINNAMELOOKUP, avec un maximum de 253 caractères. Par exemple, Name = app01-intern et HostName = app01.corp.example peuvent avoir des valeurs différentes ; il s’agit d’une correspondance de champs, et non de XML exécutable.

Pour la suppression, SFOS 22 documente HostName comme clé, tandis que SFOS 23 utilise Name. Ne pas rejouer telles quelles les anciennes requêtes SFOS 22 et ne pas utiliser automatiquement le nom DNS comme nom d’objet. Avant tout appel de suppression, vérifier la version installée, lire l’objet concerné et comparer son nom d’objet, son nom DNS, ses adresses et ses dépendances avec la cible documentée. Si l’identité est ambiguë, arrêter l’opération. Vérifier ensuite la réponse de l’API et son statut, puis relire la cible exacte : seul l’objet prévu doit être absent ; les autres entrées doivent rester inchangées. Une réussite du transport ne prouve pas à elle seule que la suppression a réussi. Aucune enveloppe de suppression n’est fournie ici et aucun test sur le produit n’est revendiqué.

Conflit non résolu concernant le DNS inverse : dans les deux versions, l’exemple d’API indique Enable/Disable pour AddReverseDNSLookUp, mais le tableau des paramètres n’autorise que Enable tout en indiquant Disable comme valeur par défaut. Cela ne permet pas de déduire une requête sûre utilisant Disable ou omettant le champ. Ne pas utiliser une telle recette d’API tant que le fabricant n’a pas clarifié ce point ; configurer plutôt Reverse DNS délibérément dans la procédure WebAdmin décrite plus haut et vérifier le PTR séparément. La procédure dans l’interface ne confirme pas la sémantique des valeurs d’énumération de l’API.

Les limites documentées suivantes s’appliquent aussi à la validation des champs XML dans SFOS 22 et 23 ; elles ne garantissent pas les valeurs par défaut de WebAdmin :

• Au maximum huit éléments Address par AddressList. IPFamily, EntryType, IPAddress, TTL, Weight et PublishOnWAN sont documentés comme obligatoires pour Add/Edit ; leurs valeurs dans le tableau sont des arrays et les doublons ne sont pas ignorés.
• IPFamily : IPv4 ou IPv6 ; EntryType : Manual ou InterfaceIP. Pour InterfaceIP, l’exemple XML attend le nom de l’interface dans IPAddress, et non une adresse IP fixe.
• IPAddress est de type STRING ; le tableau exclut les classes MULTICAST, RESERVED, UNSPECIFIED, BROADCAST et LINKLOCAL. Ne pas reprendre les adresses de documentation de cet article dans un appel API de production sans les valider.
• TTL est un INTEGER de 1 à 604800 secondes, avec six chiffres au maximum ; le tableau indique 3600 par défaut. Renseigner néanmoins explicitement ce champ obligatoire. Weight est un INTEGER de 0 à 255, avec trois chiffres au maximum ; cette limite ne prouve pas un effet particulier du poids 0.
• PublishOnWAN autorise Enable ou Disable. Ces valeurs non ambiguës ne doivent pas être appliquées par analogie à la définition contradictoire de AddReverseDNSLookUp décrite plus haut.

Les tableaux de statut distinguent Add, Edit et Delete, mais n’expliquent pas tous les codes d’erreur indiqués. En cas d’erreur, conserver la réponse API complète et l’état actuel de l’objet avant de répéter un appel qui le modifie ; ne déduire ni une réussite ni une cause du seul transport HTTP.

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