TL;DRQuand un internaute tape l’adresse de ton site dans son navigateur, le premier maillon de la chaîne n’est ni ton serveur web, ni ton CDN : c’est le serveur DNS.

Choisir un serveur DNS rapide et fiable pour ton hébergement web permet de réduire la latence, d’améliorer le Time To First Byte (TTFB) et d’éviter des erreurs de résolution qui rendent ton site inaccessible, même si ton serveur tourne parfaitement. C’est un sujet qu’on pratique au quotidien depuis 2010, en gérant les DNS de dizaines de sites ecommerce, jusqu’à installer nos propres serveurs BIND9 pour certains projets.

Sommaire de l’article#

Qu’est-ce qu’un serveur DNS et à quoi sert-il ?#

DNS signifie Domain Name System. Un serveur DNS est une machine (ou un cluster) qui traduit les noms de domaine lisibles par l’humain (comme exemple.com) en adresses IP (comme 203.0.113.10) compréhensibles par les machines.

Sans cette traduction, le navigateur ne peut pas trouver le serveur qui héberge ton site. Un serveur DNS est donc un peu l’« annuaire » de l’Internet : à chaque fois qu’un utilisateur tape ton domaine ou clique sur un lien vers ton site, une résolution DNS intervient avant le moindre octet de HTML. Si cette étape est lente ou bancale, toutes les optimisations côté serveur ou front sont pénalisées.

Comment fonctionne la résolution DNS en coulisses ?#

Comprendre comment la résolution DNS fonctionne t’aide à voir où la lenteur peut s’introduire et pourquoi le choix et la configuration de ton serveur DNS ont un impact direct sur la vitesse de ton site.

  • Le navigateur vérifie d’abord son cache local (et parfois le système d’exploitation) pour voir s’il connaît déjà l’IP du domaine.
  • Si ce n’est pas le cas, il interroge un résolveur DNS (souvent celui de ton FAI, de ton routeur ou d’un DNS public comme 1.1.1.1 ou 8.8.8.8).
  • Ce résolveur interroge les serveurs racine DNS, puis les serveurs TLD (.com, .fr, etc.) pour trouver l’autorité de ton domaine.
  • Il interroge enfin le serveur DNS autoritaire de ton domaine (là où ta zone est hébergée) pour obtenir l’enregistrement A/AAAA.
  • La réponse est renvoyée au navigateur, stockée dans des caches intermédiaires (résolveur, OS, navigateur) selon le TTL.
  • Une fois l’IP connue, le navigateur peut alors établir une connexion avec ton serveur web (HTTP/HTTPS).

Les différents types de serveurs DNS#

Dans la pratique, plusieurs catégories de serveurs DNS interviennent dans cette chaîne. Les distinguer te permet de savoir sur quoi tu as la main (et sur quoi tu ne l’as pas), surtout quand tu dois gérer des mises en production pour des ecommerces.

Les rôles principaux dans l’écosystème DNS#

On peut simplifier l’architecture DNS en quelques types de serveurs aux rôles bien distincts.

Serveurs DNS racine#

Ce sont les serveurs au sommet de la hiérarchie DNS. Ils connaissent les serveurs des domaines de premier niveau (TLD) comme .com, .net, .fr, etc. Ils ne connaissent pas ton site, mais dirigent les résolveurs vers les bons TLD.

Serveurs TLD (.com, .fr, etc.)#

Les serveurs TLD stockent les informations sur les zones DNS des domaines d’un certain TLD (par exemple tous les .fr). Ils indiquent aux résolveurs où se trouvent les serveurs DNS autoritaires pour ton domaine.

Serveurs DNS résolveurs (ou récursifs)#

Ce sont les serveurs DNS auxquels ton navigateur parle en premier (ceux de ton FAI, de ton routeur ou d’un DNS public). Ils se chargent de faire toutes les requêtes nécessaires (racine, TLD, autoritaires) pour obtenir la réponse et la renvoyer au client.

Serveurs DNS autoritaires#

Ce sont les serveurs qui hébergent réellement ta zone DNS : les enregistrements A, AAAA, MX, TXT, etc. C’est là que tu configures ce qui pointe vers ton hébergement, ton mail, ton CDN, etc. C’est typiquement là qu’on intervient en agence lorsqu’on met en production un nouveau site ou qu’on migre un ecommerce.

Serveurs DNS publics (Cloudflare, Google, OpenDNS, etc.)#

Il s’agit de résolveurs ouverts au public, comme Cloudflare (1.1.1.1), Google DNS (8.8.8.8), OpenDNS, Quad9… Ils peuvent être utilisés au niveau de tes machines, de ton routeur ou parfois comme résolveurs pour ton infrastructure.

