Quale percentuale di nameserver onora il TTL in questi giorni?

29

Alcuni anni fa ho dovuto apportare diverse modifiche al DNS nel corso di diverse settimane mentre spostavo parti di apparecchiature da un centro dati all'altro. Al momento in cui l'ho fatto, circa il 95% dei nameserver nel mondo sembrava rispettare il valore TTL e circa il 5% ha ignorato il nostro e si è inventato il proprio. In altre parole, il 95% del traffico si è spostato all'interno del TTL di 15 minuti che abbiamo definito. Un altro 3% ce l'ha fatta nella prima ora, l'1% nel primo giorno e alcuni sbandati hanno impiegato fino a tre giorni.

(Sì, OK, sto confondendo la percentuale di traffico con la percentuale di nameserver. Inserisci il handwaving.)

Questo avvenne verso il 2001, tuttavia, e stavamo usando i dinosauri per trasmettere i pacchetti attraverso i tubi. La mia ipotesi è che i nameserver di oggi abbiano un comportamento migliore e che ci saranno meno problemi con i ritardatari. Qualcuno ha un'idea di quale percentuale di traffico cambierà all'interno del TTL definito in questi giorni? Ci sono ancora molti nameserver là fuori che ignorano il TTL?

domain-name-system nameserver ttl

— user10501
fonte

4

Non ne ho idea, ma la mia sensazione è che oggi sarà anche peggio che in passato.

— Zoredache,

Mi sarebbe piaciuto averle fatte tutte in 3 giorni! Ho fatto un grande cambiamento in quel periodo (potrebbe essere stato il 2002) e dopo due settimane ci siamo finalmente resi conto che 1/3 dei server dei nomi di root stavano osservando un paio di server DNS di sviluppo che uno degli altri amministratori di sistema aveva esposto al mondo esterno. (Non ho ancora idea di come i server root li conoscessero).

— Joe H.

Qualcosa da considerare in questo è: non sono solo i ricursori DNS edge che memorizzano nella cache i record. A volte le persone ricorrono a catena e questo aggiunge tempo. Inoltre, alcuni record di cache dei sistemi operativi. Alcuni browser memorizzano anche nella cache i record. Anche Java e altre app memorizzano nella cache DNS. Questo può facilmente trasformare un TTL di 15 minuti in oltre 60 minuti.

— Aaron,

15

Ci siamo trasferiti di recente e abbiamo avuto tutti i tipi di problemi con DNS.

Quando abbiamo fatto oscillare la maggior parte dei clienti ha iniziato a colpire subito i nuovi IP. Ma alcuni stavano ancora colpendo i vecchi IP da settimane. Abbiamo lasciato un server attivo per circa un mese. Alla fine abbiamo esaminato i registri IIS sul vecchio computer e abbiamo chiamato i clienti dicendo loro di svuotare il DNS sui server DNS dell'azienda o ISP. Quello ha fatto spostare l'ultimo di loro.

Era un piccolo numero di persone che si manteneva con i vecchi IP. Su 20.000 clienti, forse 50 hanno avuto problemi dopo il primo giorno.

— mrdenny
fonte

1

Grazie! Questo è quello che mi aspettavo. Un quarto del percento non è poi così male per alcuni tipi di traffico, sebbene sia certamente molto negativo per altri.

— user10501

1

Una stima più recente: 13 ore dopo la modifica dei server DNS, un totale di 17/500 (3,4%) dei clienti ci ha contattato perché erano ancora serviti il vecchio sito anziché quello nuovo. WhatsMyDNS è utile per verificare lo stato della propagazione (nel nostro caso, 4/140 = 2,85% dei server nel loro campione utilizzano ancora il vecchio / sbagliato IP - Avrei voluto usarlo prima per comunicare meglio con i clienti e traccia la propagazione del DNS.)

— Fabien Snauwaert,

Se dovessi eseguire nuovamente una modifica DNS, imposterei in anticipo un nome di dominio di backup, per servire il nuovo sito mentre quello vecchio si sta ancora propagando.

— Fabien Snauwaert,

8

I valori (molto) lunghi di TTL delle settimane sono onorati a maggio 2011 dalla maggior parte dei nameserver che risolvono DNS fino a 2 settimane.

