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.

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