Dans un récent article, dns-ok.fr rappelait que changer de résolveur DNS ne suffit pas pour être anonyme. Le constat est juste, mais il ne couvre qu’une moitié du sujet. L’autre moitié — invisible côté utilisateur — concerne les serveurs DNS qui répondent pour vos propres noms de domaine. Comprendre cette distinction, c’est comprendre ce qui sépare un service web qui tient debout d’un service qui disparaît au premier incident réseau sérieux.
Le DNS que vous connaissez : les résolveurs
Quand on parle de « changer de DNS », on parle presque toujours de résolveurs. Ces serveurs — 8.8.8.8 chez Google, 1.1.1.1 chez Cloudflare, 9.9.9.9 chez Quad9 — se chargent de traduire les noms de domaine en adresses IP pour votre navigateur. Ils interrogent la hiérarchie DNS, mettent en cache les réponses et renvoient le résultat. Leur enjeu principal : performance, confidentialité (qui voit vos requêtes ?) et filtrage éventuel. C’est ce versant qu’aborde l’article précédent — et à juste titre, puisque tout le monde utilise un résolveur, souvent sans savoir lequel.
Le DNS qu’on oublie : les serveurs autoritatifs
À l’autre bout de la chaîne, il y a les serveurs autoritatifs. Ce sont eux qui détiennent la vérité pour une zone DNS donnée. Quand votre résolveur veut connaître l’adresse IP d’un domaine, il finit par interroger les serveurs autoritatifs déclarés pour ce domaine — les fameux enregistrements NS. Contrairement aux résolveurs, ces serveurs n’ont pas à être rapides pour tout le monde : ils doivent être joignables tout le temps. Si vos serveurs autoritatifs tombent, plus aucun résolveur au monde ne peut apprendre où joindre vos services. Ni vos sites, ni vos emails, ni vos API. Le service disparaît même s’il fonctionne parfaitement à l’intérieur.
Pourquoi deux serveurs chez le même hébergeur ne suffisent pas
Le piège classique : déclarer ns1.hebergeur.com et ns2.hebergeur.com. Sur le papier, deux serveurs. En pratique, un seul point de défaillance : si l’hébergeur subit une panne (coupure réseau, incident BGP, attaque DDoS), les deux serveurs tombent ensemble.
La RFC 2182, publiée dès 1997 et toujours d’actualité, recommandait déjà de répartir les serveurs autoritatifs sur des infrastructures indépendantes — topologiquement et géographiquement. Les recommandations APNIC 2025 vont plus loin : serveurs répartis sur 3 à 4 opérateurs réseau distincts (ASN différents) pour résister non seulement aux pannes matérielles, mais aussi aux coupures BGP qui frappent régulièrement les transitaires. On parle alors d’architecture DNS multi-ASN : chaque serveur est joignable par un chemin réseau différent, de sorte qu’aucune panne d’opérateur ne peut faire disparaître toute la zone.
Les deux faces se complètent
La confidentialité se joue côté résolveur : qui voit vos requêtes, lesquelles sont mémorisées, lesquelles sont filtrées. La disponibilité se joue côté autoritatif : combien de pannes consécutives vos serveurs peuvent absorber avant que votre nom de domaine cesse d’exister pour le reste d’Internet. Les deux préoccupations sont légitimes, elles nécessitent des choix techniques distincts, et elles devraient toutes deux faire partie d’une réflexion DNS sérieuse. L’anonymat côté client, la résilience côté serveur : ce sont les deux piliers d’une posture DNS mature.