In un test usando just-dnslookup.com, con 50 punti di misurazione attivi distribuiti globali, con un record A TTL impostato su 99.999.999 = 165 settimane (preciso: 165 settimane 2 giorni 9 ore 46 minuti 39 secondi) e un TTL predefinito di 2 settimane (= SOA + NS TTL).

La prima ricerca restituisce:

un TTL di 1 settimana, per 3 punti di misurazione su 50
un TTL di 165 settimane, per 47 punti di misurazione su 50

Ritorno delle ricerche consecutive (convertito nel valore TTL originale):

un TTL di 1 settimana, per 3 punti di misurazione su 50
un TTL di 2 settimane, per 46 punti di misurazione su 50
un TTL di 165 settimane, per 1 su 50 punti di misurazione

Un secondo test (utilizzando un dominio diverso) in cui TTL predefinito è impostato su 4 settimane (= SOA + NS TTL) i risultati sono inferiori.

La prima ricerca restituisce:

un TTL di 1 settimana, per 3 punti di misurazione su 50
un TTL di 2 settimane, per 1 su 50 punti di misurazione
un TTL di 165 settimane, per 46 punti di misurazione su 50

Ritorno delle ricerche consecutive (convertito in lunghezza TTL completa):

un TTL di 1 settimana, per 3 punti di misurazione su 50
un TTL di 2 settimane, per 47 punti di misurazione su 50
un TTL di 165 settimane, per 0 su 50 punti di misurazione

Dai servizi di risoluzione pubblica più conosciuti / meglio connessi:

Il DNS pubblico di Google [8.8.8.8 e 8.8.4.4] si riduce a 1 giorno.
UltraDNS [rdns (1 | 2) .ultradns.net] onora piene 165 settimane.
Sprintlink [ns (1 | 2 | 3) .sprintlink.net] onora piene 165 settimane.

— Pro Backup
fonte

11

Personalmente, sarei molto più preoccupato se le brevi impostazioni TTL sono rispettate. Hai fatto ricerche simili su questo? Ad esempio, se TTL è impostato su 3600 secondi, i record memorizzati nella cache scadranno davvero dopo un'ora? Questo è molto rilevante per una situazione di ritaglio. Il pensiero che un TTL di 165 settimane sarebbe onorato è in realtà piuttosto spaventoso, in particolare quando penso a situazioni in cui sono stato chiamato a ripulire dopo gli errori di qualcun altro.

— Skyhawk,

Penso che 8.8.8.8 ignori completamente ttl e usi solo 24h. Certamente non onora almeno alcuni livelli inferiori. Ora devo trovare qualcosa da fare per 24 ore.

— Steven Parkes,

3

Di recente ho spostato il DNS per alcuni domini che ospitano il mio sito personale e i siti di progetto da GoDaddy a DNS interno (sì, letteralmente a casa mia ). Nel complesso, ogni sito a cui ho accesso remoto ha rispettato il TTL e ha reso bene la transizione. Lo stesso è stato segnalato da tutti gli amici che potrei chiedere di controllare, sia tramite rete fissa che mobile. L'unico problema, ironia della sorte, erano i principali server DNS di cache nella $ University in cui lavoro, che sembrava ignorare totalmente il TTL per le query memorizzate nella cache (e persino ignorare il valore TTL che stavano assegnando al risultato memorizzato nella cache).

Sembra che, nel complesso, il TTL dovrebbe essere ben rispettato. Il 56% dei server autorevoli per i domini .com e .net utilizza BIND, che ovviamente gioca bene con gli standard. Cablevision / Optimum (almeno in NJ) sembra utilizzare Nominum CNS, che rispetta anche i TTL.

— Jason Antman
fonte

0

Questa non è una risposta specifica alla tua domanda; ma piuttosto, altre cose da considerare che giocano nei tuoi test:

Recursori DNS e daemon cache memorizzati

