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…

• 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

# 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 en créant un système de traduction distribué et hiérarchique. Pensez-y comme l’annuaire téléphonique mondial : vous cherchez un nom, vous obtenez un numéro.

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

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 → ns1.p16.dynect.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.     300     IN      MX      10 smtp.google.com.
google.com.     300     IN      MX      20 smtp2.google.com.

Le nombre avant le serveur (10, 20) indique la priorité : plus petit = préféré.

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

Pour simuler une 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

Ces options sont précieuses lors d’un diagnostic :

# 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

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

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

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

Le cache DNS peut causer des comportements inattendus :

# Voir les statistiques de cache (systemd)
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

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

Si un domaine fonctionne parfois mais pas toujours :

# 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 un domaine est signé DNSSEC
dig example.com +dnssec

# Vérifier la chaîne de confiance
dig example.com +sigchase +trusted-key=/etc/trusted-key.key

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

# 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

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é

1. Simulez un mauvais serveur DNS

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

   Observez le timeout après ~5 secondes.

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

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

Prochaines étapes

TCP vs UDP Comprendre pourquoi le DNS utilise UDP et quand TCP entre en jeu.

Troubleshooting réseau

×

📖 Voir la documentation →