Les enregistrements DNS expliqués : le modèle en 30 secondes
Tous les incidents « mon site est down » et la moitié des « mes emails partent en spam » remontent au DNS. Pourtant le DNS en soi est simple : c'est un annuaire distribué qui associe des noms à des valeurs, avec du cache agressif par-dessus. C'est le cache qui le fait paraître mystérieux.
Voici la résolution en 30 secondes. Quand ton navigateur demande app.example.com, ton OS interroge un résolveur (celui de ton FAI, ou 1.1.1.1 / 8.8.8.8). Si le résolveur n'a pas la réponse en cache, il remonte la hiérarchie : les serveurs racine le renvoient vers les serveurs .com, qui le renvoient vers les serveurs de noms autoritaires de example.com (ceux configurés chez ton registrar), qui retournent l'enregistrement. Le résolveur met cette réponse en cache pendant le TTL de l'enregistrement (time-to-live, en secondes) et la sert depuis son cache jusqu'à expiration.
C'est tout. Le reste, ce sont des types d'enregistrements et du comportement de cache.
À quoi servent les principaux types d'enregistrements DNS ?
| Enregistrement | Associe un nom à... | Usage typique |
|---|---|---|
| A | Une adresse IPv4 | example.com → 203.0.113.10 |
| AAAA | Une adresse IPv6 | example.com → 2001:db8::1 |
| CNAME | Un autre nom (alias) | www → example.com, app → myapp.pages.dev |
| MX | Hostname de serveur mail + priorité | Où livrer les emails de @example.com |
| TXT | Du texte libre | SPF, DKIM, DMARC, vérification de propriété |
| NS | Les serveurs de noms autoritaires | Délègue la zone (ex. à Cloudflare) |
| SOA | Métadonnées de zone | Numéro de série, timers — quasi automatique |
| CAA | Autorités de certification autorisées | 0 issue "letsencrypt.org" bloque les certs pirates |
| SRV | Hôte + port d'un service | SIP, XMPP, certains protocoles de jeu/fédération |
Quelques règles qui piègent tout le monde :
- Un CNAME ne peut coexister avec aucun autre enregistrement sur le même nom. C'est pour ça qu'on ne peut pas mettre de CNAME à l'apex du domaine (
example.com) — l'apex doit porter les enregistrements SOA et NS. On y revient plus bas. - Les MX pointent vers des hostnames, jamais des IPs — et ce hostname doit se résoudre via un A/AAAA, pas un CNAME.
- Les TXT, c'est là que vit l'email moderne. SPF, DKIM et DMARC ne sont que des enregistrements TXT avec des conventions.
Tu peux inspecter tout ça pour n'importe quel domaine avec un DNS Lookup — interroge chaque type d'enregistrement et vois exactement ce que le monde voit.
Le TTL et le mythe de la propagation
« La propagation DNS prend 24 à 48 heures » est l'une des demi-vérités les plus tenaces de la tech. Le DNS ne pousse aucun changement nulle part. Quand tu modifies un enregistrement, le serveur autoritaire répond avec la nouvelle valeur immédiatement. Ce qui prend du temps, c'est l'expiration des caches : chaque résolveur qui a interrogé ton enregistrement avant le changement continue de servir l'ancienne réponse jusqu'à ce que le TTL de sa copie expire.
Conséquences pratiques :
- Baisse le TTL avant un changement planifié. Si ton enregistrement a un TTL de 24 h, descends-le à 300 (5 minutes) au moins 24 heures avant le jour de la migration. Une fois la bascule faite, remonte-le.
- Pendant la fenêtre, des utilisateurs différents voient des résultats différents — c'est normal, ce sont les caches de leurs résolveurs à des stades différents.
- Un vérificateur de propagation DNS interroge des résolveurs du monde entier d'un coup et te montre exactement quelles régions ont la nouvelle valeur et lesquelles servent encore du cache périmé.
# Voir le TTL restant décompter sur une réponse en cache
dig example.com A +noall +answer
# example.com. 212 IN A 203.0.113.10 ← 212 secondes restantes dans le cache de ce résolveur
Les tâches courantes, bien faites
Pointer un domaine vers un serveur
Domaine racine → enregistrement A vers l'IP du serveur. www → CNAME vers la racine. Hébergé sur une plateforme (Vercel, Cloudflare Pages, GitHub Pages) ? Elle te donnera soit une IP pour un A, soit un hostname cible pour un CNAME — suis sa doc à la lettre, car les IPs de plateforme peuvent changer.
Le problème du CNAME à l'apex
Les plateformes adorent dire « mets juste un CNAME de ton domaine vers myapp.platform.dev » — mais la RFC interdit le CNAME à l'apex. Solutions : un fournisseur DNS avec CNAME flattening ou enregistrements ALIAS/ANAME (Cloudflare, Route 53, DNSimple), ou rediriger l'apex vers www et mettre le CNAME sur www.
Les enregistrements email : SPF, DKIM, DMARC
Trois enregistrements TXT décident si tes emails arrivent en boîte de réception :
; SPF — qui a le droit d'envoyer du mail en ton nom
example.com. TXT "v=spf1 include:_spf.google.com -all"
; DKIM — clé publique pour vérifier la signature de tes messages
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
; DMARC — quoi faire côté destinataire quand SPF/DKIM échouent
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Pièges : un seul enregistrement SPF par domaine (plusieurs = SPF échoue entièrement), maximum 10 lookups DNS dans la chaîne SPF, et démarre DMARC en p=none pour observer avant de durcir.
Un workflow de débogage pour « le domaine ne marche pas »
Procède du haut vers le bas — chaque étape élimine une couche :
1. Le domaine existe-t-il seulement, et pointe-t-il où tu crois ? Un WHOIS Lookup montre le statut d'enregistrement, la date d'expiration (le domaine expiré est un grand classique du plantage silencieux) et les serveurs de noms délégués. Si les nameservers déclarés chez le registrar ne sont pas ceux où tu édites tes enregistrements, rien de ce que tu changes ne prendra jamais effet.
2. Les serveurs autoritaires renvoient-ils la bonne réponse ?
dig @ns1.ton-fournisseur-dns.com example.com A +short
Interroger l'autoritaire en direct contourne tout le cache. Mauvaise réponse ici = l'enregistrement lui-même est faux ou absent.
3. Les résolveurs publics sont-ils d'accord ?
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
Autoritaire correct mais résolveurs en retard → c'est une attente de TTL, pas un bug. Vérifie l'état mondial avec un checker de propagation plutôt que de rafraîchir en panique.
4. Est-ce vraiment le DNS ? Si le nom se résout mais que le site échoue quand même, le DNS est innocent. Vérifie que le serveur répond sur les ports 80/443, et que le certificat correspond bien au hostname avec un SSL Checker — un certificat émis pour l'ancien domaine, ou expiré, produit des erreurs qui ressemblent à des problèmes DNS mais n'en sont pas.
5. Vide ton cache local en dernier. sudo systemd-resolve --flush-caches (Linux), sudo dscacheutil -flushcache (macOS), ipconfig /flushdns (Windows). Les navigateurs ont aussi leur propre cache DNS — chrome://net-internals/#dns.
L'ordre compte : la plupart des gens commencent par l'étape 5 et remontent, perdant une heure à vider des caches alors que le vrai problème était la délégation de nameservers à l'étape 1.
Vérifie n'importe quel domaine maintenant
Lance un DNS Lookup sur n'importe quel domaine et vois ses enregistrements A, CNAME, MX, TXT et NS en quelques secondes. Aucun compte requis.