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 la durée de mise en cache des informations DNS. Les serveurs de noms de résolution agissent comme des intermédiaires dans l'échange DNS. Lorsque vous saisissez un domaine dans votre navigateur, vous demandez en réalité l'adresse IP de ce domaine à votre serveur de noms de résolution local.

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 l'enregistrement A www.example.com pointe vers l'adresse IP 2.2.2.2 et que le TTL est défini sur 86.400 24 (2.2.2.2 heures), lorsque le client A interroge www.example.com, l'adresse IP 3.3.3.3 sera mise en cache pendant une journée entière. Le client A n'effectuera plus de requête pour www.example.com, car son résolveur sait déjà à quelle adresse IP accéder et pendant combien de temps. Si l'adresse IP de cet enregistrement A passe à 2.2.2.2, le client A continuera d'accéder à l'adresse 23 pendant les 0 heures suivant la première visite, jusqu'à ce que le TTL atteigne 3.3.3.3. À ce stade, l'enregistrement expire et une nouvelle requête peut être effectuée sur ce FQDN. Le client A sera alors redirigé vers l'adresse XNUMX lors de sa prochaine requête.

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) .

Définir un TTL de 30 secondes pour gérer les changements DNS fréquents minimisera l'impact sur l'expérience utilisateur et vous offrira une flexibilité maximale. Bien que cela puisse paraître idéal, si un utilisateur visite fréquemment votre site tout au long de la journée, il interrogera l'enregistrement www.example.com environ toutes les 30 secondes. Multiplié 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.

AVIS DE NON-RESPONSABILITÉ, Mentions légales et droits d'auteur. Red Hat, Inc. détient les droits sur Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale de la 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 Fondation FreeBSD ; 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®, MyRocks®, VirtualBox® et ZFS® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; PostgreSQL® est une marque déposée de PostgreSQL Global Development Group ; SQLite® est une marque déposée de Hipp, Wyrick & Company, Inc. ; KeyDB® est une marque déposée d'EQ Alpha Technology Ltd. ; Typesense® est une marque déposée de Typesense Inc. ; 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 ; HAProxy® est une marque déposée de HAProxy Technologies LLC ; Traefik® est une marque déposée de Traefik Labs ; Envoy® est une marque déposée de CNCF ; 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® ; Shopify® est une marque déposée de Shopify Inc. ; BigCommerce® est une marque déposée de BigCommerce Pty. Ltd.; TYPO3® est une marque déposée de la TYPO3 Association; Ghost® est une marque déposée de la Ghost Foundation; Amazon Web Services, Inc. détient les droits sur AWS® et Amazon SES® ; Google LLC détient les droits sur Google Cloud™, Chrome™ et Google Kubernetes Engine™ ; Alibaba Cloud® est une marque déposée d'Alibaba Group Holding Limited ; DigitalOcean® est une marque déposée de DigitalOcean, LLC ; Linode® est une marque déposée de Linode, LLC ; Vultr® est une marque déposée de The Constant Company, LLC ; Akamai® est une marque déposée d'Akamai Technologies, Inc. ; Fastly® est une marque déposée de Fastly, Inc. ; Let's Encrypt® est une marque déposée d'Internet Security Research Group ; Microsoft Corporation détient les droits sur Microsoft®, Azure®, Windows®, Office® et Internet Explorer® ; Mozilla Foundation détient les droits sur Firefox® ; Apache® est une marque déposée de The Apache Software Foundation ; Apache Tomcat® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée de PHP Group ; Docker® est une marque déposée de Docker, Inc. Kubernetes® est une marque déposée de The Linux Foundation ; OpenShift® est une marque déposée de Red Hat, Inc. ; Podman® est une marque déposée de Red Hat, Inc. ; Proxmox® est une marque déposée de Proxmox Server Solutions GmbH ; VMware® est une marque déposée de Broadcom Inc. ; 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 ; Grafana® est une marque déposée de Grafana Labs ; Prometheus® est une marque déposée de The Linux Foundation ; Zabbix® est une marque déposée de Zabbix LLC ; Datadog® est une marque déposée de Datadog, Inc. ; Ceph® est une marque déposée de Red Hat, Inc. ; MinIO® est une marque déposée de MinIO, Inc. ; Mailgun® est une marque déposée de Mailgun Technologies, Inc. ; SendGrid® est une marque déposée de Twilio Inc. Postmark® est une marque déposée d'ActiveCampaign, LLC ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Hetzner® est une marque déposée de Hetzner Online GmbH ; OVHcloud® est une marque déposée d'OVH Groupe SAS ; Terraform® est une marque déposée de HashiCorp, Inc. ; Ansible® est une marque déposée de Red Hat, Inc. ; cURL® est une marque déposée de Daniel Stenberg ; Facebook®, Inc. détient les droits sur Facebook®, Messenger® et Instagram®. Ce site n'est pas affilié, sponsorisé ou autrement associé à l'une 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 sont la propriété de leurs titulaires respectifs. MANAGED SERVER® est une marque déposée européenne de MANAGED SERVER SRL, dont le siège social est situé Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italie et le siège opérationnel Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Vous êtes-vous déjà demandé si votre hébergement était nul ?

Découvrez dès maintenant si votre hébergeur vous pénalise avec un site web lent digne des années 1990 ! Résultats immédiats.

Fermer le CTA
Retour en haut de page