7 octobre 2021

Qu'est-ce que le DNS Time To Live (TTL) ?

Comment choisir correctement la bonne valeur DNS TTL dans cette Ăšre moderne.

Un TTL (ou Time to Live) est un paramÚtre crucial dans chaque enregistrement DNS qui peut faire la différence dans certains cas entre la vie et la mort, mais il est rarement mentionné.

Si vous ĂȘtes Ă©galement coupable d'avoir utilisĂ© le TTL par dĂ©faut pour vos enregistrements, vous devez lire ceci.

Signification TTL

Le TTL indique aux serveurs de noms combien de temps les informations DNS doivent ĂȘtre mises en cache. Les serveurs de noms de rĂ©solution sont comme des intermĂ©diaires d'Ă©change DNS. Lorsque vous entrez un domaine dans votre navigateur, vous demandez en fait Ă  votre serveur de noms de rĂ©solution local l'adresse IP de ce domaine.

La durĂ©e de vie (TTL) est la durĂ©e pendant laquelle un enregistrement est mis en cache dans un rĂ©solveur lorsque l'enregistrement est interrogĂ©. Il est mesurĂ© en secondes et est dĂ©fini dans chaque enregistrement de la configuration DNS. En d'autres termes, TTL est une valeur qui indique au rĂ©solveur DNS combien de temps le cache doit persister avant d'en demander un nouveau. 

Exemple : si la durĂ©e de vie d'un enregistrement est dĂ©finie sur 86.400 24 secondes (24 heures), le serveur collectera des informations pour afficher les dĂ©tails mis Ă  jour pour cet enregistrement particulier dans les 24 heures et n'interrogera pas Ă  nouveau le serveur DNS avant l'expiration des XNUMX heures.

Pourquoi le TTL est-il important ?

Pour les enregistrements de base A et CNAME, vous ne rencontrerez probablement pas de scĂ©narios oĂč les temps TTL posent des problĂšmes. Cependant, une fois que vous commencez Ă  modifier les points de terminaison de maniĂšre dynamique, comme le basculement, la durĂ©e de vie devient trĂšs importante.

Par exemple, supposons que l'adresse IP principale du domaine que nous recherchons ne soit pas disponible. Ce domaine a également activé le basculement, qui dirigera les utilisateurs vers une adresse IP de secours lorsque le principal est en panne.

Cela pourrait ĂȘtre traitĂ© de deux maniĂšres. Si l'enregistrement a un TTL Ă©levĂ©, les utilisateurs seront toujours dirigĂ©s vers l'adresse IP principale jusqu'Ă  l'expiration du cache du rĂ©solveur. Si l'enregistrement a un faible TTL, il est plus probable qu'il pointe vers le bon point de terminaison en premier.

Mais prenons un exemple peut-ĂȘtre plus Ă©loquent et facile Ă  comprendre.

Imaginons que vous ayez enregistré le domaine pippo.it sur le FOURNISSEUR 1 et que vous disposiez d'un service d'hébergement Web et de messagerie distinct sur un serveur géré par le FOURNISSEUR 2.

Imaginons maintenant, comme cela s'est produit en mars 2021, que le datacenter du FOURNISSEUR 2 prenne tellement feu qu'il soit détruit.

Centre de données incendie OVH
Incendie du Datacenter d'OVH en France avec pour conséquence la perte irrémédiable de millions de sites internet.

Imaginons que vous soyez une personne astucieuse et que vous fassiez des sauvegardes automatiques sur un serveur externe que nous appellerons PROVIDER 3.

Les données de sauvegarde sont donc intactes et sécurisées.

Pour redĂ©marrer rapidement, vous irez trĂšs probablement sur PROVIDER 3 (celui oĂč se trouve la sauvegarde) et demanderez Ă  louer un serveur oĂč vous irez restaurer la sauvegarde des fichiers et de la base de donnĂ©es. Vous importerez la configuration du serveur web, les certificats SSL et vous n'aurez qu'Ă  pointer les enregistrements DNS du domaine avec le www et sans le www vers l'IP du nouveau serveur sur le FOURNISSEUR 3.

Un jeu d'enfant.

Vous vous connectez au panneau de configuration de gestion de domaine, accĂ©dez Ă  la zone DNS oĂč les informations sont stockĂ©es et trouvez un enregistrement par dĂ©faut dĂ©fini sur 640800.

640800 quoi ? Secondes !

C'est une semaine.

