DNS TTL consigliato


24

So che potrebbe essere molto diverso in base alla situazione, ma per l'hosting di un sito Web senza piani per spostare il server di hosting qual è un buon TTL da impostare sul record DNS?

Risposte:


20

Tendo a lasciarlo al default di Slicehost, 86.400 secondi (1 giorno). Lo lascio cadere fino a 10 minuti quando ho una mossa in sospeso e aspetto un giorno o due.

modifica: In questi giorni (2016) tendo a mantenerlo basso - ~ 5 minuti.


Questa è una bella differenza! Sarebbe utile se la risposta includesse il ragionamento alla base del passaggio a un TTL molto più basso.
Anthony G - giustizia per Monica,

3
@AnthonyGeoghegan I server moderni sono in grado di gestire richieste molto più frequenti e ora che sono su server dei nomi altamente affidabili (AWS Route 53) preferirei avere la flessibilità di poter cambiare DNS in un attimo.
Ceejayoz,

12

Gli standard (scritti molto tempo fa nel 1987) suggeriscono 86.400 secondi (1 giorno) come TTL predefinito minimo.

È importante che i TTL siano impostati su valori appropriati. Il TTL è il tempo (in secondi) in cui un resolver utilizzerà i dati che ha ricevuto dal tuo server prima di chiedere nuovamente al tuo server. Se si imposta un valore troppo basso, il server verrà caricato con molte richieste di ripetizione. Se lo si imposta su un valore troppo alto, le informazioni modificate non verranno distribuite in un lasso di tempo ragionevole. Se si lascia vuoto il campo TTL, verrà impostato automaticamente ciò che è specificato nel record SOA per la zona.

La maggior parte delle informazioni sull'host non cambia molto per lunghi periodi. Un buon modo per impostare i tuoi TTL sarebbe quello di impostarli su un valore elevato, quindi abbassare il valore se sai che un cambiamento arriverà presto. È possibile impostare la maggior parte dei TTL in qualsiasi punto tra un giorno (86400) e una settimana (604800). Quindi, se sai che alcuni dati cambieranno nel prossimo futuro, imposta il TTL per quel RR su un valore più basso (da un'ora a un giorno) fino a quando non avviene la modifica, quindi ripristinalo al valore precedente.

Inoltre, tutti gli RR con lo stesso nome, classe e tipo dovrebbero avere lo stesso valore TTL.

Vedi RFC 1033: http://tools.ietf.org/html/rfc1033

RFC 1912 (dal 1996) suggerisce che 3 giorni potrebbero essere più appropriati per i SOArecord.

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


4
Immagino che il traffico DNS proveniente da TTL bassi fosse significativamente più un problema nel 1987 e nel 1996 rispetto al 2011/2012.
Ceejayoz,

6
Entrambi gli standard citati si riferiscono solo al campo "Minimo" del record SOA, che non viene più utilizzato per determinare il valore TTL predefinito o minimo, come previsto quando questi standard sono stati scritti. Le migliori pratiche DNS scritte 27 e 18 anni fa sono state scritte quando DNS - anzi Internet - era una bestia diversa. Al giorno d'oggi, 300 secondi (5 minuti) è un TTL abbastanza comune per i record A / AAAA principali, sebbene utile solo quando è necessario un failover rapido, altrimenti 6 ore + sarebbe più appropriato. I record NS e i record A / AAAA per gli indirizzi NS sono generalmente di 1 giorno o più.
thomasrutter,

6
Sono in ritardo per commentare questo, ma va notato che è inappropriato fare riferimento a uno di questi RFC come "standard". ( RFC 1796 ) Lo sto notando in modo che i lettori di oggi non si allontanino da queste domande e risposte con una comprensione errata.
Andrew B,

7

Ho notato che sta diventando più di moda avere TTL più brevi per essere in grado di rispondere più rapidamente alle emergenze (in particolare all'interno di ambienti DNS HA).


1
Sì. CloudFlare imposta automaticamente tutti i TTL dei propri clienti a 300 secondi (5 minuti), il che è pazzesco, ma ovviamente vedono benefici.
Simon East,

3

Lo lascerei solo sul valore predefinito impostato dal tuo host, a meno che non sia ridicolmente alto o basso per qualche motivo. Quindi, se mai vuoi spostarti, scontralo fino a 20 minuti circa un paio di giorni prima di pianificare di eseguire la mossa.


2

4 ore dovrebbero andare bene, fornendo un equilibrio accettabile. Questo è quello che uso sulla maggior parte delle zone.


4
Questo è probabilmente troppo breve.
dmourati,

5
@dmourati: È il 2011. Per la stragrande maggioranza dei server DNS di piccole dimensioni (vale a dire meno di 1000 o più zone) e per tutti i client, i requisiti aggiuntivi di carico della CPU e larghezza di banda sono assolutamente trascurabili. Ovviamente, se i tuoi server DNS si spengono per più di 4 ore, sei SOL, ma se questo è importante e non puoi fornire un servizio DNS affidabile, non hai attività di hosting del tuo servizio DNS su una base così instabile in primo luogo. ..
Mihai Limbăşan,

3
Quando un utente pone una domanda a cui si risponde direttamente in un RFC, li si indirizza a RFC indipendentemente dall'anno in cui si trova.
dmourati,

@dmourati È prescritto in un RFC?
Joó Ádám,

Sì, vedi la mia risposta sopra.
dmourati,


2

(nota: questo post si applica al TTL sui record A / AAAA individuali, alcuni altri tipi di record possono avere TTL più lunghi perché non rappresentano singoli punti di errore allo stesso modo).

Devi davvero pensarci in termini di piani di ripristino di emergenza. Non si tratta di quando si intende spostare il sito (per le mosse intenzionali è possibile ridurre il TTL nel runup alla mossa). Si tratta di quando il tuo host svanisce dalla faccia di Internet o ti butta fuori per una violazione del TOS o ti butta fuori perché non riescono a gestire il DDOS che ti è venuto incontro.

Se non ti interessa che il tuo sito rimanga inattivo per un giorno o giù di lì in tali circostanze, vai avanti e lascia il TTL attivo per impostazione predefinita. Se si dispone di spazio indirizzo PI e transito BGP in più posizioni da più provider e si intende gestire il ripristino di emergenza a livello di BGP, andare avanti e lasciarlo sul valore predefinito di un giorno. D'altra parte, se stai usando DNS come meccanismo per dividere il tuo taffic in un sito di failover, vuoi un TTL molto più breve, 5 minuiti è un valore abbastanza comune.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.