Combien de temps faut-il pour que les enregistrements DNS se propagent?


68

Ceci est une question canonique sur la propagation DNS

Combien de temps faut-il pour que les différents types d’enregistrements se propagent?
Certains propagent-ils plus vite que d'autres?
Pourquoi faut-il du temps pour que les enregistrements DNS se propagent et comment ça fonctionne?


1
Remarque: Historiquement, il y avait une différence notable et significative dans le temps nécessaire pour mettre à jour différents types de documents (en fonction de la personne qui les avait conservés, etc.). Ce n'est plus le cas aujourd'hui.
Chris S

4
Lorsque ppl utilise le mot "propager" pour DNS, il indique clairement qu'il ne sait pas ce qu'est le DNS et comment il fonctionne. Espérons que la documentation "se propage" assez rapidement (croise les doigts).
poige

3
@tonygil S'il vous plaît voir le commentaire de Poige. Il n'y a rien de tel que la propagation DNS. De plus, les FAI ne contrôlent pas les serveurs racine. Si les serveurs DNS de ces FAI mettent en cache plus longtemps que la durée de vie de l'enregistrement, ils enfreignent le code RFC. Vous semblez avoir plusieurs malentendus avec le fonctionnement du DNS; mais les violations de RFC vont généralement casser la façon dont cela est supposé fonctionner. Cela n'a rien à voir avec les États-Unis ou l'Europe.
Chris S

1
@tonygil: La "cyberpolice" pour "les" mettre à jour concerne tous les administrateurs système, administrateurs de réseau, etc., exerçant une pression sociale sur les mauvais acteurs. Internet fonctionne parce que nous sommes tous d'accord pour le dire. Les meilleurs intérêts de nos utilisateurs, réseaux, etc., sont dans le "meilleur intérêt" manifeste d'Internet. re: "les utilisateurs ne sont pas technogurus" - Ceci est un site destiné aux administrateurs système professionnels et non aux utilisateurs finaux. Franchement, je m'attends à ce que les administrateurs système soient une sorte de "technoguru" (pour utiliser votre terminologie). Les sysadmins sont , par profession, censés se préoccuper de la façon dont cela se passe.
Evan Anderson

@EvanAnderson Je suis tout à fait d'accord pour dire que la pression crée un changement. d'autre part, la réalité est que les administrateurs système, paresseux ou incompétents, sont en hordes. et plus vous vous éloignez des États-Unis et de l'europe, plus ils deviennent fréquents. vos attentes sont satisfaisantes mais ne sont pas réalisables dans la plupart des régions du monde réel, où les administrateurs non préparés sont la règle. Ainsi, alors que vous vous attendez à ce que tout se passe bien, vous devez traiter avec le monde réel, là où ils ne le sont pas. de toute façon, fait mon point, vous avez fait le vôtre. acceptons d'être en désaccord.
tony gil

Réponses:


71

La "propagation DNS" n'est pas un phénomène réel en soi. C'est plutôt l'effet manifeste de la fonctionnalité de mise en cache spécifiée dans le protocole DNS. Dire que les modifications "se propagent" entre les serveurs DNS est un mensonge commode qui est sans doute plus facile à expliquer aux utilisateurs non techniques que de décrire tous les détails du protocole DNS. Ce n'est pas vraiment comment fonctionne le protocole, cependant.

Les serveurs DNS récursifs effectuent des requêtes pour le compte de clients. Les serveurs DNS récursifs, généralement gérés par les fournisseurs de services Internet ou les services informatiques, sont utilisés par les ordinateurs clients pour résoudre les noms de ressources Internet. Les serveurs DNS récursifs mettent en cache les résultats des requêtes qu'ils effectuent pour améliorer l'efficacité. Il est possible de répondre aux requêtes portant sur des informations déjà mises en cache sans effectuer de requêtes supplémentaires. La durée, en secondes, pendant laquelle un résultat est mis en cache est supposée être basée sur une valeur configurable appelée durée de vie (TTL). Cette valeur est spécifiée par le serveur DNS faisant autorité pour l'enregistrement demandé.

