DNS recommandé TTL
Je sais que cela pourrait être très différent basé sur la situation, mais pour l'hébergement d'un site Web sans intention de déplacer le serveur d'hébergement, ce qui est un bon TTL à définir sur l'enregistrement DNS?
J'ai tendance à laisser tomber par défaut de Slicehost, 86 400 secondes (1 jour). Je le dépose jusqu'à 10 minutes lorsque j'ai une bouge en attente et attendez un jour ou deux.
Edit : Ces jours-ci (2016), j'ai tendance à le garder bas - environ 5 minutes.
Les normes (écrites A Long il y a longtemps en 1987) suggèrent 86 400 secondes (1 jour) en tant que TTL minimum par défaut.
Il est important que TTLS soit définie sur des valeurs appropriées. Le TTL=== est l'heure (en secondes) qu'un résolveur utilisera les données qu'il a obtenu à partir de votre serveur avant de poser à nouveau votre serveur. Si vous définissez la valeur trop basse, votre serveur sera chargé. bas avec beaucoup de demandes de répétition. Si vous le définissez trop haut, les informations que vous modifiez ne seront pas distribuées dans une durée raisonnable. Si vous laissez le TTL champ vide, il sera par défaut Ce qui est spécifié dans le SOA enregistrement pour la zone.
La plupart des informations sur l'hôte ne changent pas beaucoup sur de longues périodes. Un bon moyen de configurer votre TTLS serait de les définir à une valeur élevée, puis plus abaisser la valeur si vous savez qu'un changement sera bientôt. Vous pourriez définir la plupart des TTLS depuis n'importe où entre une journée (86400) et une semaine (604800). Ensuite, si vous savez que certaines données changeront dans un proche avenir, définissez le TTL pour que RR soit inférieur à une valeur inférieure (une heure à une journée) jusqu'à ce que le changement ait lieu, puis Remettez-le à sa valeur précédente.
De plus, tous les RRS avec le même nom, la même classe et le même type doivent avoir le même TTL valeur.
Voir RFC 1033: http://tools.ietf.org/html/rfc10
RFC 1912 (à partir de 1996) suggère que 3 jours peuvent être plus appropriés pour les enregistrements SOA.
Je l'ai remarqué devient de plus en plus à la mode d'avoir plus de réduction de TTLS pour pouvoir répondre aux urgences (en particulier dans les environnements DNS) plus rapidement.
Je ne le laisserais plus à la valeur par défaut de votre hôte, à moins que ce soit ridiculement élevé ou faible pour une raison quelconque. Ensuite, si vous voulez jamais vous déplacer jusqu'à 20 minutes environ quelques jours avant de planifier le déménagement.
En outre - RFC 1912 , les utilisateurs d'Europe devraient également voir Ripe-203, "Recommandations pour DNS SOA valeurs" , qui recommande deux jours comme Un minimum TTL valeur.
4 heures devraient être très bien, fournissant un équilibre acceptable. C'est ce que j'utilise sur la plupart des zones.
(Remarque: cet article s'applique au TTL sur les enregistrements indidival AAAA, certains autres types d'enregistrements peuvent avoir plus de TTLS, car ils ne représentent pas les points d'échec célibataire de la même manière).
Vous devez vraiment y penser en termes de vos plans de reprise des catastrophes. Il ne s'agit pas du moment où vous avez l'intention de déplacer le site (pour des mouvements intentionnels, vous pouvez réduire le TTL au cours du mouvement). Il s'agit du moment où votre hôte disparaît de la face d'Internet ou de coups de pied Vous êtes sur une violation de TOS ou vous frappe parce qu'ils ne peuvent pas gérer le DDO qui vous appartenait.
Si vous ne vous souciez pas de votre site étant en panne pendant une journée environ dans ces circonstances, allez-y et laissez le TTL sur sa valeur par défaut d'une journée. Si vous avez l'espace d'adresse PI et le transit BGP Dans plusieurs endroits à partir de plusieurs fournisseurs et l'intention de gérer la catastrophe de récupération au niveau du BGP, allez-y et laissez-le sur une journée par défaut d'une journée. D'autre part si vous utilisez DNS comme mechnisme de la divorgement de votre site de basculement sur un site de basculement. Vous voulez une TTL beaucoup plus courte, 5 minuits sont une valeur bien commune.