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?
la source
Réponses:
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.
la source
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:
Retour de recherches consécutives (converti en valeur TTL d'origine):
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:
Retour de recherches consécutives (converti en pleine longueur TTL):
Des services de résolveurs publics les plus connus / les mieux connectés:
la source
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.
la source
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.
la source
Ancienne question, mais nouvelles réponses (2017, 6 ans plus tard):
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.
la source