Vous entrez la valeur de la nouvelle IP du serveur sur le FOURNISSEUR 3 oĂč vous avez restaurĂ© la sauvegarde et avant que le monde ne soit informĂ© de la nouvelle IP, cela prendra jusqu'Ă  une semaine car les serveurs de noms ont eu pour directive de considĂ©rer le DNS rĂ©cupĂ©rĂ© informations bonnes pour une semaine.

Evidemment, si un nameserver d'un fournisseur (disons Google par exemple) est passé il y a 2 jours, le temps d'attente ne sera plus une semaine, mais 5 jours, mais en tout cas il est légitime et correct de dire ça avec un TTL de 640800, il est prévu qu'une propagation DNS en une semaine ainsi qu'un TTL à 86400 secondes devraient se propager dans les 24 heures et ainsi de suite.

Si la valeur avait été par exemple de 900 secondes, le site sur le nouveau serveur de PROVIDER 3 serait à nouveau visible dans un délai maximum de 15 minutes.

DNS TTL et meilleurs paramĂštres

L'une des questions les plus frĂ©quemment posĂ©es est : "Quels sont les meilleurs paramĂštres pour Time To Live ? " Car la rĂ©ponse n'est pas toujours simple pour tous les scĂ©narios. Nous avons compilĂ© quelques bonnes pratiques pour vous aider Ă  dĂ©terminer quel paramĂštre est le plus appropriĂ© pour votre domaine. 

Valeurs TTL élevées recommandées

Les valeurs TTL Ă©levĂ©es sont gĂ©nĂ©ralement utilisĂ©es pour les enregistrements qui changent rarement, tels que les enregistrements MX ou TXT. Des durĂ©es de vie plus longues rĂ©duisent les temps de rĂ©solution car chaque fois qu'un serveur de noms faisant autoritĂ© fournit une rĂ©ponse Ă  une requĂȘte, une recherche supplĂ©mentaire est obtenue. Un TTL Ă©levĂ© fournit des rĂ©ponses plus rapides pour plusieurs ressources statiques en stockant les informations localement avant de devoir les rĂ©cupĂ©rer Ă  nouveau.

Exemple TTL 

Si vous avez le A www.example.com que pointe vers l'adresse IP 2.2.2.2 et un TTL dĂ©fini sur 86.400 24 (XNUMX heures), lorsque le client A interroge www.example.com , IP 2.2.2.2 sera mis en cache dans son cache pendant une journĂ©e entiĂšre. Le client A ne fera pas d'autre requĂȘte pour www.example.com puisque son rĂ©solveur sait dĂ©jĂ  Ă  quelle adresse IP aller et pour combien de temps. Si l'adresse IP de cet enregistrement A est modifiĂ©e en 3.3.3.3, le client A continuera Ă  passer Ă  2.2.2.2 pendant 23 heures aprĂšs la visite initiale jusqu'Ă  ce que le TTL atteigne 0. À ce stade, l'enregistrement expire et une nouvelle requĂȘte peut ĂȘtre fait sur ce FQDN. Ensuite, le client A sera dirigĂ© vers 3.3.3.3. Ă  leur prochaine question.

Note : Si vous devez apporter des modifications lors de l'utilisation de valeurs TTL Ă©levĂ©es, vous devrez abaisser la TTL et attendre l'expiration du cache avant de pouvoir apporter des modifications. Cela Ă©liminera le besoin d'attendre l'expiration de l'enregistrement.

Valeurs TTL faibles recommandées

Les ressources qui nĂ©cessitent des mises Ă  jour frĂ©quentes nĂ©cessitent une faible valeur TTL. Un temps de cache plus court est Ă©galement essentiel pour les modifications du site Web et du rĂ©seau. Les services de gestion DNS, tels que le basculement et l'Ă©quilibrage de charge, nĂ©cessitent un faible TTL afin de diriger les utilisateurs finaux vers l'adresse IP mise Ă  jour. En cas de pics de trafic inattendus, les requĂȘtes ne peuvent pas ĂȘtre envoyĂ©es Ă  l'adresse IP mise Ă  jour tant que le cache n'a pas expirĂ©, laissant les services de gestion DNS inefficaces pendant les pĂ©riodes critiques. Un TTL plus court est le remĂšde Ă  ce type de situation.

Note : Des valeurs TTL faibles sont recommandĂ©es pour les enregistrements critiques. Une bonne plage pourrait se situer entre 30 secondes et 300 secondes (5 minutes) .