Serveurs DNS de ton hébergeur#

La plupart des hébergeurs (OVH, o2switch, Infomaniak, etc.) proposent leurs propres serveurs DNS autoritaires. Ils sont utilisés par défaut lorsque tu configures ton domaine via leur interface. Dans nos projets, nous partons souvent de ces DNS avant de migrer vers un DNS managé plus avancé comme Cloudflare.

DNS gérés (DNS managés, premium, anycast)#

Certains providers proposent des services de DNS managé avec des serveurs anycast répartis dans le monde, une haute disponibilité, et des fonctions avancées (géolocalisation, filtrage, load balancing, etc.). Ils sont particulièrement utiles pour les sites à fort trafic, les ecommerces à plus de 1 M€/an ou les architectures multi-régions.

Pourquoi la vitesse du DNS est si importante#

À chaque nouvelle visite (ou quand le cache expire), ton utilisateur doit passer par cette chaîne de résolution DNS avant de voir la moindre page de ton site.

Un serveur DNS lent ou mal configuré ajoute de la latence avant même que ton serveur web n’entre en jeu. Sur des connexions lentes ou sur mobile, cela peut se traduire par un TTFB plus élevé, un ressenti de lenteur, voire des erreurs de résolution si le DNS ne répond pas correctement. Lorsqu’on audite un site, on commence d’ailleurs souvent par vérifier cette couche avant de toucher à la stack applicative.

Critères pour choisir un serveur DNS rapide#

Choisir un serveur DNS rapide ne consiste pas seulement à prendre le plus « connu » (Cloudflare, Google…) mais à prendre en compte la localisation de tes utilisateurs, la qualité de l’infrastructure et la façon dont tu comptes gérer ta zone DNS.

Trois critères clés pour évaluer la vitesse DNS#

Voici trois axes à regarder de près avant de trancher.

  1. Latence moyenne de résolution (temps moyen pour obtenir une réponse pour ton domaine).
  2. Réseau et architecture (anycast, nombre de points de présence, peering avec les FAI de ta cible).
  3. Performance et fiabilité de tes DNS autoritaires (là où ta zone est réellement hébergée).

Tu peux tester différents résolveurs DNS publics et solutions de DNS managé avec des outils comme DNSPerf ou des services de test multi-régions, mais aussi en observant tes propres logs et métriques pour voir si la résolution est une source de latence significative.

Serveurs DNS publics vs DNS de ton hébergeur#

Pour ton hébergement web, tu vas principalement choisir entre : utiliser les serveurs DNS fournis par ton hébergeur (qui hébergent ta zone) ou déléguer ton domaine vers un service de DNS managé externe (Cloudflare, DNS premium, etc.). Les résolveurs publics (1.1.1.1, 8.8.8.8…) jouent un autre rôle, côté clients.

DNS de l’hébergeur, DNS managés et DNS publics#

Il est important de distinguer l’usage « navigation » (résolveurs) de l’usage « hébergement » (serveurs autoritaires).

Utiliser les DNS de ton hébergeur#

C’est la solution par défaut : tu laisses ton registrar ou ton hébergeur gérer ta zone DNS sur leurs serveurs autoritaires (ex : ns1.ovh.net, ns2.o2switch.net). C’est simple, intégré et suffisant pour beaucoup de sites de petite ou moyenne taille, tant que l’hébergeur a une infra DNS correcte.

Déléguer ta zone à un DNS managé externe (Cloudflare & co)#

Ici, tu changes les NS de ton domaine pour pointer vers un provider spécialisé (Cloudflare, Route 53, etc.). Tu profites alors de leurs serveurs anycast répartis dans le monde, de leurs fonctions de cache DNS, de filtrage, de sécurité, et parfois d’un CDN intégré. C’est ce que nous faisons régulièrement pour des clients à fort potentiel ou exposés (ecommerce > 1 M€/an de CA) pour mieux encaisser les pics de trafic et les attaques DDoS.

Utiliser des résolveurs DNS publics sur tes machines ou ton réseau#

À côté de ça, tu peux configurer des résolveurs DNS publics sur ton poste, ton routeur ou ton serveur (1.1.1.1, 8.8.8.8, 9.9.9.9, etc.). Cela impacte la vitesse de navigation et de résolution côté client, mais pas la vitesse à laquelle le monde entier résout ton domaine (qui dépend de tes serveurs autoritaires).

Comment configurer un serveur DNS rapide pour ton hébergement#

