DNS TTL recommandé


24

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:


20

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.


Voilà toute une différence! Il serait utile que la réponse inclue le raisonnement derrière le passage à un TTL beaucoup plus faible.
Anthony G - justice pour Monica

3
@AnthonyGeoghegan Les serveurs modernes peuvent gérer des demandes beaucoup plus fréquentes, et maintenant que je suis sur des serveurs de noms très fiables (AWS Route 53), je préférerais avoir la flexibilité de pouvoir changer de DNS à tout moment.
ceejayoz

12

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.

http://www.ietf.org/rfc/rfc1912.txt


4
J'imagine que le trafic DNS provenant de TTL faibles était beaucoup plus problématique en 1987 et 1996 qu'en 2011/2012.
ceejayoz

6
Ces deux normes que vous citez se réfèrent uniquement au champ "Minimum" de l'enregistrement SOA, qui n'est plus utilisé pour déterminer la valeur TTL par défaut ou minimale, comme cela était prévu lors de la rédaction de ces normes. Les meilleures pratiques DNS écrites il y a 27 et 18 ans ont été écrites lorsque DNS - en fait Internet - était une bête différente. De nos jours, 300 secondes (5 minutes) est un TTL assez courant pour les principaux enregistrements A / AAAA, bien que cela ne soit utile qu'en cas de basculement rapide, sinon 6 heures + seraient plus appropriées. Les enregistrements NS et les enregistrements A / AAAA pour les adresses NS sont généralement d'un jour ou plus.
thomasrutter

6
Je suis en retard pour commenter cela, mais il convient de noter qu'il est inapproprié de se référer à l'un de ces RFC en tant que «normes». ( RFC 1796 ) Je note ceci afin que les lecteurs d'aujourd'hui ne s'éloignent pas de cette Q&R avec une mauvaise compréhension.
Andrew B

7

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


1
Oui. CloudFlare par défaut tous les TTL de leurs clients à 300 secondes (5 minutes), ce qui est fou, mais ils voient évidemment des avantages.
Simon East

3

Je laisserais simplement le paramètre par défaut défini par votre hôte, à moins qu'il ne soit ridiculement élevé ou bas pour une raison quelconque. Ensuite, si vous souhaitez déplacer, ramenez-le à 20 minutes environ deux jours avant de planifier le déménagement.


2

4 heures devraient suffire, offrant un équilibre acceptable. C'est ce que j'utilise sur la plupart des zones.


4
C'est probablement trop court.
dmourati

5
@dmourati: Nous sommes en 2011. Pour la très grande majorité des petits serveurs DNS (c'est-à-dire moins de 1 000 zones environ) et pour tous les clients, les exigences supplémentaires de charge CPU et de bande passante sont absolument négligeables. Bien sûr, si vos serveurs DNS tombent en panne pendant plus de 4 heures, vous êtes SOL, mais si c'est important et que vous ne pouvez pas fournir un service DNS fiable, vous n'avez pas à héberger votre service DNS sur une base aussi branlante en premier lieu. ..
Mihai Limbăşan

3
Lorsqu'un utilisateur pose une question à laquelle il est répondu directement dans un RFC, vous le dirigez vers le RFC quelle que soit l'année.
dmourati

@dmourati Est-ce prescrit dans un RFC?
Joó Ádám

Oui, voir ma réponse ci-dessus.
dmourati


2

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.