infra / reseaux-tcp-ip
DNS (résolution, types d'enregistrements)
Explication
Ce que vous allez apprendre
- Comprendre le rôle du DNS et sa hiérarchie distribuée (racine, TLD, serveurs faisant autorité)
- Interroger un enregistrement DNS avec
diget lire sa réponse (A, MX, TXT, NS...) - Distinguer les principaux types d'enregistrements et savoir à quoi chacun sert
- Comprendre le rôle du TTL dans la mise en cache et la "propagation" d'un changement DNS
- Diagnostiquer une résolution DNS incohérente en interrogeant plusieurs résolveurs publics
Dans quel contexte ?
Une équipe vient de migrer son site exemple.com vers un nouvel hébergeur et a mis à jour l'enregistrement A chez son registrar. Deux heures plus tard, certains visiteurs voient encore l'ancien site, d'autres le nouveau. Plutôt que de paniquer, l'administrateur interroge dig @8.8.8.8 exemple.com +short et dig @1.1.1.1 exemple.com +short : les résultats diffèrent, ce qui confirme que c'est simplement le TTL de l'ancien enregistrement qui n'a pas encore expiré partout — pas une panne.
L'annuaire téléphonique d'Internet
Personne ne retient les adresses IP des sites qu'on visite : on retient des noms (exemple.com). Le DNS (Domain Name System) est le système qui fait le lien entre ces deux mondes, en traduisant un nom lisible par un humain en adresse IP exploitable par les machines. Sans lui, naviguer sur Internet nécessiterait de mémoriser des suites de chiffres pour chaque site.
| Type d'enregistrement | Rôle | Exemple |
|---|---|---|
| A | Nom vers IPv4 | exemple.com -> 203.0.113.10 |
| AAAA | Nom vers IPv6 | exemple.com -> 2001:db8::1 |
| CNAME | Alias vers un autre nom | www.exemple.com -> exemple.com |
| MX | Serveur de messagerie | mail.exemple.com (priorité 10) |
| TXT | Texte libre (SPF, DKIM) | vérification de propriété du domaine |
Prérequis
Il est utile d'être déjà à l'aise avec la notion d'adresse IP (leçon précédente) : le DNS ne fait que faire correspondre un nom à une IP, il ne remplace pas l'adressage IP lui-même.
Un annuaire distribué, pas centralisé
Il serait irréaliste qu'un seul serveur au monde connaisse toutes les correspondances nom-vers-IP. Le DNS est organisé de façon hiérarchique et distribuée : des serveurs racine, puis des serveurs faisant autorité pour chaque domaine, se répartissent la responsabilité. C'est cette architecture qui permet au système de tenir à l'échelle d'Internet entier, sans point de défaillance unique.
Pourquoi il existe plusieurs types d'enregistrements
Un domaine ne sert pas qu'à héberger un site web : il peut aussi recevoir des emails, prouver qu'il t'appartient, ou pointer vers un service précis. Chaque type d'enregistrement DNS (A, MX, TXT...) répond à un besoin différent, ce qui explique pourquoi la configuration DNS d'un domaine professionnel contient souvent bien plus qu'une simple entrée A.
Le TTL : un compromis entre fraîcheur et performance
Interroger le DNS à chaque requête serait lent. Les réponses sont donc mises en cache pendant une durée définie par le TTL. C'est ce même mécanisme qui explique pourquoi un changement DNS met parfois du temps à "se propager" partout : ce n'est pas une propagation active, mais simplement l'expiration progressive des caches existants un peu partout dans le monde.
Bonne pratique
Avant une migration planifiée (changement d'hébergeur, de serveur mail...), abaisse le TTL de l'enregistrement concerné (par exemple à 300 secondes) plusieurs heures à l'avance. Une fois la migration faite et validée, tu peux remonter le TTL à une valeur plus longue (3600s ou plus) pour réduire la charge sur tes serveurs DNS.
Commandes & code
DNS : résolution et enregistrements
# Résolution de base
dig exemple.com # requête complète (question + réponse + autorité)
dig +short exemple.com # juste l'IP
dig exemple.com MX # enregistrements MX (serveurs mail)
dig exemple.com NS # serveurs de noms faisant autorité
dig exemple.com TXT # enregistrements texte (SPF, vérifications...)
dig exemple.com ANY # tous les types (souvent restreint par les résolveurs)
dig -x 8.8.8.8 # reverse DNS (IP -> nom)
dig @8.8.8.8 exemple.com # interroge un résolveur DNS précis
dig +trace exemple.com # trace toute la chaîne depuis la racine# Types d'enregistrements DNS courants
A -> nom vers IPv4 exemple.com -> 203.0.113.10
AAAA -> nom vers IPv6 exemple.com -> 2001:db8::1
CNAME -> alias vers un autre nom www.exemple.com -> exemple.com
MX -> serveur de messagerie, avec priorité mail.exemple.com (priorité 10)
TXT -> texte libre (SPF, DKIM, vérif domaine)
NS -> serveurs faisant autorité pour la zone
SOA -> Start Of Authority : infos de la zone (serial, TTL...)
PTR -> reverse DNS, IP vers nom (zone in-addr.arpa)
SRV -> localise un service (port + hôte), ex: _sip._tcp.exemple.com
CAA -> autorise quelles autorités de certification peuvent émettre un certif pour ce domaine# Résolution locale : ordre de résolution défini par /etc/nsswitch.conf (hosts: files dns)
cat /etc/hosts # résolution manuelle, prioritaire sur le DNS
# 127.0.0.1 localhost
# 10.0.0.5 db-interne.local
cat /etc/resolv.conf # serveurs DNS utilisés par la machine
# nameserver 1.1.1.1
# nameserver 8.8.8.8
# Vider le cache DNS local (varie selon la distribution/le service utilisé)
sudo systemd-resolve --flush-caches
resolvectl status # état de la résolution DNS gérée par systemd-resolved
resolvectl query exemple.com
# TTL : durée de mise en cache d'un enregistrement, en secondes
dig exemple.com | grep -A1 "ANSWER SECTION"
# exemple.com. 300 IN A 203.0.113.10 <- TTL de 300s = 5 minutes
# Debug d'une propagation DNS lente après un changement
dig @8.8.8.8 exemple.com +short # ce que voit Google
dig @1.1.1.1 exemple.com +short # ce que voit Cloudflare
# Si les résultats diffèrent : propagation en cours, attendre l'expiration du TTL précédentRésumé
digest l'outil de référence ;+shortpour l'essentiel,+tracepour comprendre une chaîne de résolution.- A/AAAA pointent vers une IP, CNAME vers un autre nom, MX vers un serveur mail, TXT sert à la vérification/SPF/DKIM.
- Le TTL contrôle combien de temps un changement DNS met à se propager dans les caches intermédiaires.
Exercices pratiques
Mission : traquer une résolution DNS incohérente après migration
Objectif : Diagnostiquer pourquoi un sous-domaine reste sur l'ancien hébergeur après une migration, malgré un TTL abaissé sur l'enregistrement principal.
Contexte
exemple.com a migré d'hébergeur. L'enregistrement A de l'apex a été abaissé à un TTL de 300s avant la bascule, comme recommandé. Mais www.exemple.com est en réalité un CNAME vers cdn-ancien-hebergeur.net, dont le TTL est resté à 86400s (24h) car personne n'y a pensé.
Deux heures après la migration, exemple.com fonctionne pour tout le monde, mais www.exemple.com pointe encore vers l'ancien hébergeur pour une partie des visiteurs.