Si un TTL est dĂ©fini sur 30 secondes pour s'adapter aux changements DNS frĂ©quents, l'expĂ©rience de l'utilisateur final est peu impactĂ©e et vous offre une flexibilitĂ© maximale. Bien que cela puisse sembler idĂ©al, si un utilisateur visite frĂ©quemment votre site au cours d'une journĂ©e, il interroge l'enregistrement www.example.com Toutes les 30 secondes environ, et lorsque vous le multipliez par le nombre d'utilisateurs, le nombre de requĂȘtes augmente, ce qui peut entraĂźner des coĂ»ts plus Ă©levĂ©s. 

Logique TTL

La rĂšgle de base pour dĂ©finir des valeurs TTL pour les enregistrements non critiques qui peuvent nĂ©cessiter des modifications dans un proche avenir est d'envisager un TTL plus court. Cependant, vous ne voulez pas non plus payer pour le nombre plus Ă©levĂ© de requĂȘtes fournies par des TTL infĂ©rieurs, donc un TTL de seulement 30 secondes, voire une demi-heure, n'est pas la meilleure rĂ©solution. Dans ce cas, vous voudrez utiliser un TTL plus long de 1 Ă  12 heures .

Vous pouvez ajuster votre durĂ©e de vie en fonction des besoins d'accessibilitĂ© de vos utilisateurs finaux.  

Cas d'utilisation TTL les plus courants

Les cas d'utilisation suivants incluent des réponses de notre équipe d'assistance pour vous aider avec les meilleures valeurs TTL pour votre domaine.

ScĂ©nario : J'utilise le basculement et j'ai besoin d'aussi peu de temps d'arrĂȘt que possible. Quel TTL dois-je dĂ©finir ?

RĂ©ponse : Si la disponibilitĂ© de votre FQDN est absolument essentielle, le basculement est un must mais nĂ©cessite un faible TTL pour fonctionner comme vous le souhaitez. Le basculement ne peut en aucun cas contourner les TTL. Si vous avez un TTL de 1800 (secondes) pour votre enregistrement de basculement et qu'il Ă©choue sur la deuxiĂšme adresse IP, les utilisateurs ne seront pas acheminĂ©s vers l'adresse IP mise Ă  jour pendant 30 minutes maximum (jusqu'Ă  l'expiration du cache dans le rĂ©solveur). Dans cet esprit, vous voudrez dĂ©finir un TTL faible et le plus bas sera le mieux. Cela dit, de nombreux rĂ©solveurs ne reconnaĂźtront pas les TTL de moins de 30 secondes, mais vous pouvez toujours effectuer un test pour savoir si votre rĂ©solveur autorise les TTL de moins de 30 secondes. 

ScĂ©nario : Cet enregistrement n'a pas besoin de basculement, mais nous apportons quelques modifications.

RĂ©ponse : Si l'enregistrement en question n'est pas critique mais est mis Ă  jour de temps en temps, un TTL plus Ă©levĂ© est la voie Ă  suivre. La question de suivi la plus courante est « et quand dois-je apporter un changement ? Â» et la rĂ©ponse est de programmer la mise Ă  jour. Disons que vous avez le TTL rĂ©glĂ© sur 7200 (2 heures), une fois que vous savez que vous voulez mettre Ă  niveau, rĂ©duisez le TTL pendant combien de temps vous ĂȘtes Ă  l'aise avec les temps d'arrĂȘt (30 secondes est le minimum que nous recommandons), puis attendez le TTL-in dans ce cas, vous attendriez deux heures. AprĂšs deux heures, vous pouvez modifier l'enregistrement et restaurer la valeur TTL initiale.

Comprendre le temps de vivre pour l'affinement de la stratégie DNS

La beauté de Time To Live est de pouvoir personnaliser complÚtement les valeurs pour répondre au mieux aux besoins de votre domaine. Comprendre TTL et comment l'utiliser efficacement vous assurera de maximiser votre stratégie DNS.

Une rĂšgle pour bien vivre avec DNS

Une rĂšgle simple pour vivre sereinement avec DNS Time To Live est celle qui se lit « pas trop, pas trop peu. La droite". C'est-Ă -dire comprendre qu'une valeur trop Ă©levĂ©e du TTL peut ĂȘtre absolument CATASTROPHIQUE dans certaines conditions dans lesquelles vous devez rapidement basculer l'IP par exemple vers un nouveau serveur, un nouveau fournisseur, une nouvelle structure (peut-ĂȘtre parce que vous devenez victimes de attaques DDoS par exemple), et en mĂȘme temps comprendre qu'il peut ĂȘtre paranoĂŻaque de dĂ©finir un TTL Ă  10 secondes Ă  moins que nous ne puissions rĂ©ellement tolĂ©rer ne serait-ce qu'une minute de temps d'arrĂȘt.

