Quel pourcentage de serveurs de noms honorent TTL ces jours-ci?

29

Il y a quelques années, j'ai dû effectuer plusieurs modifications DNS au cours de plusieurs semaines alors que je déplaçais des équipements d'un centre de données à l'autre. Au moment où je l'ai fait, environ 95% des serveurs de noms dans le monde semblaient respecter la valeur TTL, et environ 5% ignoraient la nôtre et inventaient la leur. En d'autres termes, 95% du trafic s'est déplacé dans le TTL de 15 minutes que nous avons défini. Un autre 3% a réussi la première heure, 1% le premier jour et quelques retardataires ont pris jusqu'à trois jours.

(Oui, OK, je confond le pourcentage de trafic avec le pourcentage de serveurs de noms. Veuillez insérer l'ondulation manuelle.)

C'était vers 2001, cependant, et nous utilisions des dinosaures pour transmettre des paquets à travers les tubes. Je suppose que les serveurs de noms d'aujourd'hui se comportent mieux et qu'il y aura moins de problèmes avec les retardataires. Quelqu'un a-t-il une idée du pourcentage de trafic qui va basculer dans le TTL défini ces jours-ci? Existe-t-il encore de nombreux serveurs de noms qui ignorent le TTL?

domain-name-system  nameserver  ttl 
— user10501
source
4
Je n'en ai aucune idée, mais mon instinct est qu'aujourd'hui, ce sera encore pire que par le passé.
— Zoredache
J'aurais adoré les faire tous en 3 jours! J'ai fait un changement majeur à cette époque (peut-être en 2002), et après deux semaines, nous avons finalement réalisé que 1/3 des serveurs de noms racine regardaient quelques serveurs DNS de développement que l'un des autres administrateurs système avait exposés au monde extérieur. (Je n'ai toujours aucune idée de la façon dont les serveurs racine les connaissaient).
— Joe H.
Quelque chose à considérer dans ceci est: ce ne sont pas seulement les récurseurs DNS de pointe qui mettent en cache les enregistrements. Parfois, les gens enchaînent les récurseurs et cela ajoute du temps. De plus, certains systèmes d'exploitation mettent en cache les enregistrements. Certains navigateurs mettent également en cache les enregistrements. Java et d'autres applications mettent également en cache DNS. Cela peut facilement transformer un TTL de 15 minutes en plus de 60 minutes.
— Aaron

Réponses:

15

Nous avons déménagé récemment et avons eu toutes sortes de problèmes avec DNS.

Lorsque nous avons effectué le basculement, la plupart des clients ont immédiatement commencé à utiliser les nouvelles adresses IP. Mais certains frappaient toujours les anciennes adresses IP pendant des semaines. Nous avons laissé un serveur en place pendant environ un mois. Finalement, nous avons parcouru les journaux IIS sur l'ancienne machine et appelé les clients en leur disant de vider le DNS sur leur serveur DNS d'entreprise ou de FAI. Cela fit bouger le dernier d'entre eux.

C'était un petit nombre de personnes qui conservaient les anciennes adresses IP. Sur 20 000 clients, peut-être 50 ont eu des problèmes après le premier jour.