Si ton but est d’accélérer la résolution DNS de ton site pour tes utilisateurs, tu vas surtout jouer sur deux leviers : où est hébergée ta zone DNS (serveurs autoritaires) et comment tu configures tes enregistrements (caching, TTL, cohérence MX/WWW, etc.).

Le plus gros gain vient généralement du passage à un DNS anycast performant (Cloudflare, DNS managé) et d’une configuration propre, plutôt que de tweaks micro-optimisés sur un DNS lent ou surchargé. Sur nos projets, nous commençons toujours par analyser les logs, les sources de trafic et d’éventuelles attaques avant de basculer la zone pour ne pas propager une configuration déjà problématique.

Exemple de configuration DNS avec Cloudflare#

Voici un exemple simplifié de configuration de zone DNS pour un domaine hébergé chez un provider classique, mais dont la zone est gérée chez Cloudflare pour profiter de leur réseau anycast. Le cas typique : site sur serveur dédié / VPS, DNS managé chez Cloudflare, mails hébergés ailleurs.

; Enregistrements de base
@    300 IN A     203.0.113.10
www  300 IN CNAME exemple.com.

; Mail (hébergeur externe)
@    3600 IN MX   10 mail.provider.com.
mail 3600 IN A    198.51.100.20

; TXT (SPF)
@    3600 IN TXT  "v=spf1 a mx include:sendgrid.net ~all"

; CDN / sous-domaines techniques
static 600 IN CNAME cdn.provider.com.

Lors de ce type de migration, il est crucial de bien reproduire les enregistrements MX existants. Nous avons déjà vu des cas où des MX pointaient vers l’ancien serveur web, coupant la réception d’emails après migration du site. Repointer le MX vers le fournisseur de mail correct fait partie des points de contrôle indispensables avant et après bascule.

Choisir un DNS rapide : quelques profils types#

En pratique, le « meilleur » DNS dépend de ton contexte : taille du site, audience, niveau de maîtrise, contraintes de sécurité, etc.

Cas 1 : petit site ou TPE locale#

Pour un petit site vitrine ou un blog local, les DNS de ton hébergeur ou de ton registrar, correctement configurés, suffisent souvent, à condition qu’ils soient un minimum sérieux (infrastructure redondée, anycast si possible).

  1. Conserver les NS par défaut de ton hébergeur ou registrar.
  2. Nettoyer la zone des enregistrements inutiles ou obsolètes.
  3. Définir des TTL raisonnables (ni 30 secondes, ni 7 jours partout).
  4. Vérifier régulièrement l’absence d’erreurs DNS (via des outils de diagnostic).
  5. Tester la propagation après chaque changement, avec des outils comme dnschecker.org.

Cas 2 : e-commerce ou site à trafic croissant#

Pour un e-commerce ou un site en croissance, déléguer la zone à un DNS managé performant (Cloudflare, Route 53, etc.) est souvent un bon investissement, ne serait-ce que pour la résilience, la gestion fine des TTL et les options de sécurité.

  • Passer les NS chez un provider DNS anycast reconnu.
  • Profiter des fonctions de monitoring, firewall DNS et règles de sécurité (par exemple pour atténuer des attaques).
  • Configurer des TTL adaptés : plus courts sur les A/AAAA critiques si tu changes souvent d’infra.

Sur ce type de sites, nous combinons souvent migration vers Cloudflare + règles de sécurité basées sur les IP et user-agents, après analyse de logs, pour filtrer le trafic malveillant avant qu’il n’atteigne le serveur.

Cas 3 : architecture multi-sites ou multi-régions#

Si tu gères plusieurs sites ou une architecture multi-régions, un DNS avancé te permet d’orienter le trafic selon la géolocalisation, le poids, ou la disponibilité des noeuds, ce qu’un simple DNS d’hébergeur ne propose généralement pas.

  1. Étudier les options de routing géographique ou pondéré.
  2. Diviser la zone en sous-domaines par région/domaine fonctionnel.
  3. Monitorer les temps de résolution par région via des outils spécialisés.
  4. Prévoir un plan de reprise en cas de panne d’un datacenter en jouant sur le DNS.

Cas 4 : focus sécurité et filtrage#

Certains DNS (Quad9, OpenDNS, NextDNS) ajoutent une couche de filtrage (malware, phishing, etc.). Utile pour la navigation interne ou certains usages, mais à manier avec précaution pour des services publics où le blocage doit être maîtrisé.

  • Utiliser ces DNS côté clients internes, pas forcément pour la zone publique de ton site.
  • Tester l’impact sur l’accessibilité de certains services.