Ammesso che non siate realtĂ  come Top Fortune 500, in cui un minuto di Down puĂČ significare milioni di euro di danni, un valore ragionevole e pacifico per la quasi totalitĂ  della popolazione e delle realtĂ  Ăš di impostarlo tra un range che vai dai 5 ai 15 minutes.

Avec cette "rĂšgle", vous ne ferez peut-ĂȘtre pas le meilleur choix mais vous ne ferez CERTAINEMENT pas le pire.

Informations sur l'auteur

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions systÚme GNU/Linux avancées orientées vers la haute performance. Avec un modÚle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accÚs à des technologies avancées en matiÚre d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils systÚme sur les systÚmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. dĂ©tient les droits de Red HatÂź, RHELÂź, RedHat LinuxÂź et CentOSÂź ; AlmaLinuxℱ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky LinuxÂź est une marque dĂ©posĂ©e de la Rocky Linux Foundation ; SUSEÂź est une marque dĂ©posĂ©e de SUSE LLC ; Canonical Ltd. dĂ©tient les droits sur UbuntuÂź ; Software in the Public Interest, Inc. dĂ©tient les droits sur DebianÂź ; Linus Torvalds dĂ©tient les droits sur LinuxÂź ; FreeBSDÂź est une marque dĂ©posĂ©e de la FreeBSD Foundation ; NetBSDÂź est une marque dĂ©posĂ©e de la Fondation NetBSD ; OpenBSDÂź est une marque dĂ©posĂ©e de Theo de Raadt. Oracle Corporation dĂ©tient les droits sur OracleÂź, MySQLÂź et MyRocksÂź ; PerconaÂź est une marque dĂ©posĂ©e de Percona LLC ; MariaDBÂź est une marque dĂ©posĂ©e de MariaDB Corporation Ab ; REDISÂź est une marque dĂ©posĂ©e de Redis Labs Ltd. F5 Networks, Inc. dĂ©tient les droits sur NGINXÂź et NGINX PlusÂź ; VarnishÂź est une marque dĂ©posĂ©e de Varnish Software AB. Adobe Inc. dĂ©tient les droits sur MagentoÂź ; PrestaShopÂź est une marque dĂ©posĂ©e de PrestaShop SA ; OpenCartÂź est une marque dĂ©posĂ©e d'OpenCart Limited. Automattic Inc. dĂ©tient les droits sur WordPressÂź, WooCommerceÂź et JetPackÂź ; Open Source Matters, Inc. dĂ©tient les droits sur JoomlaÂź ; Dries Buytaert dĂ©tient les droits sur DrupalÂź. Amazon Web Services, Inc. dĂ©tient les droits sur AWSÂź ; Google LLC dĂ©tient les droits sur Google Cloudℱ et Chromeℱ ; Facebook, Inc. dĂ©tient les droits sur FacebookÂź ; Microsoft Corporation dĂ©tient les droits sur MicrosoftÂź, AzureÂź et Internet ExplorerÂź ; La Fondation Mozilla dĂ©tient les droits sur FirefoxÂź. ApacheÂź est une marque dĂ©posĂ©e de The Apache Software Foundation ; PHPÂź est une marque dĂ©posĂ©e du groupe PHP. CloudFlareÂź est une marque dĂ©posĂ©e de Cloudflare, Inc. ; NETSCOUTÂź est une marque dĂ©posĂ©e de NETSCOUT Systems Inc. ; ElasticSearchÂź, LogStashÂź et KibanaÂź sont des marques dĂ©posĂ©es d'Elastic NV. Ce site n'est affiliĂ©, sponsorisĂ© ou autrement associĂ© Ă  aucune des entitĂ©s mentionnĂ©es ci-dessus et ne reprĂ©sente aucune de ces entitĂ©s de quelque maniĂšre que ce soit. Tous les droits sur les marques et noms de produits mentionnĂ©s sont la propriĂ©tĂ© de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnĂ©es appartiennent Ă  leurs titulaires. MANAGED SERVERÂź est une marque dĂ©posĂ©e au niveau europĂ©en par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page