Que fait le DNS et comment fonctionne-t-il ?

DNS (Domain Name System) est l’infrastructure de nommage distribuée d’internet qui traduit les noms de domaine lisibles par l’homme — tels que example.com — en adresses IP lisibles par les machines comme 93.184.216.34. Sans DNS, chaque requête de navigateur, appel API et livraison d’e-mail nécessiterait que les utilisateurs et les applications connaissent l’adresse numérique exacte de chaque hôte distant, rendant l’internet moderne opérationnellement impossible à grande échelle.

À sa base, DNS est une base de données hiérarchique distribuée à l’échelle mondiale. Ce n’est pas un serveur unique ni un registre centralisé — c’est un arbre de délégation couvrant des centaines de milliers de serveurs de noms faisant autorité dans le monde entier, coordonné par un petit ensemble de serveurs racines et régi par des normes définies dans la RFC 1034 et la RFC 1035.

Pourquoi DNS est bien plus qu’un simple « annuaire téléphonique »

L’analogie avec l’annuaire téléphonique est utile pour les débutants, mais elle sous-estime considérablement ce que DNS fait réellement. DNS est un système de recherche en temps réel, tolérant aux pannes et répliqué à l’échelle mondiale qui gère également :

• Le routage du courrier via les enregistrements MX, dirigeant les e-mails vers les serveurs de messagerie appropriés
• La découverte de services via les enregistrements SRV, utilisés par des protocoles comme SIP, XMPP et le réseau interne Kubernetes
• La vérification de propriété de domaine via les enregistrements TXT, utilisés pour SPF, DKIM, DMARC et Google Search Console
• Le nommage canonique via les enregistrements CNAME, permettant l’intégration CDN et l’équilibrage de charge
• L’adressage IPv6 via les enregistrements AAAA
• Les recherches inversées via les enregistrements PTR dans la zone in-addr.arpa, essentielles pour la réputation des serveurs de messagerie et l’audit de sécurité
• La validation DNSSEC, qui ajoute des signatures cryptographiques aux réponses DNS pour prévenir l’empoisonnement du cache

Chaque fois que vous envoyez un e-mail, vous connectez à un VPN ou chargez une application web, DNS résout plusieurs types d’enregistrements en arrière-plan — souvent des dizaines de requêtes par chargement de page.

La hiérarchie DNS : comment l’espace de noms est structuré

DNS est organisé comme un arbre inversé. Comprendre cette structure est essentiel pour comprendre pourquoi la résolution fonctionne comme elle le fait.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Zone racine (.) : Gérée par l’IANA. Il existe 13 adresses logiques de serveurs racines (A à M), exploitées par des organisations comme Verisign, la NASA et l’ICANN. En pratique, celles-ci sont servies par des centaines de machines physiques via le routage anycast.
• Domaines de premier niveau (TLDs) : TLDs génériques comme .com, .net, .org, et TLDs de code pays comme .uk, .de, .md. Chaque TLD possède son propre ensemble de serveurs de noms faisant autorité.
• Domaines de second niveau (SLDs) : Le domaine que vous enregistrez — example.com. Le DNS faisant autorité pour cette zone est contrôlé par celui qui a enregistré le domaine.
• Sous-domaines : www, mail, api, staging — ce sont des enregistrements dans la zone SLD, entièrement contrôlés par le propriétaire du domaine.

Étape par étape : comment une requête DNS est résolue

Une résolution DNS récursive complète implique jusqu’à sept échanges réseau distincts. Voici la séquence précise :

Étape 1 — Vérification du cache du navigateur

Lorsque vous tapez www.example.com dans votre navigateur, le système d’exploitation vérifie d’abord son cache DNS local. Sur Linux, cela peut être géré par systemd-resolved ; sur Windows, par le service DNS Client. Si un enregistrement mis en cache valide existe et que son TTL (Time to Live) n’a pas expiré, la résolution s’arrête ici.

Vous pouvez inspecter le cache DNS local sur Linux avec :

resolvectl statistics

Ou le vider avec :

sudo resolvectl flush-caches

Sur Windows :

ipconfig /displaydns
ipconfig /flushdns

Étape 2 — Requête au résolveur récursif

Si aucune réponse mise en cache n’existe, le système d’exploitation transmet la requête au résolveur récursif configuré (également appelé serveur DNS récursif ou résolveur à service complet). Il s’agit généralement de :

• Le résolveur de votre FAI (attribué via DHCP)
• Un résolveur public : 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Un résolveur auto-hébergé comme Unbound ou BIND sur votre propre infrastructure VPS Hosting

Le résolveur récursif effectue le gros du travail. Il parcourra la hiérarchie DNS en votre nom et mettra en cache les résultats pour répondre plus rapidement aux requêtes futures.

