DNS : résolution de noms et dépannage
Quand « Internet ne marche plus », le DNS est souvent en cause. Comprendre la chaîne de résolution, les types d'enregistrements et le rôle du cache permet de localiser la panne en quelques commandes.
Le DNS (Domain Name System) traduit des noms lisibles comme www.exemple.fr en adresses IP, et inversement. Défini par les RFC 1034 et 1035, c'est une base de données distribuée et hiérarchique : aucun serveur ne connaît tous les noms, mais chacun sait à qui déléguer.
Objectif : comprendre la chaîne de résolution, connaître les enregistrements essentiels et appliquer une méthode de dépannage reproductible.
La hiérarchie des noms
Un nom de domaine se lit de droite à gauche :
www.exemple.fr.
│ │ │ └─ racine (le point final, souvent omis)
│ │ └──── domaine de premier niveau (TLD) : fr
│ └───────── domaine de second niveau : exemple
└─────────────── nom d'hôte : www
Chaque niveau constitue une zone gérée par des serveurs faisant autorité. La racine délègue .fr aux serveurs de l'AFNIC, qui délèguent exemple.fr aux serveurs déclarés par son propriétaire.
Les acteurs de la résolution
- Le client (stub resolver) : la bibliothèque système du poste, qui envoie une requête récursive à un résolveur configuré.
- Le résolveur récursif : serveur DNS de l'entreprise ou du fournisseur d'accès, qui fait tout le travail et met les réponses en cache.
- Les serveurs faisant autorité : ceux qui détiennent réellement les enregistrements d'une zone.
Déroulé d'une résolution
- Le poste demande
www.exemple.frà son résolveur (requête récursive : « donne-moi la réponse finale »). - Si la réponse n'est pas en cache, le résolveur interroge un serveur racine, qui répond par une délégation vers les serveurs de
.fr. - Le résolveur interroge un serveur de
.fr, qui le renvoie vers les serveurs deexemple.fr. - Le résolveur interroge un serveur faisant autorité pour
exemple.fr, qui fournit l'enregistrement demandé. - Le résolveur met la réponse en cache pour la durée de son TTL et la transmet au poste.
Les étapes 2 à 4 sont des requêtes itératives : chaque serveur répond avec ce qu'il sait, sans chercher plus loin.
Les enregistrements essentiels
| Type | Rôle | Exemple |
|---|---|---|
| A | Nom → adresse IPv4 | www IN A 203.0.113.10 |
| AAAA | Nom → adresse IPv6 | www IN AAAA 2001:db8::10 |
| CNAME | Alias vers un autre nom | blog IN CNAME www.exemple.fr. |
| MX | Serveurs de messagerie (avec priorité) | @ IN MX 10 mail.exemple.fr. |
| NS | Serveurs faisant autorité de la zone | @ IN NS ns1.exemple.fr. |
| SOA | Paramètres de la zone (série, délais) | une seule par zone |
| PTR | Adresse → nom (résolution inverse) | 10.113.0.203.in-addr.arpa. IN PTR www.exemple.fr. |
| TXT | Texte libre (SPF, vérifications de domaine) | @ IN TXT "v=spf1 mx -all" |
| SRV | Localisation d'un service (protocole, port) | _ldap._tcp IN SRV 0 100 389 dc1.exemple.local. |
Règle à retenir : un nom qui porte un CNAME ne peut porter aucun autre enregistrement. C'est pourquoi on ne peut pas placer un CNAME à l'apex d'une zone (exemple.fr lui-même), qui porte obligatoirement SOA et NS.
Cache et TTL
Chaque enregistrement possède un TTL (en secondes) indiquant combien de temps il peut rester en cache. Un TTL long réduit la charge et accélère les résolutions ; un TTL court permet des changements rapides.
Bonne pratique de migration : abaissez le TTL d'un enregistrement (par exemple à 300 secondes) au moins une durée de TTL complète avant de changer l'adresse, puis rétablissez-le après la migration.
Les réponses négatives (« ce nom n'existe pas », NXDOMAIN) sont elles aussi mises en cache, selon les règles de la RFC 2308 et la valeur du SOA.
Plusieurs caches coexistent : celui du navigateur, celui du système d'exploitation et celui du résolveur. Pour vider le cache local :
ipconfig /flushdns # Windows
Clear-DnsClientCache
resolvectl flush-caches # Linux avec systemd-resolved
Méthode de dépannage DNS
Étape 1 : vérifier la configuration du client
resolvectl status # Linux (systemd-resolved)
cat /etc/resolv.conf
Get-DnsClientServerAddress
ipconfig /all
Le poste utilise-t-il le bon résolveur ? Un serveur DNS public configuré sur un poste d'entreprise ne connaîtra pas les noms internes.
Étape 2 : tester le résolveur
dig www.exemple.fr
dig @10.0.0.53 www.exemple.fr A +short
Resolve-DnsName www.exemple.fr -Server 10.0.0.53
nslookup www.exemple.fr 10.0.0.53
Lisez le statut de la réponse dans dig :
| Statut | Signification |
|---|---|
| NOERROR avec réponse | Résolution réussie |
| NOERROR sans réponse | Le nom existe mais pas pour ce type d'enregistrement |
| NXDOMAIN | Le nom n'existe pas |
| SERVFAIL | Le résolveur n'a pas pu obtenir de réponse valide (serveurs injoignables, échec DNSSEC…) |
| REFUSED | Le serveur refuse de répondre à ce client |
| Délai dépassé | Résolveur injoignable ou port 53 filtré |
Étape 3 : interroger directement les serveurs faisant autorité
dig NS exemple.fr +short
dig @ns1.exemple.fr www.exemple.fr A +norecurse
Si le serveur faisant autorité renvoie la bonne réponse mais pas le résolveur, le problème vient du cache ou de la délégation.
Étape 4 : suivre la chaîne de délégation
dig www.exemple.fr +trace
+trace effectue la résolution depuis la racine et affiche chaque délégation. Une rupture dans la chaîne révèle une délégation incohérente.
Étape 5 : contrôler la résolution inverse si nécessaire
dig -x 203.0.113.10
Certains services (messagerie, journaux, authentification) dépendent d'une résolution inverse correcte.
Erreurs courantes
- Oublier le point final dans un fichier de zone :
mail.exemple.frsans point devientmail.exemple.fr.exemple.fr. - Ne pas incrémenter le numéro de série du SOA : les serveurs secondaires ignorent la modification.
- Filtrer DNS en TCP : les réponses volumineuses échouent.
- Modifier un enregistrement sans anticiper le TTL et s'étonner que certains clients voient l'ancienne valeur.
- Mélanger noms internes et externes sans stratégie claire (DNS « split-horizon » mal maîtrisé).
Implications de sécurité
Le DNS classique n'est ni chiffré ni authentifié. Les risques principaux sont l'empoisonnement de cache, l'usurpation de réponses et l'exfiltration de données par tunnel DNS. Les contre-mesures incluent DNSSEC pour l'authenticité, DoT/DoH pour la confidentialité entre client et résolveur, des résolveurs fermés aux clients autorisés et la journalisation des requêtes. Voir DNS sécurisé et mécanismes de protection.
Conclusion
La résolution DNS suit toujours la même logique : client, résolveur, délégations, serveur faisant autorité, cache. Avec dig ou Resolve-DnsName, interrogez chaque maillon séparément : la panne apparaît rapidement. Pour l'intégration avec Active Directory, consultez DNS sous Windows Server et intégration à Active Directory.