Il n'y a pas de réponse unique à toutes les questions posées car le DNS est un protocole distribué. Le comportement de DNS dépend de la configuration du serveur DNS faisant autorité pour un enregistrement donné, de la configuration des serveurs DNS récursifs effectuant des requêtes pour le compte d'ordinateurs clients et de la fonctionnalité de mise en cache DNS intégrée aux systèmes d'exploitation de ces ordinateurs.

Il est recommandé de spécifier une valeur TTL suffisamment courte pour prendre en compte les modifications quotidiennes nécessaires des enregistrements DNS, mais suffisamment longue pour créer un "gain" dans la mise en cache (c.-à-d. Pas trop court pour supprimer le cache trop rapidement pour fournir une amélioration de l'efficacité). L’utilisation d’une stratégie équilibrée avec les valeurs de la durée de vie résulte en une "victoire" pour tout le monde. Il réduit l'utilisation de la charge et de la bande passante pour les serveurs DNS faisant autorité pour un domaine donné, les serveurs racine et les serveurs TLD. Cela réduit l'utilisation de la bande passante en amont pour l'opérateur du serveur DNS récursif. Il en résulte des réponses aux requêtes plus rapides pour les ordinateurs clients.

Comme la durée de vie d'un enregistrement DNS est définie, la charge et l'utilisation de la bande passante sur les serveurs DNS faisant autorité augmentent car les serveurs DNS récursifs ne pourront pas mettre en cache le résultat pendant une longue durée. Comme la durée de vie d'un enregistrement est élevée, les modifications apportées aux enregistrements ne sembleront pas "prendre effet" rapidement car les ordinateurs clients continueront à recevoir les résultats mis en cache stockés sur leurs serveurs DNS récursifs. Définir la durée de vie optimale consiste à trouver un équilibre entre l'utilisation et la possibilité de modifier rapidement les enregistrements et de voir ces modifications reflétées sur les clients.

Il est à noter que certains fournisseurs de services Internet sont abusifs et ignorent les valeurs de durée de vie spécifiées par les serveurs DNS faisant autorité (en se substituant à leur propre remplacement administratif, ce qui constitue une violation du RFC). Il n'y a rien à faire à ce sujet, d'un point de vue technique. Si les exploitants de serveurs DNS abusifs peuvent être localisés, des plaintes auprès de leurs administrateurs système pourraient les amener à mettre en œuvre leurs meilleures pratiques (ce qui relève du sens commun pour tout ingénieur réseau familiarisé avec DNS). Ce type d'abus n'est pas un problème technique.

Si tout le monde "respecte les règles", les modifications apportées aux enregistrements DNS peuvent "prendre effet" très rapidement. Dans le cas de la modification de l'adresse IP affectée à un enregistrement "A", par exemple, une réduction exponentielle de la valeur TTL serait effectuée, ce qui conduirait au moment où la modification sera effectuée. Le TTL peut commencer à 1 jour, par exemple, et être réduit à 12 heures pour une période de 24 heures, puis 6 heures pour une période de 12 heures, 3 heures pour une période de 6 heures, etc., jusqu'à un intervalle suffisamment réduit. Une fois la durée de vie supprimée, l'enregistrement peut être modifié et ramené à la valeur souhaitée pour les opérations quotidiennes. (Il n'est pas nécessaire d'utiliser une réduction exponentielle, mais cette stratégie minimise le temps pendant lequel l'enregistrement a une durée de vie minimale et diminue la charge sur le serveur DNS faisant autorité.)

Après la création d'un enregistrement DNS, les journaux de modification doivent être surveillés afin de détecter les tentatives d'accès résultant de l'ancien enregistrement DNS. Dans l'exemple de modification d'un enregistrement "A" pour faire référence à une nouvelle adresse IP, un serveur doit rester présent à l'ancienne adresse IP pour gérer les tentatives d'accès résultant d'ordinateurs clients utilisant encore l'ancien enregistrement "A". Une fois que les tentatives d’accès basées sur l’ancien enregistrement ont atteint un niveau acceptable, l’ancienne adresse IP peut être supprimée. Si les requêtes liées à un ancien enregistrement ne s'épuisent pas rapidement, il est possible qu'un serveur DNS récursif (comme décrit ci-dessus) ignore la durée de vie (TTL) faisant autorité. Connaître l'adresse IP source d'une tentative d'accès ne fournit cependant pas d'informations directes sur le serveur DNS récursif responsable de la fourniture d'un ancien enregistrement.