Étape 3 — Référencement par le serveur racine

Le résolveur récursif interroge l’un des 13 clusters de serveurs racines. Le serveur racine ne connaît pas l’adresse IP de www.example.com. À la place, il renvoie un référencement — une liste de serveurs de noms faisant autorité pour la zone TLD .com, accompagnée de leurs adresses IP (appelées enregistrements glue).

Étape 4 — Requête au serveur de noms TLD

Le résolveur interroge les serveurs de noms TLD .com (exploités par Verisign). Ces serveurs ne détiennent pas non plus la réponse finale. Ils renvoient un autre référencement — les serveurs de noms faisant autorité pour example.com spécifiquement (par exemple, ns1.example.com, ns2.example.com).

Étape 5 — Requête au serveur de noms faisant autorité

Le résolveur interroge le serveur de noms faisant autorité pour example.com. Ce serveur détient le fichier de zone réel et renvoie la réponse définitive — l’enregistrement A contenant l’adresse IPv4 (ou AAAA pour IPv6).

Étape 6 — Mise en cache de la réponse et livraison

Le résolveur récursif met en cache la réponse selon la valeur TTL de l’enregistrement (par exemple, 300 secondes = 5 minutes, 86400 secondes = 24 heures). Il renvoie ensuite l’adresse IP au système d’exploitation du client, qui la transmet au navigateur.

Étape 7 — Connexion TCP/IP

Le navigateur utilise l’adresse IP résolue pour ouvrir une connexion TCP (généralement sur le port 443 pour HTTPS). Le travail de DNS est maintenant terminé. Le serveur web répond et la page se charge.

L’ensemble de ce processus — étapes 2 à 6 — se termine généralement en 20 à 120 millisecondes avec un cache de résolveur chaud, et en moins de 500 millisecondes pour une résolution entièrement froide et non mise en cache traversant tous les niveaux de la hiérarchie.

Types d’enregistrements DNS : une référence technique

Les enregistrements CAA méritent une mention spéciale : ils indiquent aux autorités de certification quelles organisations sont autorisées à émettre des Certificats SSL pour votre domaine — un contrôle de sécurité critique qui est fréquemment négligé.

Types de requêtes DNS : récursif vs. itératif vs. non récursif

La plupart des appareils d’utilisateurs finaux envoient des requêtes récursives à leur résolveur configuré. Le résolveur lui-même utilise des requêtes itératives lors de la traversée de la hiérarchie.

TTL : le paramètre DNS le plus mal compris

Le TTL (Time to Live) est le nombre de secondes pendant lesquelles un enregistrement DNS peut être mis en cache par les résolveurs et les clients. Il est défini par le propriétaire du domaine dans le fichier de zone.

• TTL faible (60–300 secondes) : Propagation plus rapide des modifications. Essentiel avant les migrations planifiées, les changements d’IP ou les événements de basculement. Augmente la charge de requêtes sur les serveurs faisant autorité.
• TTL élevé (3600–86400 secondes) : Réduit la charge du résolveur et accélère les requêtes répétées. Les modifications prennent plus de temps à se propager à l’échelle mondiale.

Conseil opérationnel critique : Lors de la planification d’une migration de serveur ou d’un changement d’IP, réduisez votre TTL à 300 secondes au moins 48 heures avant le changement. Cela garantit qu’au moment où vous mettez à jour l’enregistrement A, aucun résolveur ne met en cache l’ancienne valeur pendant plus de 5 minutes. Ne pas le faire est l’une des causes les plus courantes de temps d’arrêt prolongé lors des migrations.

Lorsque vous enregistrez un domaine via l’Enregistrement de domaine et que vous le pointez vers un nouveau serveur, la fenêtre de propagation est directement régie par la valeur TTL précédente — et non par une règle arbitraire de « 24 à 48 heures » souvent citée incorrectement.

Protocoles de transport DNS : UDP, TCP, DoH et DoT

Le DNS traditionnel fonctionne sur le port UDP 53 pour les requêtes inférieures à 512 octets. Les réponses dépassant cette taille déclenchent un repli sur le port TCP 53. Les réponses DNSSEC, les transferts de zone (AXFR) et les grands enregistrements TXT nécessitent couramment TCP.

Les protocoles DNS modernes axés sur la confidentialité ont considérablement modifié ce paysage :

