Dans un monde idéal, le DNS serait comme l’un de ces fours à rôtir vus à la télévision-réglez-le et oubliez-le. Cependant, Internet est un lieu en évolution dynamique et ce qui peut être pertinent à un moment donné peut ne pas être le suivant.
pour faire face à cela, le DNS a été conçu avec un mécanisme pour actualiser les enregistrements et s’assurer que les utilisateurs recevaient toujours la réponse la plus pertinente lorsqu’ils la demandaient.
les bases
Le temps de vie, ou TTL pour faire court, est le genre de date d’expiration qui est mis sur un enregistrement DNS., Le TTL sert à indiquer au serveur récursif ou au résolveur local combien de temps il doit conserver ledit enregistrement dans son cache. Plus la durée de vie est longue, plus le résolveur conserve ces informations dans son cache. Plus la durée de vie est courte, plus le résolveur conserve ces informations dans son cache.
par exemple, nous avons example.com. Example.com a un enregistrement A au sommet de la zone pour nous diriger vers un serveur. Avec un TTL de 3600 secondes, ou 1 heure, cela signifie qu’un serveur récursif apprend example.com, il stockera ces informations sur L’enregistrement A à example.com pendant une heure., Toute autre personne qui utilise ce même résolveur obtiendra la même réponse, et du côté faisant autorité, il n’y aura aucune requête au serveur à moins que le TTL ne s’épuise.
les meilleures pratiques
Les TTL ne sont pas à prendre à la légère: elles peuvent affecter directement la quantité de volume de requêtes imputable à votre service faisant autorité et, en cas de nécessité de modifier rapidement l’enregistrement, entraîner une propagation des modifications plus longue que prévu pour tous les utilisateurs.,
pour les enregistrements qui exploitent une sorte de scénario avancé de gestion du trafic, tel que la chaîne de filtres de NS1, il est préférable de garder le TTL aussi court que possible. De cette façon, lorsqu’un changement est adopté par le système, les utilisateurs à l’autre extrémité demandant le nom reçoivent les informations les plus récentes. Il convient de noter que la plupart des serveurs récursifs ne comprennent pas réellement un TTL inférieur à 30 secondes – bien que nous ne vous empêchions pas d’aller plus bas que cela, les résultats peuvent ne pas être favorables à long terme.,
pour les enregistrements qui changent rarement, tels que les enregistrements TXT ou MX, il est préférable de les conserver entre une heure (3600s) et un jour (86400s). Quand vient le temps d’effectuer des modifications en ce qui concerne ces types d’enregistrements, il peut vous incomber de modifier le TTL à un intervalle plus court avant d’effectuer des modifications pour vous assurer que les modifications sont propagées rapidement.
le SOA TTLs
en haut de chaque zone DNS, au début de L’Autorité (SOA), il y a cinq valeurs TTL qui servent un but plus élevé dans le DNS.
SOA TTL – intervalle auquel L’enregistrement SOA lui-même est actualisé.,
Refresh TTL – intervalle auquel les serveurs secondaires (DNS secondaire) sont définis pour actualiser le fichier de zone primaire à partir du serveur principal.
réessayer TTL – la vitesse à laquelle un serveur secondaire va réessayer d’actualiser le fichier de zone primaire si l’actualisation initiale a échoué.
expiration TTL – si L’actualisation et la nouvelle tentative échouent à plusieurs reprises, c’est la période après laquelle le primaire doit être considéré comme disparu et ne fait plus autorité pour la zone donnée.,
NX TTL – dans le cas où la demande du domaine entraîne une requête inexistante (NXDOMAIN), c’est le temps qui est respecté par le récursor pour renvoyer la réponse NXDOMAIN.
Il est recommandé de ne pas modifier ces TTL sauf si vous avez un besoin très spécifique de le faire, ce qui est souvent un cas très rare.