Comprendre le DNS, L'annuaire d'Internet

Votre connexion Internet fonctionne mais impossible d'accéder à un site web ? Le problème vient probablement du DNS (Domain Name System). Le DNS est l'annuaire d'Internet : il traduit les noms de domaine lisibles (github.com) en adresses IP (140.82.121.4). Ce module vous apprend comment fonctionne le DNS et comment diagnostiquer ses problèmes, une compétence quotidienne en administration système.

TL;DR, L'essentiel en 30 secondes

• Le DNS traduit les noms en IP : github.com → 140.82.121.4
• dig +short domaine : obtenir l'IP d'un domaine
• NXDOMAIN = domaine inexistant, SERVFAIL = problème serveur DNS
• resolvectl status : voir quel DNS votre système utilise réellement

Je sais que c'est bon si...

Cochez cette liste avant de conclure que « le DNS est cassé ». Les deux premiers points séparent une panne de résolveur d'une panne de domaine : si le test avec un DNS externe passe alors que le test local échoue, le problème est chez vous, pas chez l'hébergeur du domaine. Le troisième point est celui qui fait gagner le plus de temps sur un incident, car NXDOMAIN et SERVFAIL appellent des actions opposées.

• dig +short google.com retourne une IP
• dig @8.8.8.8 mon-domaine.com fonctionne (test avec DNS externe)
• Je sais interpréter NOERROR, NXDOMAIN et SERVFAIL

Commandes minimales à retenir

Ces trois commandes se lancent dans cet ordre et forment un diagnostic complet. La première dit si la résolution aboutit, la deuxième révèle quel serveur a réellement répondu (rarement celui que vous croyez), la troisième contourne votre configuration locale pour interroger un résolveur public. Comparer les sorties de la première et de la troisième suffit à localiser la panne.

# 1. Résoudre un nom
dig +short github.com

# 2. Voir le DNS utilisé
resolvectl status | head -20

# 3. Tester avec un DNS externe
dig @8.8.8.8 github.com +short

Prérequis

• Module 3 complété : vous savez ce qu'est une adresse IP et un masque
• Module 5 complété : vous comprenez TCP/UDP et savez tester un port avec netcat
• Une machine Linux connectée à Internet
• Un terminal ouvert

Installation des outils

Les commandes dig et nslookup sont préinstallées sur la plupart des distributions. Si elles manquent :

# Debian/Ubuntu
sudo apt install dnsutils

# Fedora/RHEL
sudo dnf install bind-utils

Attention : systemd-resolved peut cacher le vrai DNS

Sur Ubuntu et Debian récents, /etc/resolv.conf pointe vers 127.0.0.53 (systemd-resolved). Ce n'est pas votre vrai serveur DNS, c'est un cache local.

Pour voir le vrai DNS utilisé : resolvectl status.

Si dig fonctionne mais votre application échoue, c'est peut-être un problème de configuration systemd-resolved ou une entrée dans /etc/hosts.

Ce que vous allez apprendre

• Pourquoi le DNS existe : l'annuaire qui traduit les noms en IP
• Comment fonctionne la résolution : resolver → root → TLD → autoritaire
• Les types d'enregistrements : A, AAAA, CNAME, MX, TXT
• Les commandes de diagnostic : nslookup et dig
• Les erreurs courantes : NXDOMAIN, SERVFAIL, timeout
• Cas pratiques : vérifier un domaine avant déploiement

Pourquoi le DNS existe-t-il ?

Imaginez devoir retenir 140.82.121.4 au lieu de github.com, ou 142.250.179.110 pour google.com. Impossible à l'échelle d'Internet avec ses milliards de sites.

Le DNS résout ce problème avec une base de données distribuée et hiérarchique. Aucun serveur ne détient la totalité des noms : chaque niveau ne connaît que le niveau juste en dessous et sait vers qui déléguer. La racine sait qui gère .com, le serveur de .com sait qui gère github.com, et seul ce dernier détient l'adresse finale. Cette délégation est ce qui permet à des millions d'organisations de modifier leurs propres enregistrements sans autorité centrale.