DoH vs. DoT — la vraie différence opérationnelle : DoH encapsule DNS dans le trafic HTTPS sur le port 443, le rendant indiscernable du trafic web ordinaire. C’est utile pour la confidentialité, mais rend la surveillance et le filtrage du réseau d’entreprise considérablement plus difficiles. DoT utilise un port dédié (853), que les administrateurs réseau peuvent surveiller, bloquer ou inspecter indépendamment. Pour une infrastructure autogérée sur un Serveur dédié, l’exécution d’un résolveur DoT ou DoH local vous offre à la fois confidentialité et contrôle total de la politique de résolution.

DNSSEC : intégrité cryptographique pour DNS

Les extensions de sécurité DNS (DNSSEC) ajoutent une chaîne de signatures cryptographiques aux réponses DNS, permettant aux résolveurs de vérifier qu’une réponse est authentique et n’a pas été altérée en transit. Elles protègent contre l’empoisonnement du cache DNS (attaque Kaminsky) et l’usurpation DNS par attaque de l’homme du milieu.

DNSSEC ne chiffre pas le trafic DNS — il le signe uniquement. La chaîne de signatures fonctionne comme suit :

1. Le propriétaire de la zone génère une clé de signature de zone (ZSK) et une clé de signature de clé (KSK)
2. Chaque ensemble d’enregistrements DNS est signé avec la ZSK, produisant des enregistrements RRSIG
3. La KSK signe l’ensemble d’enregistrements DNSKEY
4. Un enregistrement DS (Delegation Signer) est publié dans la zone parente (par exemple, .com), créant la chaîne de confiance jusqu’à la racine

L’activation de DNSSEC est fortement recommandée pour tout domaine gérant des transactions financières, de l’authentification ou des e-mails. Un DNSSEC mal configuré — en particulier une signature expirée ou un enregistrement DS non concordant — entraînera un échec de résolution complet pour les résolveurs validants, ce qui est un mode d’échec plus difficile à gérer que l’absence totale de DNSSEC.

Pannes DNS courantes et comment les diagnostiquer

NXDOMAIN — Domaine inexistant

Le serveur faisant autorité a confirmé que le domaine n’existe pas. Causes courantes : faute de frappe dans le nom de domaine, expiration de l’enregistrement du domaine, enregistrement DNS supprimé.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Échec du serveur

Le résolveur n’a pas pu compléter la requête. Causes courantes : échec de validation DNSSEC, serveur faisant autorité inaccessible, fichier de zone mal configuré.

dig +dnssec example.com
# Look for: status: SERVFAIL

Pour contourner la validation DNSSEC et isoler le problème :

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Cache périmé / Délai de propagation

Après la mise à jour d’un enregistrement DNS, les anciennes valeurs persistent dans les caches des résolveurs jusqu’à l’expiration du TTL. Pour interroger directement le serveur faisant autorité et contourner le cache du résolveur :

dig @ns1.example.com www.example.com

Vérification de la propagation DNS à l’échelle mondiale

Utilisez dig avec des résolveurs publics spécifiques pour vérifier l’état de propagation :

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS dans les environnements d’hébergement : configurations pratiques

Lorsque vous déployez un site web ou une application sur un VPS avec cPanel, la gestion DNS est généralement assurée via le cluster DNS de WHM ou l’éditeur de zone de cPanel. Comprendre la structure sous-jacente du fichier de zone vous permet d’effectuer des modifications que l’interface graphique n’expose pas.

Un fichier de zone minimal pour example.com ressemble à ceci :

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Pour que l’Hébergement e-mail fonctionne correctement, l’enregistrement MX doit pointer vers un nom d’hôte (et non directement vers une adresse IP), et ce nom d’hôte doit lui-même se résoudre via un enregistrement A. Une erreur de configuration courante consiste à pointer MX directement vers une IP — cela viole la RFC 2821 et provoque des échecs de livraison avec les serveurs de messagerie stricts.

Performances DNS : ce qui affecte réellement la vitesse de résolution

• Proximité du résolveur : Un résolveur géographiquement proche du client (ou sur le même réseau) réduit considérablement le temps d’aller-retour.
• Taux de succès du cache : Les domaines à fort trafic avec des TTL raisonnables sont presque toujours servis depuis le cache. La résolution avec cache froid est 5 à 20 fois plus lente.
• Routage anycast : Les serveurs racines et les principaux résolveurs publics utilisent l’anycast, acheminant automatiquement les requêtes vers le nœud physique le plus proche.
• Nombre de recherches DNS par page : Une seule page web peut déclencher 20 à 50 requêtes DNS (ressources CDN, analytics, polices, réseaux publicitaires). Les navigateurs les parallélisent, mais chaque nom d’hôte unique nécessite sa propre recherche.
• Prélecture DNS : Les navigateurs modernes prennent en charge <link rel="dns-prefetch" href="//cdn.example.com"> pour résoudre les noms d’hôtes tiers avant qu’ils ne soient nécessaires, réduisant ainsi la latence perçue.

