Je sais que cela pourrait être très différent en fonction de la situation, mais pour l'hébergement d'un site Web sans projet de déplacer le serveur d'hébergement, quel est un bon TTL à définir sur l'enregistrement DNS?
Je sais que cela pourrait être très différent en fonction de la situation, mais pour l'hébergement d'un site Web sans projet de déplacer le serveur d'hébergement, quel est un bon TTL à définir sur l'enregistrement DNS?
Réponses:
J'ai tendance à le laisser par défaut de Slicehost, 86 400 secondes (1 jour). Je le ramène à 10 minutes lorsque j'ai un déménagement en attente et j'attends un jour ou deux.
edit: Ces jours-ci (2016), j'ai tendance à le maintenir bas - ~ 5 minutes.
Les normes (rédigées il y a longtemps en 1987) suggèrent 86 400 secondes (1 jour) comme TTL par défaut minimum.
Il est important que les TTL soient définis sur des valeurs appropriées. Le TTL est le temps (en secondes) pendant lequel un résolveur utilisera les données qu'il a obtenues de votre serveur avant de le redemander. Si vous définissez une valeur trop faible, votre serveur sera chargé avec de nombreuses demandes répétées. Si vous le définissez trop haut, les informations que vous modifiez ne seront pas distribuées dans un délai raisonnable. Si vous laissez le champ TTL vide, il correspondra par défaut à ce qui est spécifié dans l'enregistrement SOA de la zone.
La plupart des informations sur l'hôte ne changent pas beaucoup sur de longues périodes. Un bon moyen de configurer vos TTL serait de les définir à une valeur élevée, puis de réduire la valeur si vous savez qu'un changement viendra bientôt. Vous pouvez définir la plupart des TTL entre un jour (86400) et une semaine (604800). Ensuite, si vous savez que certaines données vont changer dans un avenir proche, définissez le TTL pour ce RR sur une valeur inférieure (une heure sur un jour) jusqu'à ce que le changement ait lieu, puis remettez-le à sa valeur précédente.
En outre, tous les RR avec le même nom, la même classe et le même type doivent avoir la même valeur TTL.
Voir RFC 1033: http://tools.ietf.org/html/rfc1033
La RFC 1912 (de 1996) suggère que 3 jours peuvent être plus appropriés pour les SOAenregistrements.
J'ai remarqué qu'il devient de plus en plus à la mode d'avoir des TTL plus courts pour pouvoir répondre plus rapidement aux urgences (en particulier dans les environnements DNS HA).
4 heures devraient suffire, offrant un équilibre acceptable. C'est ce que j'utilise sur la plupart des zones.
Outre la RFC 1912 , les utilisateurs en Europe devraient également consulter RIPE-203, "Recommandations pour les valeurs DNS SOA" , qui recommande deux jours comme valeur TTL minimale.
(Remarque: ce post s'applique au TTL sur les enregistrements A / AAAA individuels, certains autres types d'enregistrement peuvent avoir des TTL plus longs car ils ne représentent pas les points de défaillance uniques de la même manière).
Vous devez vraiment y penser en termes de plans de reprise après sinistre. Il ne s'agit pas de savoir quand vous avez l'intention de déplacer le site (pour les déplacements intentionnels, vous pouvez réduire le TTL dans la période précédant le déplacement). Il s'agit du moment où votre hôte disparaît du visage d'Internet ou vous met à la porte pour une violation de TOS ou vous met à la porte parce qu'il ne peut pas gérer le DDOS qui vous est arrivé.
Si vous ne vous souciez pas que votre site soit en panne pendant un jour ou deux dans ces circonstances, allez-y et laissez le TTL sur sa valeur par défaut d'un jour. Si vous avez un espace d'adressage PI et un transit BGP à plusieurs emplacements de plusieurs fournisseurs et que vous avez l'intention de gérer la récupération après sinistre au niveau BGP, allez-y et laissez-le sur sa valeur par défaut d'un jour. D'un autre côté, si vous utilisez DNS comme moyen de diviser votre Taffic vers un site de basculement, vous voulez un TTL beaucoup plus court, 5 minuites est une valeur assez courante.