Ce que le DNS fait concrètement

Quand vous tapez github.com dans votre navigateur :

1. Votre système demande l'IP correspondante
2. Le DNS répond 140.82.121.4
3. Votre navigateur se connecte à cette IP

Cette traduction prend de quelques ms (réponse en cache) à parfois plus de 100 ms selon la distance au resolver, les retries, la validation DNSSEC ou le fallback TCP.

Comment fonctionne la résolution DNS ?

Le DNS n'est pas un serveur unique mais une hiérarchie de serveurs spécialisés. Quand votre machine cherche une adresse, elle interroge plusieurs niveaux.

Les acteurs de la résolution

Suivez les cinq étapes en gardant un point en tête : votre machine ne parle qu'au resolver. Tout le trajet vers la racine, le TLD puis le serveur autoritaire est effectué par le resolver, pas par votre PC. C'est pour cette raison qu'un poste peut résoudre correctement un domaine dont il n'atteindrait jamais les serveurs autoritaires lui-même. Chaque niveau ne renvoie pas la réponse mais une délégation, c'est-à-dire l'adresse du serveur à interroger ensuite.

1. Votre PC envoie une requête au resolver configuré

2. Le Resolver (ex: 8.8.8.8 de Google) fait le travail :

   • Il consulte d'abord son cache
   • Sinon, il interroge la hiérarchie DNS

3. Le serveur Root répond : "Pour .com, demande à ce serveur TLD"

   Les 13 root servers

   Il existe 13 identités logiques (nommées A à M), mais chacune est répliquée via anycast sur des centaines d'instances dans le monde. La liste officielle est sur root-servers.org.

4. Le serveur TLD (Top-Level Domain) répond : "Pour github.com, demande à ce serveur autoritaire"

5. Le serveur Autoritaire (les NS du domaine) donne la réponse finale

   Pour connaître les serveurs autoritaires actuels d'un domaine :

   dig NS github.com +short

Cache DNS et performance

Le resolver met en cache les réponses pour éviter de refaire tout ce processus. C'est pour cela qu'une modification DNS peut prendre du temps à se propager : les caches conservent l'ancienne valeur jusqu'à expiration du TTL (Time To Live).

Qui résout quoi ? Stub, récursif, autoritaire

En production, comprendre qui fait quoi évite 80% des confusions :

Acteur	Rôle	Exemple
Stub resolver	Envoie les requêtes à un récursif, ne fait aucune résolution lui-même	127.0.0.53 (systemd-resolved), libc
Résolveur récursif	Interroge la hiérarchie DNS et met en cache	8.8.8.8, 1.1.1.1, Unbound interne
Serveur autoritaire	Détient les enregistrements officiels d'une zone	ns1.example.com

Glissez pour voir

Confusion fréquente

Quand /etc/resolv.conf pointe vers 127.0.0.53, votre application parle au stub local (systemd-resolved), qui lui forward vers le vrai récursif (votre box, votre ISP, ou 8.8.8.8). Pour voir ce récursif réel : resolvectl status.

Le fichier /etc/resolv.conf

Sur Linux, ce fichier configure les serveurs DNS utilisés par votre système :

cat /etc/resolv.conf

Sortie typique :

nameserver 8.8.8.8
nameserver 8.8.4.4
search home.lan

Signification :

