GUIDE EXPLOITATION · DNS
Fiabiliser le DNS pour éviter une panne invisible des applications.
Une connexion Internet peut fonctionner alors que les utilisateurs ne parviennent plus à ouvrir leurs services. Le DNS traduit des noms en adresses et porte aussi des dépendances de messagerie, de découverte et d’authentification. Ses différentes fonctions nécessitent des responsabilités explicites.
Par où commencer pour rendre le DNS plus fiable ?
Cartographiez les noms internes et publics, les résolveurs utilisés, les serveurs faisant autorité et les comptes permettant de les modifier. Testez résolution et accès applicatif depuis chaque contexte : bureau, VPN et secours. Prévoyez des dépendances distinctes, une surveillance adaptée et une procédure de changement avec retour arrière.
- Résolveur
- Interroge le DNS pour les clients
- Serveur faisant autorité
- Publie les réponses d’une zone
- Redondance
- Vérifier les dépendances partagées
- Validation
- Nom résolu et service réellement accessible
Reconnaître les principaux scénarios DNS
| Symptôme | Piste | Preuve à réunir | Action prudente |
|---|---|---|---|
| Noms internes en échec sur VPN | Règles de résolution ou routage DNS. | Résolveur interrogé, réponse et contexte VPN. | Vérifier le profil et le chemin autorisé. |
| Service public inaccessible après changement | Enregistrement erroné ou cache. | Ancienne valeur, nouvelle valeur et TTL. | Corriger la zone et tenir compte du cache. |
| IPv4 fonctionne, IPv6 échoue | AAAA ou chemin IPv6 incomplet. | Réponses A/AAAA et connexion par pile. | Valider le service avant publication. |
| Secours actif mais noms en échec | Résolveur dépendant du lien principal. | Chemin DNS pendant la bascule. | Revoir la continuité de la résolution. |
1. Séparer les rôles DNS
Distinguez la résolution pour les utilisateurs, les zones internes et l’hébergement des noms publics. Documentez fournisseurs, zones, serveurs, délégation et contacts. La disponibilité d’un résolveur public ne garantit pas celle d’une zone interne.
Inventoriez également l’accès au bureau d’enregistrement et les comptes d’administration. Utilisez une authentification renforcée et des droits adaptés. Vérifiez que le renouvellement du domaine et les contacts de récupération dépendent de l’organisation et d’un processus maintenu.
- Zones et délégations
- Résolveurs et chemins
- Comptes et responsabilités
- Renouvellements suivis
2. Éliminer les dépendances communes
Deux adresses DNS peuvent correspondre à des services qui partagent une alimentation, un site ou une administration. Analysez les défaillances communes au lieu de conclure à la redondance à partir du nombre de serveurs.
Testez la résolution pendant la perte du lien principal et depuis les VPN. Un accès secondaire ne restaure pas les noms internes si leur résolveur reste accessible uniquement par le chemin interrompu. Définissez les modes dégradés acceptables avant l’incident.
- Sites et alimentation
- Chemins opérateurs
- Dépendances au VPN
- Mode dégradé documenté
3. Gérer les changements et la sécurité
Avant une migration, exportez la zone et listez les enregistrements concernés, y compris messagerie et vérification de services. Le TTL influence la durée de conservation des réponses en cache ; le réduire juste au moment du changement ne supprime pas les anciennes réponses déjà conservées.
DNSSEC concerne l’authenticité des données DNS signées ; il ne chiffre pas les échanges. Sa mise en place exige la maîtrise des clés, de la délégation et des renouvellements. Un changement mal coordonné peut rendre une zone invalide pour les résolveurs qui valident les signatures.
- Zone sauvegardée
- TTL anticipé
- Délégation contrôlée
- DNSSEC géré dans la durée
4. Surveiller résolution et usage réel
Interrogez les noms critiques depuis plusieurs contextes, puis vérifiez la connexion au service. Distinguez absence de réponse, nom inexistant et échec du service derrière une réponse correcte. Les erreurs doivent être corrélées à la zone et au résolveur effectivement utilisés.
Après un incident, consignez la réponse reçue, l’heure et les changements. Ne contournez pas durablement le DNS de l’organisation avec un résolveur arbitraire : cela peut casser les noms internes et les contrôles de sécurité. Faites valider toute modification par le responsable du service.
- Sondes internes et externes
- Résolution puis test applicatif
- Alertes avec contexte
- Changements autorisés
Livrables et critères de réception
Adaptez ces critères à votre périmètre et faites-les valider avant la commande ou le changement. Conservez date, méthode, responsable et résultats. Une hypothèse sans preuve reste à confirmer.
| Contrôle | Livrable | Validation |
|---|---|---|
| Cartographie | Zones, résolveurs et propriétaires. | Dépendances attribuées. |
| Continuité | Bureau, VPN et secours. | Noms critiques disponibles. |
| Changement | Zone et retour arrière. | Modification vérifiable et réversible. |
Checklist avant décision
- Inventorier les zones
- Identifier les comptes responsables
- Documenter les résolveurs
- Contrôler la délégation
- Sauvegarder avant changement
- Tester VPN et secours
- Surveiller noms et applications
- Prévoir le retour arrière
Réponses complémentaires
DNSSEC chiffre-t-il les requêtes ?
Non. Il permet de vérifier l’authenticité des données DNS signées. Le chiffrement du transport répond à un autre objectif.
Deux résolveurs garantissent-ils la disponibilité ?
Non. Vérifiez leur alimentation, leurs chemins, leurs services amont et les dépendances des clients.
Peut-on contourner le problème avec un fichier hosts ?
Cela peut aider un diagnostic autorisé mais crée une configuration locale difficile à maintenir. Ce n’est pas une réparation générale du DNS.
Pourquoi une modification est-elle visible sur certains postes seulement ?
Des caches, des résolveurs ou des zones différents peuvent expliquer l’écart. Comparez les réponses et les TTL depuis les contextes concernés.
Sources et limites
Ces ressources publiques complètent l’étude. Elles ne remplacent ni un test sur place, ni l’éligibilité opérateur, ni les conditions contractuelles applicables au service concerné.
- ANSSI — Architectures des services DNSCadre technique pour la sécurité des services DNS internes, de résolution et publics.
- NIST — Secure DNS Deployment GuideRéférence technique sur les déploiements DNS sécurisés.
Guide préparé par l’équipe éditoriale de Nicholas Owen Global Telecom et mis à jour le . Les prix, couvertures, délais et performances doivent être confirmés par écrit.
Guides complémentaires
Ces sujets prolongent les vérifications présentées dans ce guide.
GUIDE RÉSEAU · TRANSITION IPV6Passer à IPv6 par étapes, sans créer un réseau parallèle invisible.Préparez IPv6 sans rupture : inventaire, plan d’adressage, DNS, sécurité, supervision, pilote dual stack et retrait progressif des dépendances IPv4.
GUIDE ENTREPRISE · RÉSILIENCETester la reprise du réseau avant la vraie panne.Transformez un plan de reprise télécom en exercices vérifiables : scénarios de panne, services prioritaires, rôles, mesures et retour à la normale.
GUIDE · TÉLÉTRAVAILOrganiser une connectivité fiable et sûre pour le télétravailLe télétravail associe accès domestique, terminal professionnel, identité et applications de l’entreprise.