Domain & DNS

Benchmark temps de réponse DNS

Benchmark de la vitesse des résolveurs de plusieurs fournisseurs.

À propos de cet outil

Cet outil mesure à quelle vitesse 15 résolveurs publics répondent à une requête DNS pour le domaine que vous choisissez. Chaque résolveur est interrogé plusieurs fois de suite afin que vous puissiez voir la variance — un seul outlier est souvent un cache froid, un nombre élevé constant signifie que cette empreinte anycast est juste loin de notre hôte de Francfort.

La latence est prise de la statistique ;; Query time de dig, qui mesure le temps de fil entre nous et le résolveur après le démarrage du processus. Le surcoût fork+exec (~10–20 ms) est exclu, donc les chiffres reflètent le comportement réseau + résolveur plutôt que la planification de l'OS. La sparkline montre la séquence brute ; les colonnes Min/Avg/Max résument uniquement les exécutions réussies.

Quand utiliser cet outil

  • Choisir un résolveur pour votre routeur ou appareil. Exécutez contre un domaine que vous utilisez réellement — différents réseaux voient différents gagnants.
  • Diagnostiquer un site lent. Comparez la latence du résolveur aux symptômes de chargement du site — un DNS qui prend toujours 200 ms s'additionne sur des dizaines de sous-ressources.
  • Surveiller un fournisseur. Si votre résolveur principal saute soudainement de 20 ms à 300 ms sur plusieurs exécutions, il est temps de changer.
  • Comparer la couverture anycast. Cloudflare et Google gagnent généralement depuis les hôtes UE ; Alibaba et DNSPod gagnent par surprise depuis l'Asie.

Pourquoi les résultats diffèrent de votre réseau local

Nous mesurons depuis notre serveur en Allemagne vers le POP anycast le plus proche de chaque résolveur. Depuis votre réseau domestique, les distances et le peering sont différents. Traitez les chiffres absolus comme une comparaison relative, pas comme votre latence personnelle. Si vous avez besoin d'une mesure locale, exécutez dig +stats @<ip> example.com sur votre propre machine — le même drapeau produit le même nombre.

Questions fréquentes

Pourquoi un résolveur est-il beaucoup plus lent que les autres ?

Soit son POP le plus proche est loin de notre hôte, son anycast a une mauvaise journée, ou le récursif a dû traverser jusqu'à un serveur faisant autorité (cache froid). Notre requête par défaut est cloudflare.com — un nom très populaire que chaque résolveur met en cache ; si vous interrogez un domaine rare, la première exécution sera lente pour tout le monde.

Que signifie "Timeout" ?

Pas de réponse UDP en 2 secondes. Pourrait être un pépin temporaire, l'IP de notre hôte est bloquée par ce fournisseur, ou le résolveur est sous pression. Un timeout sur cinq exécutions est du bruit ; cinq sur cinq signifient que le résolveur est actuellement inaccessible depuis notre réseau de Francfort.

En quoi cela diffère-t-il de DNS Propagation ?

La propagation demande "les résolveurs voient-ils la nouvelle valeur ?" — une requête chacun, valeurs comparées côte à côte. Response Time demande "à quelle vitesse répondent-ils ?" — plusieurs requêtes chacune, latence comparée côte à côte. Question différente, mêmes 15 résolveurs.

Puis-je changer le nombre d'exécutions ?

Oui — choisissez 3, 5, 7 ou 10 dans le menu déroulant. Plus d'exécutions = médiane plus serrée, mais chaque exécution attend que la précédente se termine sur les 15 résolveurs, donc 10 exécutions prennent environ 5× plus de temps que 2 exécutions. Pour un usage occasionnel, 5 est un bon équilibre.

Les résultats sont-ils mis en cache ?

Pendant une minute par triplet (domaine, type, exécutions). Cliquer sur Mesurer deux fois de suite renvoie la même table de résultats — bon pour partager l'URL, mauvais pour interroger les changements. Ajustez le domaine ou les exécutions pour forcer une nouvelle exécution ; attendez 60s sinon.