Ce sont des briques intéressantes dans une stratégie de sécurité globale, mais pas un remède miracle à tous les problèmes.

Cas 5 : environnement technique hybride (on-prem + cloud)#

Dans les environnements hybrides, le DNS peut aussi servir de glue entre des ressources internes et publiques. Là, un DNS managé avec une bonne gestion des vues internes/externes peut vite devenir indispensable.

  1. Segmenter les zones internes et externes.
  2. Documenter clairement qui gère quoi (infra, dev, ops).
  3. Standardiser les TTL, les conventions de nommage et la gestion des sous-domaines.

Cas 6 : tuning fin et monitoring#

Enfin, pour les plus techniques, le choix du DNS s’accompagne d’un monitoring régulier (latence, erreurs, propagation) et de tests de performance réguliers pour vérifier que la configuration tient la route dans le temps.

Bonnes pratiques DNS pour la vitesse et la fiabilité#

Une fois ton serveur DNS choisi et configuré, quelques bonnes pratiques simples t’aideront à garder une résolution rapide et stable sur la durée, tout en évitant les pièges classiques (en particulier sur la partie mails).

  • Éviter les chaînes de CNAME inutiles qui rallongent le nombre d’étapes.
  • Adapter les TTL : plus courts pour ce qui bouge souvent, plus longs pour le reste.
  • Surveiller régulièrement les erreurs DNS et les temps de réponse.
  • Tester systématiquement la propagation après modification (dnschecker.org, dig, nslookup, etc.).

Faut-il changer de DNS pour accélérer ton site ?#

Changer de DNS peut apporter un gain mesurable de temps de résolution, surtout si tu passes d’un DNS lent et peu distribué à un DNS anycast performant. Mais ce n’est qu’une brique de la performance globale de ton site.

FAQ : serveur DNS rapide et hébergement web#

Un serveur DNS plus rapide va-t-il vraiment rendre mon site plus rapide ?#

Oui, mais uniquement sur la partie résolution du domaine. Un DNS rapide réduit le temps nécessaire pour récupérer l’IP de ton serveur, ce qui améliore le TTFB, surtout lors de la première visite ou quand les caches ont expiré. En revanche, il n’accélère pas ton code, ta base de données, ton CDN ou ton front. Vois-le comme un maillon optimisé de la chaîne, pas comme une solution miracle de performance.

Quelle différence entre DNS de l’hébergeur et DNS publics (Cloudflare, Google, etc.) ?#

Les DNS de ton hébergeur servent généralement de serveurs autoritaires pour ta zone : ils stockent tes enregistrements A, MX, etc. Les DNS publics comme 1.1.1.1 ou 8.8.8.8 sont des résolveurs utilisés par les clients pour interroger ces serveurs autoritaires. Tu peux déléguer ta zone à un DNS managé comme Cloudflare pour bénéficier de leurs serveurs autoritaires anycast, tout en laissant chaque utilisateur utiliser le résolveur DNS de son choix.

Est-ce que je risque une coupure de mon site en changeant de DNS ?#

Tu peux en éviter la grande majorité si la migration est préparée : exporter la zone existante, recopier tous les enregistrements (A, AAAA, MX, TXT…), réduire les TTL en amont, planifier la bascule en période creuse, tester la propagation pendant et après. Les coupures arrivent surtout quand on oublie un enregistrement critique (comme un MX ou un sous-domaine technique) ou qu’on mélange des NS incohérents entre registrar et nouveau provider.

Combien de temps prend la propagation des DNS après un changement ?#

Techniquement, la propagation dépend des TTL que tu as définis et des caches des résolveurs. En pratique, compte quelques minutes à quelques heures pour que la majorité des utilisateurs voient la nouvelle configuration, et jusqu’à 24–48 heures pour une propagation complète dans le monde. En réduisant les TTL avant un changement important et en testant avec des outils comme dnschecker.org, tu peux fortement limiter cette fenêtre d’incertitude.

Faut-il réinstaller un certificat SSL quand on change de DNS ou de serveur ?#

Tu n’as pas besoin de réinstaller un certificat SSL juste parce que tu as modifié les DNS. En revanche, si tu changes de serveur ou d’infrastructure (nouvelle IP, nouveau reverse proxy, Cloudflare en proxy orange, etc.), il faut t’assurer que le certificat est bien installé et valide sur la nouvelle stack. Dans le cas d’un passage derrière Cloudflare en mode proxy, tu auras un certificat côté Cloudflare pour les visiteurs, et idéalement un certificat valide aussi côté origine pour sécuriser la liaison complète.