Directive	Rôle
nameserver	Serveur DNS à interroger (jusqu'à 3)
search	Domaine ajouté automatiquement aux noms courts

Glissez pour voir

systemd-resolved

Sur les systèmes modernes (Ubuntu 18.04+, Debian 11+), /etc/resolv.conf pointe souvent vers 127.0.0.53, le service local systemd-resolved. Pour voir les vrais serveurs DNS :

resolvectl status

Les types d'enregistrements DNS

Le DNS ne stocke pas que des adresses IP. Il existe plusieurs types d'enregistrements selon l'information recherchée.

Les enregistrements essentiels

Type	Nom complet	Usage	Exemple
A	Address	Nom → IPv4	github.com → 140.82.121.4
AAAA	Quad-A	Nom → IPv6	google.com → 2607:f8b0:4004::8a
CNAME	Canonical Name	Alias vers un autre nom	www.github.com → github.com
MX	Mail Exchange	Serveur mail du domaine	gmail.com → alt1.gmail-smtp-in.l.google.com
NS	Name Server	Serveurs DNS du domaine	github.com → dns1.p08.nsone.net
TXT	Text	Métadonnées diverses	SPF, DKIM, validation Let's Encrypt

Glissez pour voir

Enregistrements courants en administration

En pratique quotidienne, vous manipulerez surtout :

• A et AAAA : pour pointer un nom vers un serveur
• CNAME : pour créer des alias (ex: blog.example.com → example.com)
• TXT : pour les validations de domaine (certificats SSL, SPF pour le mail)

Diagnostiquer le DNS avec les commandes

Deux outils sont indispensables pour le diagnostic DNS : nslookup (simple) et dig (complet).

nslookup, Requêtes simples

nslookup permet des requêtes rapides et fonctionne sur Linux, macOS et Windows.

Syntaxe de base :

nslookup github.com

Sortie :

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   github.com
Address: 140.82.121.4

Interroger un serveur DNS spécifique :

nslookup github.com 8.8.8.8

Chercher un type d'enregistrement particulier :

nslookup -type=MX google.com

nslookup est legacy

nslookup reste utile pour la compatibilité Windows, mais dig et host sont recommandés sur Linux. nslookup a des comportements parfois surprenants et ne montre pas tous les détails utiles au diagnostic.

getent hosts, Ce que l'application voit vraiment

dig interroge uniquement le DNS. Mais votre application peut résoudre via /etc/hosts, mDNS, ou NSS. Pour voir ce que le système retournera vraiment :

# Résolution système complète (hosts + DNS)
getent hosts github.com

# IPv4 uniquement
getent ahostsv4 github.com

# IPv6 uniquement
getent ahostsv6 github.com

Quand utiliser getent ?

Si dig fonctionne mais votre application échoue, testez avec getent. Une entrée dans /etc/hosts ou un problème NSS peut expliquer la différence.

dig, Requêtes avancées

dig (Domain Information Groper) est l'outil de référence sous Linux. Il offre beaucoup plus de détails que nslookup.

Requête simple

dig github.com

Sortie :

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
github.com.             60      IN      A       140.82.121.4

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan 23 10:30:00 CET 2025
;; MSG SIZE  rcvd: 55

Avec serveur spécifique

dig @8.8.8.8 github.com

La notation @8.8.8.8 force l'interrogation du DNS Google, utile pour comparer avec votre DNS local.

Enregistrement MX

dig google.com MX

Sortie (extrait ANSWER SECTION) :

;; ANSWER SECTION:
google.com.     264     IN      MX      10 smtp.google.com.

Le nombre avant le serveur (ici 10) est la préférence : plus la valeur est basse, plus le serveur est prioritaire. Google n'expose qu'un seul MX ; un domaine avec redondance en affiche plusieurs, comme gmail.com qui va de 5 gmail-smtp-in.l.google.com à 40 alt4.gmail-smtp-in.l.google.com.

Réponse courte

dig +short github.com

Sortie :

140.82.121.4

Idéal pour les scripts où vous voulez juste l'adresse IP.

Lire une réponse dig en détail

Voici comment interpréter les sections d'une réponse dig :

Section	Contenu
HEADER	Status (NOERROR, NXDOMAIN, etc.) et compteurs
QUESTION	Ce qui a été demandé
ANSWER	La réponse (ex: l'IP)
AUTHORITY	Serveurs DNS faisant autorité
ADDITIONAL	Infos supplémentaires
Query time	Temps de réponse en ms
SERVER	Le serveur DNS interrogé

Glissez pour voir

TTL et cache

Le nombre après le nom de domaine (ex: 60 dans github.com. 60 IN A) est le TTL en secondes. Plus il est bas, plus les changements se propagent vite. 60 secondes est courant pour les services avec load balancing.

Tracer la résolution complète

dig +trace est l'outil à sortir quand une modification DNS « ne se propage pas ». Il court-circuite le cache de votre résolveur et refait le chemin complet, ce qui vous montre la valeur réellement publiée par le serveur autoritaire, indépendamment de ce que votre cache local raconte. Lisez la sortie de haut en bas : chaque bloc correspond à un niveau de délégation, et le dernier bloc contient la réponse faisant autorité.

Pour lancer cette résolution itérative depuis les root servers :

dig +trace github.com

Ce que +trace fait vraiment

dig +trace n'affiche pas ce que votre resolver a fait. Il exécute une nouvelle résolution itérative depuis votre machine, en interrogeant directement root → TLD → autoritaire. C'est utile pour vérifier la propagation, mais ce n'est pas un "replay" du chemin réel de votre résolveur.

Flags dig essentiels en incident

Le réflexe utile en astreinte est de raccourcir l'attente. Par défaut dig retente 3 fois avec 5 secondes de patience, soit 15 secondes perdues par serveur injoignable. +time=1 +tries=1 transforme le test en une seconde, ce qui permet d'enchaîner plusieurs résolveurs. Les deux autres options répondent à des symptômes précis : +tcp quand une réponse revient tronquée, +dnssec quand vous soupçonnez un SERVFAIL de validation.

# Timeout court pour tests rapides
dig example.com +time=1 +tries=1

# Forcer TCP (si UDP bloqué ou réponse tronquée)
dig example.com +tcp

# Voir les infos DNSSEC
dig example.com +dnssec

# Combiner : test rapide via DNS Google
dig @8.8.8.8 example.com +short +time=2

Problèmes DNS courants et solutions

Les erreurs que vous rencontrerez

Le code renvoyé par le résolveur, visible sur la ligne status: du header dig, désigne où se situe le problème. NXDOMAIN et NODATA viennent du serveur autoritaire et signifient que la zone a répondu, donc que la chaîne DNS fonctionne. SERVFAIL et REFUSED viennent du résolveur lui-même, et le domaine n'est probablement pas en cause. Un Timeout n'est pas un code DNS du tout : rien n'est revenu, ce qui pointe vers le réseau ou un firewall.

Erreur	Signification	Cause probable
NXDOMAIN	Domaine inexistant	Faute de frappe, domaine expiré, jamais enregistré
NODATA	Nom existe mais pas ce type	Demander AAAA alors que seul A existe
SERVFAIL	Échec du serveur	Voir encart ci-dessous
REFUSED	Requête refusée	Le serveur n'accepte pas vos requêtes (ACL)
Timeout	Pas de réponse	Problème réseau, firewall, serveur down

Glissez pour voir

SERVFAIL ≠ domaine inexistant

SERVFAIL est souvent mal compris. En environnement moderne, les causes principales sont :

• Échec de validation DNSSEC : le résolveur validant rejette une signature invalide
• Timeouts en cascade : le résolveur n'arrive pas à joindre les autoritaires
• Délégation cassée : les NS pointent vers des serveurs qui ne répondent pas
• Serveur autoritaire surchargé : trop de requêtes, pas assez de ressources

Pour diagnostiquer, testez avec dig +dnssec et comparez avec un résolveur non-validant.

Diagnostic pas à pas

Cette séquence part du bas de la pile et remonte, pour éviter de chercher une panne DNS là où c'est le réseau qui est coupé. Arrêtez-vous à la première étape qui échoue : elle désigne la couche responsable. Si l'étape 1 passe et l'étape 2 échoue, le problème est le domaine lui-même ; si l'étape 2 passe alors que la résolution normale échoue, c'est votre résolveur local qu'il faut corriger.

1. Vérifier la connectivité de base

   ping 8.8.8.8

   Si ça échoue, le problème est réseau, pas DNS.

2. Tester avec un DNS public

   dig @8.8.8.8 github.com

   Si ça fonctionne, votre DNS local est le problème.

3. Vérifier votre configuration DNS

   cat /etc/resolv.conf
   resolvectl status  # sur systemd

4. Vider le cache DNS local

   # Sur systemd-resolved
   sudo resolvectl flush-caches
   
   # Vérifier que le cache est vidé (Current Cache Size doit valoir 0)
   sudo resolvectl statistics

Propagation DNS

Après une modification DNS, l'ancienne valeur peut persister dans les caches du monde entier. Le TTL (Time To Live) définit cette durée. Pour une migration, réduisez le TTL à 60 secondes avant le changement, puis remettez-le à une valeur normale après.

La chaîne de caches

Quand « je vide le cache » ne suffit pas, c'est souvent parce que plusieurs niveaux cachent les réponses. Lisez le tableau du haut vers le bas : vous ne maîtrisez que les deux premières lignes. La troisième, le résolveur récursif de l'opérateur ou de l'entreprise, garde l'ancienne valeur jusqu'à expiration du TTL et aucune commande côté client ne l'accélère. C'est pourquoi un collègue voit le nouveau site pendant que vous voyez encore l'ancien.

Niveau	Cache	Comment vider
Navigateur	Cache interne (Chrome, Firefox)	Fermer/rouvrir, ou chrome://net-internals/#dns
OS / systemd-resolved	Cache local	sudo resolvectl flush-caches
Résolveur récursif	Cache partagé (ISP, entreprise)	Impossible côté client
CDN / Load balancer	Cache applicatif	Dépend de la plateforme

Glissez pour voir

Negative caching (NXDOMAIN en cache)

Attention : NXDOMAIN est aussi mis en cache ! Le TTL négatif est défini dans le SOA de la zone (champ MINIMUM). Si un domaine "n'existe pas", cette réponse peut persister plusieurs minutes même après création. C'est le negative caching (RFC 2308).

Problèmes liés au cache

Avant de vider quoi que ce soit, regardez sudo resolvectl statistics : le bloc Cache affiche Current Cache Size, Cache Hits et Cache Misses. Sans privilèges, la commande échoue sur Permission denied en tentant de joindre le service de supervision de systemd-resolved. Vider un cache déjà vide ne réglera rien et vous fera chercher au mauvais endroit ; après un flush-caches, Current Cache Size doit être retombé à zéro, ce qui confirme que l'opération a porté sur le bon service.

Le cache DNS peut causer des comportements inattendus :

# Voir les statistiques de cache (systemd)
sudo resolvectl statistics

# Vider le cache
sudo resolvectl flush-caches

# Sur macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

DNS et transport : UDP, TCP, EDNS0

Par défaut, le DNS utilise UDP port 53 pour sa rapidité. Mais certaines situations nécessitent TCP :

Quand DNS bascule en TCP

Le passage à TCP n'est jamais un choix du client : c'est le serveur qui l'impose en positionnant le bit TC (truncated) dans l'en-tête de sa réponse UDP. Le client constate ce bit et rejoue la même question en TCP. Le tableau ci-dessous liste les quatre situations où ce basculement se produit ; retenez surtout la première, car c'est elle qui explique les pannes intermittentes quand un firewall laisse passer UDP/53 mais bloque TCP/53.

Situation	Mécanisme
Réponse > 512 octets (sans EDNS0)	Le serveur met TC=1 (truncated), le client retry en TCP
Réponse > taille EDNS0	Même mécanisme avec le buffer EDNS0 annoncé
Transfert de zone (AXFR)	Toujours TCP
Politique serveur	Certains serveurs forcent TCP

Glissez pour voir

EDNS0 : Extended DNS

EDNS0 (RFC 6891) permet d'annoncer une taille de buffer UDP supérieure à 512 octets (souvent 4096). Cela réduit les fallbacks TCP. Vérifiez avec :

dig example.com +bufsize=4096

Pannes « bizarres » liées au transport

Le symptôme typique est un domaine qui répond pour certains types d'enregistrement et pas pour d'autres : le A passe, le TXT ou le DNSSEC échoue. La différence n'est pas le domaine, c'est la taille de la réponse, qui franchit le seuil au-delà duquel le serveur exige TCP. Le test ci-dessous isole ce cas en une commande : si +tcp réussit là où la requête normale échoue, le coupable est sur le chemin réseau, pas dans la zone DNS.

# Tester en forçant TCP
dig example.com +tcp

# Si TCP fonctionne mais UDP non → problème firewall/MTU

Firewall et TCP/53

Certains firewalls bloquent TCP/53 en pensant que DNS = UDP uniquement. Résultat : les grosses réponses (DNSSEC, TXT longs) échouent. Vérifiez que UDP/53 ET TCP/53 sont ouverts.

Sécurité DNS : DNSSEC, DoT, DoH

Sans alourdir ce module, voici les concepts de sécurité DNS à connaître :

DNSSEC, Intégrité des réponses

DNSSEC (RFC 4033) permet de vérifier l'authenticité des réponses DNS via des signatures cryptographiques. Il protège contre le cache poisoning mais ne chiffre pas les requêtes.

# Voir si la réponse a été validée (flag "ad" dans le header)
dig @9.9.9.9 example.com +dnssec

# Vérifier la chaîne de confiance de bout en bout
delv @9.9.9.9 example.com

L'option dig +sigchase que l'on croise encore dans de vieux tutoriels est dépréciée : les versions récentes de BIND affichent ;; +sigchase option is deprecated puis exécutent une requête ordinaire. L'outil de remplacement est delv, livré dans le même paquet que dig (dnsutils sur Debian, bind-utils sur Fedora). Une chaîne valide se termine par la ligne ; fully validated.

Précisez toujours un résolveur validant avec @. Via le stub 127.0.0.53 de systemd-resolved, delv renvoie ;; broken trust chain et dig +dnssec n'affiche pas le flag ad : ce n'est pas le domaine qui est cassé, c'est le stub qui ne transmet pas les enregistrements nécessaires à la validation.

DoT et DoH, Confidentialité des requêtes

Protocole	Port	Description
DoT (DNS over TLS)	853	Chiffrement TLS, RFC 7858
DoH (DNS over HTTPS)	443	DNS dans HTTPS, RFC 8484

Glissez pour voir

Ces protocoles chiffrent les échanges entre vous et le résolveur (pas au-delà). Ils empêchent l'espionnage de vos requêtes DNS par votre ISP ou un attaquant réseau.

Configuration DoT/DoH

Pour activer DoT avec systemd-resolved :

/etc/systemd/resolved.conf

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes

Cas pratique dans un contexte d'administration

Vérifier qu'un site est accessible via DNS

Avant de signaler une panne, vérifiez que le DNS fonctionne :

# Le domaine est-il résolu ?
dig +short production.company.com

# La réponse vient-elle du bon serveur ?
dig @ns1.company.com production.company.com

# Comparer avec un DNS public
dig @8.8.8.8 production.company.com

Valider une configuration de domaine

Lors d'un déploiement, vérifiez les enregistrements critiques :

# Record A (site principal)
dig +short example.com A

# Record CNAME (sous-domaines)
dig +short www.example.com CNAME

# Records MX (mail)
dig example.com MX +short

# Records TXT (SPF, validation)
dig example.com TXT +short

Surveiller le TTL avant une migration

Le TTL détermine combien de temps l'ancienne adresse restera servie par les caches du monde entier après votre bascule. Relevez-le avant de planifier la migration : un TTL de 86400 secondes signifie qu'un utilisateur peut atterrir sur l'ancien serveur pendant 24 heures. La manœuvre consiste à abaisser le TTL à 60 secondes au moins un TTL complet à l'avance, à basculer, puis à le remonter. Attention à la lecture de la sortie : la valeur affichée par un résolveur en cache décroît à chaque requête, seul un dig @ sur le serveur autoritaire donne la valeur publiée.

# Voir le TTL actuel
dig example.com | grep -A1 "ANSWER SECTION"

# Résultat : example.com.  300  IN  A  1.2.3.4
#            ↑ 300 secondes = 5 minutes de cache

Travaux pratiques

TP 1 : Exploration DNS de services réels

Ce premier TP porte sur des domaines publics réels, donc vos résultats ne seront pas identiques aux valeurs citées plus haut : les grands services répondent en anycast et font tourner leurs adresses. C'est précisément ce qu'il faut observer. À l'étape 4, comparez les réponses des trois résolveurs publics et notez les écarts d'adresse ou de TTL ; ces écarts sont normaux et viennent de l'état de cache propre à chaque opérateur.

1. Résolvez l'adresse de GitHub

   dig github.com A
   dig github.com AAAA

   Notez l'IPv4 et vérifiez si GitHub a une IPv6.

2. Examinez les serveurs mail de Google

   dig google.com MX

   Combien de serveurs mail sont configurés ? Lequel a la priorité ?

3. Trouvez les serveurs DNS de github.com

   dig github.com NS

   Ces serveurs sont autoritaires pour le domaine.

4. Comparez les réponses de différents resolvers

   dig @8.8.8.8 github.com +short    # Google
   dig @1.1.1.1 github.com +short    # Cloudflare
   dig @9.9.9.9 github.com +short    # Quad9

   Les réponses sont-elles identiques ?

5. Tracez une résolution complète

   dig +trace google.com

   Identifiez les serveurs root, TLD et autoritaires dans la sortie.

TP 2 : Diagnostic d'un problème DNS simulé

L'objectif ici est d'apprendre à distinguer trois échecs qui se ressemblent en apparence. L'adresse 192.0.2.1 de la première étape appartient au bloc de documentation réservé par la RFC 5737 : elle n'est routée nulle part, ce qui reproduit fidèlement un serveur injoignable sans déranger personne. Notez à chaque étape ce que dig affiche exactement : absence de réponse, status: NXDOMAIN, ou Query time élevé. Ces trois signatures mènent à trois corrections différentes.

1. Simulez un mauvais serveur DNS

   # Interroger un serveur qui n'existe pas
   dig @192.0.2.1 github.com

   Observez que dig rend la main au bout d'environ 15 secondes, avec ;; no servers could be reached. Ce n'est pas un seul timeout mais 3 tentatives de 5 secondes : ce sont les valeurs par défaut de +tries et +time. En incident, +time=1 +tries=1 ramène l'attente à une seconde.

2. Testez un domaine inexistant

   dig domaine-qui-nexiste-pas-12345.com

   Repérez le status NXDOMAIN dans la réponse.

3. Mesurez les temps de réponse

   dig github.com | grep "Query time"
   dig @8.8.8.8 github.com | grep "Query time"

   Comparez votre DNS local au DNS Google.

Testez vos connaissances

Le quiz ci-dessous tire ses questions du module et porte principalement sur les codes de réponse, la hiérarchie de résolution et la lecture d'une sortie dig. Le seuil de réussite est fixé à 80 % : en dessous, reprenez la section « Problèmes DNS courants », qui concentre les points les plus souvent manqués.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

Le DNS est l'annuaire distribué d'Internet. Retenez ces points clés :

• Hiérarchie : Root (13 logiques, anycast mondial) → TLD → Autoritaire → Réponse
• Trois acteurs : Stub (local) → Résolveur récursif (fait le travail) → Autoritaire (détient la zone)
• Cache multi-niveaux : Navigateur, OS, résolveur, CDN, et negative caching pour NXDOMAIN
• Types courants : A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (métadonnées)
• Outils : dig pour le diagnostic DNS, getent hosts pour voir ce que l'application résout
• Transport : UDP par défaut, TCP si réponse tronquée (TC=1), EDNS0 pour buffers > 512
• SERVFAIL : Souvent DNSSEC ou timeouts, pas forcément "serveur down"
• Sécurité : DNSSEC = intégrité, DoT/DoH = confidentialité client-résolveur

FAQ : questions fréquentes sur le DNS

Ces huit questions couvrent ce qui bloque le plus souvent en pratique : la résolution en ligne de commande, le choix entre dig et nslookup, la distinction entre un enregistrement A et un CNAME, le délai avant qu'un changement prenne effet, la différence entre un résolveur récursif et un serveur autoritaire, l'écart entre NXDOMAIN et SERVFAIL, et ce que recouvrent DoH et DoT.

Qu'est-ce que le DNS ?

Le DNS (Domain Name System) est l'annuaire d'Internet : il traduit les noms de domaine (exemple.com) en adresses IP (93.184.216.34). La résolution suit une hiérarchie : serveurs racine, serveurs de TLD (.com, .fr), puis serveurs autoritaires du domaine, via un résolveur récursif qui met en cache.

Comment résoudre un nom de domaine en ligne de commande ?

La commande recommandée est dig : dig +short exemple.com donne l'IP, dig MX exemple.com les serveurs mail, dig @1.1.1.1 exemple.com interroge un résolveur précis, dig -x IP fait la résolution inverse. nslookup existe mais l'ISC recommande dig ou host.

Quelle est la différence entre un enregistrement A et un CNAME ?

Un enregistrement A associe un nom directement à une adresse IPv4 (AAAA pour IPv6). Un CNAME est un alias : il pointe un nom vers un autre nom, pas vers une IP. Le CNAME évite de dupliquer une IP sur plusieurs sous-domaines, mais il est interdit au sommet d'un domaine (apex).

Pourquoi mon changement DNS ne prend-il pas effet immédiatement ?

À cause du cache et du TTL. Chaque enregistrement DNS a un TTL pendant lequel les résolveurs gardent l'ancienne valeur en cache et la servent. Pour accélérer une migration, on baisse le TTL à l'avance et on vide son cache local (resolvectl flush-caches).

Quelle différence entre un résolveur récursif et un serveur autoritaire ?

Un serveur autoritaire détient les enregistrements officiels d'un domaine. Un résolveur récursif (box, 1.1.1.1, 8.8.8.8) ne détient rien : il interroge la racine, le TLD puis l'autoritaire, met en cache et vous rend la réponse. Votre machine parle au récursif, jamais à l'autoritaire.

Qu'est-ce que le DNS chiffré (DoH et DoT) ?

Le DNS classique circule en clair sur le port 53. DoT (port 853) et DoH (port 443) chiffrent les requêtes pour la vie privée. systemd-resolved gère DoT nativement mais pas DoH, qui passe par les navigateurs ou un proxy. DoH se fond dans le trafic HTTPS, DoT utilise un port dédié.

dig ou nslookup : lequel utiliser ?

Sur Linux, privilégiez dig : il affiche le code de réponse, le TTL, le serveur interrogé et le détail complet, indispensable au diagnostic. nslookup reste pratique sous Windows et pour une résolution rapide, mais il masque des informations utiles et a des comportements surprenants.

Quelle différence entre NXDOMAIN et SERVFAIL ?

NXDOMAIN signifie que le domaine n'existe pas : le serveur autoritaire a répondu, la chaîne DNS fonctionne (faute de frappe, domaine expiré). SERVFAIL est un échec côté résolveur, souvent lié à la validation DNSSEC ou à des timeouts vers les autoritaires. Les deux appellent des actions opposées.

Prochaines étapes

ICMP, le protocole de diagnostic réseau Interpréter ping et traceroute quand la résolution passe mais la connexion non.

Méthodologie de diagnostic réseau Enchaîner les couches dans le bon ordre pour isoler une panne.

HTTP et HTTPS, le protocole du Web Ce qui se passe après la résolution du nom, une fois la connexion établie.

Diagnostic TLS avec openssl Déboguer les erreurs de certificat sur un nom qui résout pourtant correctement.

×

📖 Voir la documentation →