DNS vs. mécanismes de résolution alternatifs

Le fichier /etc/hosts est évalué avant DNS sur pratiquement tous les systèmes d’exploitation. Cela le rend précieux pour le développement local — vous pouvez associer myapp.local à 127.0.0.1 sans toucher à aucune infrastructure DNS.

Points clés et liste de contrôle décisionnelle

Utilisez cette liste de contrôle lors de la configuration ou du dépannage DNS pour tout environnement de production :

• Avant toute migration de serveur : Réduisez le TTL à 300 secondes au moins 48 heures à l’avance
• Pour la délivrabilité des e-mails : Vérifiez que les enregistrements MX, SPF (TXT), DKIM (TXT), DMARC (TXT) et PTR sont tous correctement configurés
• Pour la sécurité : Activez DNSSEC sur votre domaine et ajoutez des enregistrements CAA pour restreindre l’émission de certificats
• Pour la confidentialité : Utilisez DoT ou DoH sur les appareils clients et les serveurs ; évitez d’envoyer du DNS en clair sur des réseaux non fiables
• Pour les performances : Définissez le TTL à 3600–86400 pour les enregistrements stables ; utilisez 300 uniquement pour les enregistrements qui changent fréquemment
• Pour les diagnostics : Interrogez toujours directement le serveur faisant autorité avec dig @ns1.yourdomain.com pour distinguer le délai de propagation d’une véritable erreur de configuration
• Pour la gestion de zone : Incrémentez le numéro de série SOA à chaque modification d’un fichier de zone — les résolveurs l’utilisent pour détecter les changements
• Pour l’hébergement : Confirmez que la délégation des serveurs de noms de votre registraire correspond aux enregistrements NS dans votre fichier de zone — une discordance est la cause la plus courante de « DNS ne fonctionne pas » après un transfert de domaine

Foire aux questions

Quelle est la différence entre un résolveur DNS et un serveur DNS faisant autorité ?

Un résolveur récursif (par exemple, 8.8.8.8) est un intermédiaire qui interroge la hiérarchie DNS au nom de votre appareil et met en cache les résultats. Un serveur de noms faisant autorité détient les enregistrements de zone réels pour un domaine spécifique et fournit des réponses définitives. Votre résolveur interroge de nombreux serveurs faisant autorité ; le serveur faisant autorité de votre domaine répond uniquement pour les zones qu’il héberge.

Pourquoi la propagation DNS prend-elle du temps après la mise à jour d’un enregistrement ?

Le délai de propagation est causé par la mise en cache basée sur le TTL. Chaque résolveur ayant précédemment mis en cache votre ancien enregistrement continuera à le servir jusqu’à l’expiration du TTL. Si votre TTL était de 86400 (24 heures), les résolveurs peuvent servir l’ancien enregistrement pendant jusqu’à 24 heures après votre mise à jour. Ce n’est pas un bug — c’est le mécanisme de mise en cache prévu qui rend DNS évolutif.

Qu’est-ce qu’une fuite DNS et pourquoi est-ce important ?

Une fuite DNS se produit lorsque votre appareil envoie des requêtes DNS en dehors de votre résolveur prévu — généralement le résolveur de votre FAI — même lors de l’utilisation d’un VPN ou d’un outil de confidentialité. Cela expose votre activité de navigation à votre FAI. Vous pouvez tester les fuites sur dnsleaktest.com et les corriger en configurant votre client VPN pour forcer le routage DNS via son propre résolveur.

DNS peut-il être utilisé comme vecteur d’attaque ?

Oui. Les attaques courantes basées sur DNS incluent l’empoisonnement du cache (injection de faux enregistrements dans le cache d’un résolveur), l’amplification DNS DDoS (utilisation de résolveurs ouverts pour inonder une cible de grandes réponses DNS), le détournement DNS (redirection des requêtes vers des serveurs malveillants) et le tunneling DNS (exfiltration de données en les encodant dans des chaînes de requêtes DNS). DNSSEC atténue l’empoisonnement du cache ; la limitation de débit et la limitation du taux de réponse (RRL) sur les serveurs faisant autorité atténuent l’amplification.

Comment trouver les serveurs de noms faisant autorité pour n’importe quel domaine ?

Utilisez dig avec le type d’enregistrement NS et l’indicateur +short pour une sortie propre :

dig NS example.com +short

Pour tracer le chemin de délégation complet de la racine à l’autorité, utilisez :

dig +trace example.com

Cela montre chaque saut de référencement — racine → TLD → faisant autorité — ce qui est la méthode la plus fiable pour diagnostiquer les erreurs de configuration de délégation.