— mrdenny
source
1
Merci! C'est à peu près ce à quoi je m'attendais. Un quart de pour cent n'est pas trop mauvais pour certains types de trafic, mais c'est certainement très mauvais pour d'autres.
— user10501
1
Une estimation plus récente: après 13 heures de changement de serveur DNS, un total de 17/500 (3,4%) des clients nous ont contactés car ils recevaient toujours l'ancien site au lieu du nouveau. WhatsMyDNS est pratique pour vérifier l'état de la propagation (dans notre cas, 4/140 = 2,85% des serveurs de leur échantillon utilisent toujours l'ancienne / mauvaise adresse IP - j'aurais aimé l'utiliser plus tôt pour mieux communiquer avec les clients et suivre la propagation du DNS.)
— Fabien Snauwaert
Si je devais effectuer à nouveau un changement DNS, je mettrais en place un nom de domaine de sauvegarde à l'avance, pour servir le nouveau site pendant que l'ancien se propage.
— Fabien Snauwaert
8

Les valeurs (très) longues TTL des semaines sont honorées en mai 2011 par la plupart des serveurs de noms de résolution DNS jusqu'à 2 semaines.

Dans un test utilisant just-dnslookup.com, ayant 50 points de mesure actifs répartis mondiaux, avec un TTL d'enregistrement A réglé à 99,999,999 = 165 semaines (précis: 165 semaines 2 jours 9 heures 46 minutes 39 secondes) et un TTL par défaut de 2 semaines (= SOA + NS TTL).

La première recherche renvoie:

  • un TTL de 1 semaine, pour 3 points de mesure sur 50
  • un TTL de 165 semaines, pour 47 points de mesure sur 50

Retour de recherches consécutives (converti en valeur TTL d'origine):

  • un TTL de 1 semaine, pour 3 points de mesure sur 50
  • un TTL de 2 semaines, pour 46 points de mesure sur 50
  • un TTL de 165 semaines, pour 1 point de mesure sur 50

Un deuxième test (utilisant un domaine différent) où TTL par défaut est défini sur 4 semaines (= SOA + NS TTL) est ci-dessous.

La première recherche renvoie:

  • un TTL de 1 semaine, pour 3 points de mesure sur 50
  • un TTL de 2 semaines, pour 1 point de mesure sur 50
  • un TTL de 165 semaines, pour 46 points de mesure sur 50

Retour de recherches consécutives (converti en pleine longueur TTL):

  • un TTL de 1 semaine, pour 3 points de mesure sur 50
  • un TTL de 2 semaines, pour 47 points de mesure sur 50
  • un TTL de 165 semaines, pour 0 point de mesure sur 50

Des services de résolveurs publics les plus connus / les mieux connectés:

  • DNS public Google [8.8.8.8 et 8.8.4.4] réduit à 1 jour.
  • UltraDNS [rdns (1 | 2) .ultradns.net] honore 165 semaines complètes.
  • Sprintlink [ns (1 | 2 | 3) .sprintlink.net] honore 165 semaines complètes.
— Pro Backup
source
11
Personnellement, je serais beaucoup plus préoccupé par le respect des courts paramètres TTL. Avez-vous fait des recherches similaires à ce sujet? Par exemple, si TTL est défini sur 3600 secondes, les enregistrements mis en cache expireront-ils vraiment après une heure? Ceci est très pertinent dans une situation de transition. La pensée qu'un TTL de 165 semaines serait honoré est en fait assez effrayante, en particulier lorsque je pense à des situations dans lesquelles j'ai été appelé à nettoyer après les erreurs de quelqu'un d'autre.
— Skyhawk
Je pense que 8.8.8.8 ignore complètement ttl et utilise juste 24h. Il n'honore certainement pas au moins certains ttls inférieurs. Maintenant, je dois trouver quelque chose à faire pendant 24h.
— Steven Parkes
3

J'ai récemment déplacé DNS pour quelques domaines qui hébergent mon site personnel et mes sites de projet de GoDaddy vers le DNS interne (ouais, littéralement ma maison ). Dans l'ensemble, chaque site auquel j'ai accès à distance a respecté le TTL et a bien fait la transition. La même chose a été rapportée par tous les amis à qui je pouvais demander de vérifier, à la fois par téléphone fixe et mobile. Ironiquement, le seul problème était les principaux serveurs DNS de mise en cache de $ University où je travaille, qui semblaient ignorer totalement TTL pour les requêtes mises en cache (et même ignorer la valeur TTL qu'ils attribuaient au résultat mis en cache).

Il semble que, dans l'ensemble, le TTL devrait être bien respecté. 56% des serveurs faisant autorité pour les domaines .com et .net exécutent BIND, ce qui est évidemment conforme aux normes. Cablevision / Optimum (au moins dans le NJ) semble utiliser Nominum CNS, qui respecte également les TTL.

— Jason Antman
source
0

Ce n'est pas une réponse à votre question spécifiquement; mais plutôt, des choses supplémentaires à considérer qui jouent dans vos tests:

Récurseurs DNS enchaînés et démons de mise en cache

Ce ne sont pas seulement les récurseurs DNS de pointe qui mettent en cache les enregistrements. Parfois, les gens enchaînent les récurseurs et cela ajoute du temps. Que cela soit fait ou non pourrait être une longue discussion basée sur ce que les gens essayaient de résoudre. J'ai vu 3 niveaux de récursivité dans un centre de données. Le mélange des récurseurs peut avoir des résultats mitigés, car les décréments TTL ne sont pas toujours préservés. Certains systèmes d'exploitation mettent en cache les enregistrements. Certains systèmes utilisent également des choses comme nscd, dnsmasqet d'autres méthodes pour minimiser l'impact des problèmes de récurseur local et pour réduire la charge sur leurs récurseurs. Les caractéristiques du système d'exploitation varient en fonction de la version de publication, des démons de mise en cache, de la version des démons de mise en cache, etc.

[Modifier] Pour réitérer, ce n'est pas un comportement normal d'un récurseur ou d'un démon de mise en cache. Je ne vais pas faire honte aux buggy, mais l'un d'eux est considéré comme non entretenu, même s'il est fourni avec de nombreuses distributions Linux.

Cache DNS d'application

Certains navigateurs mettent également en cache les enregistrements. Java et d'autres applications mettent également en cache DNS. Vous pouvez parfois plafonner le ttl max dans les applications.

Les résultats finaux peuvent être biaisés

Les éléments ci-dessus peuvent facilement transformer un TTL de 15 minutes en 60 minutes ou plus.

C'est pourquoi je suggère souvent que les applications ou les sites Web devraient envisager d'avoir plusieurs nœuds actifs dans leur conception de tolérance aux pannes, afin que le client puisse déterminer plus rapidement lorsqu'un point d'entrée dans votre site a échoué et gérer automatiquement le problème dans un manoir gracieux et prévisible. , lorsque cela est possible. Anycast est une méthode que certaines entreprises utilisent pour rendre le basculement quelque peu transparent et ne pas compter autant sur les modifications DNS. Il existe également des méthodes intelligentes d'équilibrage de charge qui peuvent être effectuées en javascript en utilisant plusieurs enregistrements DNS.

— Aaron
source
Le TTL ne se réinitialise pas simplement parce que l'enregistrement est envoyé d'un serveur DNS au suivant. Un TTL de 15 minutes signifie 15 minutes quel que soit le nombre de couches de caches qu'il traverse. La seule façon dont cela pourrait devenir plus est si certains logiciels sont bogués et n'implémentent pas correctement DNS.
— kasperd
Je suis d'accord. J'ai rencontré un peu de récurseurs buggy.
— Aaron
-1

Ancienne question, mais nouvelles réponses (2017, 6 ans plus tard):

  1. On dirait que presque tous les serveurs DNS du monde entier se mettent à jour en 5 minutes
  2. Google et OpenDNS vous permettent de vider manuellement un enregistrement DNS, accélérant les mises à jour de propagation

Avant les expériences ci-dessous, j'avais précédemment changé mon TTL de 14400 (secondes = 4 heures) à 300 (secondes = 5 minutes) mais je l'ai fait 2 heures avant les expériences et puisque le TTL précédent était de 4 heures, je ne suis pas sûr de mon changement serait sorti si les serveurs DNS n'avaient pas leur propre TTL minimum.

Mes expériences:

Expérience 1:

J'ai changé une traduction de nom en IP (un enregistrement) sur le serveur faisant autorité, puis j'ai vérifié:

Après 5 minutes (300 secondes), environ la moitié des serveurs mondiaux contrôlés par ces sites avaient été mis à jour.

Après 7 minutes, tout avait été mis à jour sauf 1.

Expérience 2:

Google et OpenDNS vous permettent de vider manuellement leur cache DNS pour un domaine particulier. Liens:

J'ai mis à jour un autre enregistrement A, puis j'ai immédiatement vidé le cache DNS de Google. Ils ont un captcha qui m'a fait "cliquer sur toutes les cases avec des signes" 3 fois, il a donc fallu 1 à 2 minutes avant de pouvoir terminer la chasse d'eau.

Après 4 minutes, seul 1 serveur DNS vérifié par ces sites avait l'ancienne adresse IP. Tous les autres ont été mis à jour.

Ainsi, l'effacement du cache DNS de Google et le forçage à réinterroger le serveur faisant autorité semble avoir accéléré la propagation DNS mondiale, peut-être en déclenchant des mises à jour du cache sur tous les serveurs du monde.

Cependant, même sans le flush Google, il semble que la propagation se fasse en minutes, pas en heures ou en jours.

— john v kumpf
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.