Non sono solo i ricursori DNS edge che memorizzano nella cache i record. A volte le persone ricorrono a catena e questo aggiunge tempo. Se questo debba essere fatto o no potrebbe essere una lunga discussione basata su ciò che la gente stava cercando di risolvere. Ho visto 3 livelli di ricorsione in un data center. La miscelazione dei ricursori può avere risultati contrastanti, poiché i decrementi TTL non vengono sempre conservati. Alcuni record di cache dei sistemi operativi. Alcuni sistemi utilizzano anche le cose come nscd, dnsmasqe altri metodi per ridurre al minimo l'impatto dei problemi recursor locali e per ridurre il carico sulle loro recursors. Le caratteristiche del sistema operativo variano in base alla versione di rilascio, ai daemon di cache, alla versione di daemon di cache, ecc ...

[Modifica] Per ribadire, questo non è un comportamento normale di un ricursore o di un demone di cache. Non mi vergognerò di quelli buggy, ma uno di questi è considerato non mantenuto, anche se è in bundle con molte distribuzioni di Linux.

Cache DNS dell'applicazione

Alcuni browser memorizzano anche nella cache i record. Anche Java e altre app memorizzano nella cache DNS. A volte puoi limitare il massimo ttl all'interno delle applicazioni.

I risultati finali possono essere distorti

Gli elementi di cui sopra possono facilmente trasformare un TTL di 15 minuti in oltre 60 minuti o anche di più.

Questo è il motivo per cui suggerisco spesso che applicazioni o siti Web debbano considerare la presenza di più nodi attivi nella progettazione della tolleranza agli errori, in modo che il client possa determinare più rapidamente quando un punto di accesso al sito non è riuscito e gestire automaticamente il problema in un maniero grazioso e prevedibile , quando possibile. Anycast è un metodo che alcune aziende utilizzano per rendere il failover un po 'trasparente e non fare così tanto affidamento sulle modifiche DNS. Esistono anche alcuni metodi intelligenti di bilanciamento del carico che possono essere eseguiti in JavaScript utilizzando più record DNS.

— Aaron
fonte

Il TTL non si reimposta solo perché il record viene inviato da un server DNS al successivo. Un TTL di 15 minuti significa 15 minuti, indipendentemente da quanti strati di cache sta attraversando. L'unico modo in cui potrebbe diventare di più è se parte del software è difettoso e non implementa correttamente il DNS.

— Kasperd,

Sono d'accordo. Ho incontrato un po 'di ricorsori buggy.

— Aaron,

-1

Vecchia domanda, ma nuove risposte (2017, 6 anni dopo):

Sembra che quasi tutti i server DNS in tutto il mondo si aggiornino in 5 minuti
Google e OpenDNS ti consentono di scaricare manualmente un record DNS, accelerando gli aggiornamenti di propagazione

Prima degli esperimenti di seguito avevo precedentemente modificato il mio TTL da 14400 (secondi = 4 ore) a 300 (secondi = 5 minuti) ma l'ho fatto 2 ore prima degli esperimenti e dato che il TTL precedente era di 4 ore non sono sicuro del mio cambiamento sarebbe uscito se i server DNS non avessero il proprio TTL minimo.

I miei esperimenti:

Esperimento 1:

Ho modificato una traduzione da nome a IP (un record) nel server autorevole, quindi ho verificato:

Dopo 5 minuti (300 secondi) circa la metà dei server globali controllati da quei siti era stata udpata.

Dopo 7 minuti, tutto era stato aggiornato tranne 1.

Esperimento 2:

Google e OpenDNS ti consentono di svuotare manualmente la loro cache DNS per un determinato dominio. link:

Svuota la voce della cache DNS di Google per il tuo dominio: https://developers.google.com/speed/public-dns/cache
Lavare OpenDNS DNS cache 's per il dominio: https://cachecheck.opendns.com/

Ho aggiornato un altro record A, quindi ho immediatamente svuotato la cache DNS di Google. Hanno un captcha che mi ha fatto "fare clic su tutti i quadrati con segni" 3 volte, quindi ci sono voluti 1-2 minuti prima che potessi completare il flush.

Dopo 4 minuti, solo 1 server DNS controllato da quei siti aveva il vecchio indirizzo IP. Tutti gli altri erano stati aggiornati.

Quindi svuotare la cache DNS di Google e costringerla a interrogare nuovamente il server autorevole sembra aver accelerato la propagazione DNS globale, forse innescando gli aggiornamenti della cache in tutti i server del mondo.

Tuttavia, anche senza Google flush, sembra che la propagazione avvenga in pochi minuti, non ore o giorni.

— john v kumpf
fonte