Comprendre le protocole DNS : tout ce que vous devez savoir
Enregistrements A, CNAME, MX, TXT, TTL, DNSSEC, DNS over HTTPS — le DNS en profondeur, des zones files au diagnostic avec dig.
Chaque développeur configure DNS un jour. Et presque tout le monde le fait à l'aveugle — copier-coller des enregistrements sans comprendre ce qu'ils font, attendre "la propagation", espérer que ça fonctionne.
Ce guide couvre le protocole complet : comment le DNS résout un nom, les types d'enregistrements que vous rencontrerez (et ceux que vous devriez connaître), comment diagnostiquer avec dig, et les erreurs de sécurité qui permettent des attaques sur votre domaine.
Si vous cherchez juste une vue d'ensemble de DNS dans le contexte d'Internet, comment fonctionne Internet pose les bases. Ici, on va dans le détail.
DNS : base de données distribuée
DNS n'est pas un seul serveur — c'est une base de données distribuée en arbre. Chaque nœud de l'arbre est responsable d'une zone : une portion de l'espace de nommage.
. ← Zone racine (root servers)
├── fr. ← Zone TLD (Afnic)
│ └── iducation.fr. ← Zone de votre domaine (votre hébergeur DNS)
│ ├── www
│ ├── api
│ └── mail
├── com.
│ └── google.com.
└── io.
└── github.io.Chaque zone est gérée par un serveur autoritatif qui détient les enregistrements officiels pour cette zone. La chaîne de délégation permet à n'importe quel résolveur de retrouver n'importe quel nom en suivant les pointeurs de zone en zone.
Les types d'enregistrements DNS
C'est là que la plupart des guides DNS deviennent vagues. Voici chaque type avec son usage concret.
A — IPv4
iducation.fr. 300 IN A 76.76.21.21L'enregistrement fondamental. Pointe un nom vers une adresse IPv4. Un domaine peut avoir plusieurs enregistrements A — le résolveur retourne tous les résultats, le client choisit (round-robin DNS, load balancing basique).
dig A iducation.frAAAA — IPv6
iducation.fr. 300 IN AAAA 2606:4700:3037::ac43:a86cMême chose pour IPv6. Les navigateurs modernes préfèrent AAAA quand disponible (Happy Eyeballs — connexion parallèle IPv4/IPv6, victoire du plus rapide).
CNAME — Alias
www.iducation.fr. 3600 IN CNAME iducation.fr.
blog.iducation.fr. 3600 IN CNAME iducation-blog.vercel.app.CNAME crée un alias — il pointe vers un autre nom, pas vers une IP. Quand le résolveur rencontre un CNAME, il résout la cible ensuite.
Règle critique : un CNAME ne peut pas coexister avec d'autres enregistrements sur le même nom. iducation.fr. ne peut pas avoir à la fois un CNAME et un enregistrement MX — c'est une erreur de configuration. C'est pourquoi l'apex du domaine (le domaine nu, sans sous-domaine) utilise des enregistrements A/AAAA directs, pas un CNAME.
Cloudflare et d'autres proposent des ALIAS ou ANAME — un pseudo-enregistrement qui se comporte comme un CNAME mais retourne une IP. Résout le problème de l'apex.
MX — Mail Exchange
iducation.fr. 3600 IN MX 10 mail1.provider.com.
iducation.fr. 3600 IN MX 20 mail2.provider.com.Indique quels serveurs reçoivent les emails pour ce domaine. Le nombre (10, 20) est la priorité — les valeurs basses sont préférées. En cas d'indisponibilité du serveur prioritaire, le suivant est tenté.
Sans enregistrement MX, les emails destinés à votre domaine ne peuvent pas être délivrés.
dig MX iducation.frTXT — Texte libre
iducation.fr. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
iducation.fr. 3600 IN TXT "google-site-verification=abc123..."Enregistrement polyvalent. Usage principal : vérification de propriété et authentification email.
SPF (Sender Policy Framework) — liste les serveurs autorisés à envoyer des emails au nom de votre domaine. Réduit le spam usurpant votre identité.
DKIM — signature cryptographique des emails. La clé publique est publiée en TXT.
DMARC — politique sur quoi faire avec les emails qui échouent SPF/DKIM.
_dmarc.iducation.fr. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@iducation.fr"# Vérifier SPF
dig TXT iducation.fr | grep spf
# Vérifier DMARC
dig TXT _dmarc.iducation.fr
# Vérifier DKIM (selector = "google" dans cet exemple)
dig TXT google._domainkey.iducation.frNS — Name Servers
iducation.fr. 86400 IN NS lena.ns.cloudflare.com.
iducation.fr. 86400 IN NS miles.ns.cloudflare.com.Délègue la gestion de la zone à des nameservers spécifiques. C'est l'enregistrement que vous modifiez chez votre registrar quand vous changez d'hébergeur DNS. Les enregistrements NS ont un TTL long (24h+) — la délégation ne change pas souvent.
SOA — Start of Authority
iducation.fr. 3600 IN SOA lena.ns.cloudflare.com. dns.cloudflare.com. (
2024061801 ; serial
10000 ; refresh
2400 ; retry
604800 ; expire
300 ; minimum TTL
)Un seul SOA par zone. Contient les métadonnées de la zone : nameserver primaire, email de l'administrateur (. remplace @), numéro de série (incrémenté à chaque modification — permet aux secondaires de détecter les changements).
PTR — Reverse DNS
21.21.76.76.in-addr.arpa. 3600 IN PTR iducation.fr.Inverse de l'enregistrement A : de l'IP vers le nom. Géré par votre hébergeur/FAI (pas vous). Essentiel pour :
- La réputation email — les serveurs SMTP vérifient que l'IP du serveur expéditeur résout vers un nom cohérent
- Les logs réseau lisibles (
iducation.frau lieu de76.76.21.21)
dig -x 76.76.21.21
# ou
host 76.76.21.21SRV — Services
_https._tcp.iducation.fr. 3600 IN SRV 0 5 443 iducation.fr.
_sip._udp.example.com. 3600 IN SRV 10 20 5060 sip.example.com.Format : priorité, poids, port, cible. Utilisé pour découvrir automatiquement les services — VoIP (SIP), messagerie (XMPP), jeux, et de plus en plus via DNS-SD (service discovery).
CAA — Certification Authority Authorization
iducation.fr. 3600 IN CAA 0 issue "letsencrypt.org"
iducation.fr. 3600 IN CAA 0 issuewild ";"Spécifie quelle(s) CA sont autorisées à émettre des certificats TLS pour votre domaine. Si quelqu'un tente d'obtenir un certificat via une autre CA, elles doivent refuser. Protection contre les certificats frauduleux.
dig CAA iducation.frTTL : l'art du cache DNS
Le TTL (Time To Live) indique combien de secondes les résolveurs peuvent cacher un enregistrement avant de le re-demander.
iducation.fr. 300 IN A 76.76.21.21
^^^^
5 minutes de cacheTTL court (60–300s) — propagation rapide des changements. Utile avant une migration, pendant un incident. Coût : plus de requêtes DNS, légèrement plus de latence.
TTL long (3600–86400s) — moins de requêtes, meilleure performance. Idéal pour les enregistrements stables.
Stratégie de migration :
- Semaine avant : baisser le TTL à 300s
- Jour J : changer l'IP
- Attendre 5 minutes (ancien TTL max)
- Remonter le TTL à 3600s
# Voir le TTL actuel et quand il expire dans le cache
dig iducation.fr +noall +answer
# iducation.fr. 287 IN A 76.76.21.21
# ^^^
# TTL restant dans le cache du résolveur interrogéLa "propagation DNS" — un mythe partiel
"Attendre 48h que le DNS se propage" est un conseil vague qui mélange deux choses différentes.
Délai de délégation NS : quand vous changez de nameservers chez votre registrar, les root servers et TLD servers doivent mettre à jour leur cache. Ça prend effectivement jusqu'à 24–48h — le TTL des enregistrements NS est long.
Propagation des enregistrements A/CNAME : dans votre propre zone, la "propagation" dépend uniquement du TTL. Si TTL = 300s et que vous changez un enregistrement A, les résolveurs qui avaient l'ancien enregistrement en cache l'auront pendant au maximum 300 secondes. Pas 48h.
# Vérifier depuis différents résolveurs mondiaux
# (utile pour voir si le changement est visible depuis différentes régions)
dig @8.8.8.8 iducation.fr # Google
dig @1.1.1.1 iducation.fr # Cloudflare
dig @208.67.222.222 iducation.fr # OpenDNS
dig @9.9.9.9 iducation.fr # Quad9Diagnostic avec dig
dig est l'outil DNS de référence. Nettement plus puissant que nslookup.
# Requête de base
dig iducation.fr
# Type spécifique
dig MX iducation.fr
dig TXT iducation.fr
dig NS iducation.fr
# Tracer la résolution complète depuis les root servers
dig +trace iducation.fr
# Sortie minimaliste
dig +short iducation.fr
# 76.76.21.21
# Interroger un serveur DNS spécifique
dig @8.8.8.8 iducation.fr
# Voir tous les enregistrements d'une zone (si le transfert est autorisé)
dig axfr iducation.fr @ns1.iducation.fr
# Reverse DNS
dig -x 76.76.21.21
# Voir le TTL restant dans le cache d'un résolveur
dig @8.8.8.8 iducation.fr +noall +answer +ttlunitsLire une réponse dig
$ dig iducation.fr
; <<>> DiG 9.18.0 <<>> iducation.fr
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;iducation.fr. IN A
;; ANSWER SECTION:
iducation.fr. 287 IN A 76.76.21.21
# ^^^
# TTL restant dans le cache
;; Query time: 4 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)status: NOERROR — requête réussie. status: NXDOMAIN — domaine inexistant. status: SERVFAIL — erreur serveur (souvent un problème DNSSEC).
DNSSEC : signer ses enregistrements
DNS a été conçu sans authentification. Un attaquant qui peut empoisonner le cache d'un résolveur peut faire croire à l'utilisateur que google.com est à son IP. C'est une attaque réelle, documentée, exploitée.
DNSSEC ajoute des signatures cryptographiques à chaque enregistrement. La chaîne de confiance remonte des root servers jusqu'à votre zone.
# Vérifier si DNSSEC est activé
dig DS iducation.fr
dig DNSKEY iducation.fr
# Résolution avec validation DNSSEC
dig +dnssec iducation.frSi DNSSEC est activé et que la signature est invalide, les résolveurs retournent SERVFAIL plutôt qu'une réponse potentiellement falsifiée.
En pratique : votre registrar et votre hébergeur DNS gèrent DNSSEC. Sur Cloudflare, c'est activable en un clic. La clé DS (Delegation Signer) doit être publiée chez votre registrar.
DNS over HTTPS (DoH) et DNS over TLS (DoT)
Le DNS classique voyage en clair sur UDP port 53. Votre FAI, votre employeur, ou n'importe quel nœud réseau peut voir toutes vos requêtes DNS — et donc tous les sites que vous visitez.
DNS over TLS (DoT) — chiffrement TLS sur le port 853 dédié.
DNS over HTTPS (DoH) — requêtes DNS encapsulées dans du HTTPS standard (port 443). Indiscernable du trafic web normal. Impossible à bloquer par filtrage de port.
Cloudflare 1.1.1.1, Google 8.8.8.8, et Quad9 9.9.9.9 supportent tous DoH et DoT. Firefox et Chrome utilisent DoH par défaut (DoH de Cloudflare ou du résolveur configuré).
# Requête DoH manuellement (via curl)
curl -H 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=iducation.fr&type=A'Attaques DNS courantes
Cache poisoning
Un attaquant envoie des fausses réponses DNS à un résolveur avant que la vraie réponse arrive. Si la fausse réponse est acceptée, le résolveur cache une IP contrôlée par l'attaquant. Tous les utilisateurs de ce résolveur sont redirigés.
Contre-mesure : randomisation des ports source et des identifiants de transaction (Kaminsky patches, 2008), DNSSEC.
DNS hijacking
Compromettre le compte registrar, changer les nameservers. Toutes les requêtes DNS pour votre domaine sont résolues par le serveur de l'attaquant — il peut émettre de faux certificats, intercepter les emails, etc.
Contre-mesures : authentification à deux facteurs sur votre registrar, Registry Lock (bloque les changements NS au niveau du registre TLD — payant, disponible chez certains registrars pour les domaines sensibles).
DNS amplification (DDoS)
Utiliser des résolveurs DNS ouverts pour amplifier du trafic vers une victime. Une petite requête déclenche une grande réponse (facteur d'amplification 70x avec les enregistrements ANY). Des millions de résolveurs ouverts sont utilisés comme réflecteurs.
Contre-mesure pour les opérateurs de résolveurs : activer Response Rate Limiting (RRL), ne pas être un résolveur ouvert.
Typosquatting DNS
Enregistrer iducaton.fr, iducatiion.fr pour intercepter les fautes de frappe. Protégez vos variantes de domaine critiques.
DNS split-brain (Horizon Split)
Un même domaine, deux réponses différentes selon d'où vient la requête. En interne api.iducation.fr pointe vers 192.168.1.10 (IP privée, plus rapide, pas de sortie Internet). En externe, vers 76.76.21.21 (IP publique).
Configuré avec deux zones DNS : une sur un résolveur interne (Pi-hole, Unbound, AD DNS) et une sur votre hébergeur DNS public. Les clients internes utilisent le résolveur interne, les clients externes le résolveur public.
Choisir son hébergeur DNS
Tous les hébergeurs DNS ne sont pas égaux. Critères :
| Critère | Ce qu'il mesure |
|---|---|
| Latence de résolution | Temps de réponse depuis différentes régions |
| Anycast | Distribution géographique des PoPs |
| Uptime | 100% garanti ? SLA ? |
| DNSSEC | Support natif ou manuel ? |
| DoH/DoT | Support ? |
| API | Modification programmatique des enregistrements |
| TTL minimum | Certains limitent à 300s minimum |
Cloudflare DNS (gratuit) : meilleure latence mondiale, Anycast global, DNSSEC en un clic, API complète, TTL minimum 1s. Recommandé pour la majorité des projets.
Route 53 (AWS) : intégration parfaite avec l'écosystème AWS, health checks et routing policies avancés. Payant (0,50$/zone/mois + $0,40/million de requêtes).
Hetzner DNS, Gandi LiveDNS, OVH DNS : gratuits, corrects pour des projets personnels ou professionnels sans contraintes de latence mondiale.
DNS est un protocole vieux de 40 ans — RFC 882 et 883 datent de 1983. Sa conception distribuée et sa robustesse en font l'une des infrastructures les plus fiables d'Internet. Mais cette robustesse a un coût : sa complexité est réelle, ses erreurs de configuration se propagent lentement, et ses failles de sécurité historiques (pas de chiffrement, pas d'authentification) sont comblées progressivement par DNSSEC et DoH.
Quand quelque chose ne fonctionne pas dans votre stack réseau, dig +trace est votre premier réflexe. Il suit la chaîne de délégation depuis les root servers et vous montre exactement où ça bloque.