Personnellement, j’ai vu les changements «prendre effet» immédiatement, en quelques heures, et dans certains cas avec un FAI endommagé au cerveau, après plusieurs jours. Faire abstraction de votre durée de vie et être conscient du fonctionnement du processus augmentera vos modifications pour réussir, mais vous ne pouvez jamais être sûr de ce qu'un idiot bien intentionné pourrait faire avec leurs serveurs DNS récursifs.


9
Ce n'est pas une réponse sur "OpenDNS" - c'est une réponse sur DNS. N'importe quel fournisseur de DNS récursif peut implémenter les interfaces qu'il souhaite autoriser à purger le cache, etc. Nous parlons de DNS - pas d'API de fournisseur. Pour ce qui est de vos modifications: je me fie à l'expression "cerveau endommagé" comme étant une expression utilisée de longue date dans la culture des hackers, et je l'utilise dans ce contexte (voir le fichier Jargon, les "pirates" de Steven Levy, etc.) . En ce qui concerne "l'idiot", je pense qu'il est raisonnablement établi que, en dehors des codes légaux, il s'agit d'un terme familier désignant des actions incompétentes. Je m'en tiens à cela aussi.
Evan Anderson

11
@tonygil - OpenDNS n'est pas DNS. C'est juste un service que quelqu'un offre. Que se passe-t-il si FooDNS ouvre demain et possède une nouvelle API de nettoyage de cache passionnante? Ma réponse devrait-elle inclure cela aussi? Où ça s'arrête? Cela dégénère en folie. re: droits civils - Je ne suis pas un employeur ni une entité gouvernementale qui refuse les droits civils à un membre d'une classe protégée. Bien sûr, allez-y et voyez si vous pouvez trouver quelqu'un qui veuille me poursuivre. Ils peuvent me joindre par courrier à la case postale 852, Troy, OH. (866) 569-9799, x801 transfère à mon téléphone cellulaire 24x7. (C'est un bon travail de détective qui regarde mon profil, BTW.)
Evan Anderson

1
Vous voyez, vous avez dit que la pression des pairs apporte un changement. c'est ce que j'ai fait. attiré votre attention sur le fait que je ne suis pas d'accord avec votre utilisation des mots "idiot" et "endommagé du cerveau" parce qu'ils sont offensants et péjoratifs. le fait que quelqu'un l'utilise à profusion (c.-à-d. les pirates informatiques) ne le corrige pas. le kkk a utilisé le n-mot à profusion. Veuillez respecter ceux d’entre nous qui s’occupent des handicapés mentaux. Je comprends que vous incorporiez les termes métaphoriquement dans votre style coloré, mais croyez-moi: ils sont offensants et inutiles.
Tony gil

A propos du respect de la durée de vie: la durée de vie est la valeur maximale pour conserver les éléments en cache, un résolveur de mise en cache est libre d’abandonner les données qui la précèdent. Ils peuvent donc le baisser s’ils le souhaitent. Cependant, il est vrai qu'ils ne devraient pas l'augmenter, c'est une violation du protocole. Mais pour les gens qui mettent environ 1 seconde dans le TTL, certaines caches se défendent en ne respectant pas cela et en serrant au minimum 5 minutes à la place.
Patrick Mevzek

Les serveurs DNS récursifs, généralement gérés par les fournisseurs de services Internet ou les services informatiques, constituent de nos jours une immense flotte (anycast cloud) de serveurs de noms récursifs ouverts tels que 1.1.1.1ou 8.8.8.8ou 9.9.9.9ou 80.80.80.80. Il est important de comprendre qu'ils sont anycasted: la réponse peut changer en fonction de l'adresse IP source car elle risque de toucher une instance physique complètement différente ET le cache dont ils disposent peut être global pour toutes les instances ou non.
Patrick Mevzek
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.