Una bassa latenza DNS è fondamentale per una navigazione Internet veloce. Per minimizzarlo, è importante selezionare attentamente i server DNS e . Ma il primo passo è eliminare le query inutili.
Questo è il motivo per cui il DNS è stato originariamente progettato come un protocollo altamente memorizzabile nella cache. Gli amministratori di zona impostano una durata (TTL) per le singole voci e i risolutori utilizzano queste informazioni quando archiviano le voci in memoria per evitare traffico non necessario.
La memorizzazione nella cache è efficace? Un paio di anni fa, la mia piccola ricerca ha dimostrato che non era perfetto. Diamo uno sguardo allo stato attuale delle cose.
Per raccogliere informazioni ho patchato per salvare il valore TTL per la risposta. È definito come il TTL minimo dei suoi record per ogni richiesta in entrata. Ciò fornisce una buona panoramica della distribuzione TTL del traffico reale e tiene conto anche della popolarità delle singole richieste. La versione patchata del server ha funzionato per diverse ore.
Il set di dati risultante è costituito da 1 record (nome, qtype, TTL, timestamp). Ecco la distribuzione TTL complessiva (l'asse X è TTL in secondi):
A parte un piccolo aumento a 86 (principalmente per i record SOA), è abbastanza chiaro che i TTL sono nella gamma bassa. Diamo uno sguardo più da vicino:
Ok, i TTL superiori a 1 ora non sono statisticamente significativi. Quindi concentriamoci sull'intervallo 0-3600:
La maggior parte dei TTL vanno da 0 a 15 minuti:
La stragrande maggioranza va da 0 a 5 minuti:
Non è molto buono.
La distribuzione cumulativa rende il problema ancora più evidente:
La metà delle risposte DNS hanno un TTL pari o inferiore a 1 minuto e tre quarti hanno un TTL pari o inferiore a 5 minuti.
Ma aspetta, in realtà è peggio. Dopotutto, questo è TTL da server autorevoli. Tuttavia, i risolutori client (ad esempio router, cache locali) ricevono un TTL dai risolutori upstream e diminuisce ogni secondo.
Pertanto il client può effettivamente utilizzare ciascuna voce, in media, per metà del TTL originale prima di inviare una nuova richiesta.
Forse questi TTL molto bassi si applicano solo a richieste insolite e non a siti Web e API popolari? Diamo un'occhiata:
L'asse X è TTL, l'asse Y è la popolarità delle query.
Sfortunatamente, le query più popolari sono anche le peggiori da memorizzare nella cache.
Ingrandiamo:
Verdetto: è davvero brutto. Era già brutto prima, ma è peggiorato ancora. La memorizzazione nella cache DNS è diventata praticamente inutile. Poiché sempre meno persone utilizzano il risolutore DNS del proprio ISP (per buone ragioni), l'aumento della latenza diventa più evidente.
La memorizzazione nella cache DNS è diventata utile solo per i contenuti che nessuno visita.
Tieni inoltre presente che il software potrebbe interpretare i TTL bassi.
Perché è così?
Perché i record DNS sono impostati su un TTL così basso?
- I bilanciatori del carico legacy sono rimasti con le impostazioni predefinite.
- Ci sono miti secondo cui il bilanciamento del carico DNS dipenda da TTL (questo non è vero: dai tempi di Netscape Navigator, i client hanno scelto un indirizzo IP casuale da una serie di RR e ne hanno provato in modo trasparente un altro se non riescono a connettersi)
- Gli amministratori desiderano applicare immediatamente le modifiche, quindi è più semplice pianificare.
- L'amministratore di un server DNS o di un sistema di bilanciamento del carico vede il suo compito nell'implementazione efficiente della configurazione richiesta dagli utenti e non nell'accelerazione di siti e servizi.
- TTL bassi ti danno tranquillità.
- Inizialmente le persone impostano TTL bassi per i test e poi dimenticano di modificarli.
Non ho incluso il "failover" nell'elenco perché sta diventando sempre meno rilevante. Se è necessario reindirizzare gli utenti a un'altra rete solo per visualizzare una pagina di errore quando tutto il resto è danneggiato, probabilmente è accettabile un ritardo superiore a 1 minuto.
Inoltre, un TTL di un minuto significa che se i server DNS autorevoli vengono bloccati per più di 1 minuto, nessun altro potrà accedere ai servizi dipendenti. E la ridondanza non aiuta se la causa è un errore di configurazione o un hack. D'altra parte, con TTL ragionevoli, molti client continueranno a utilizzare la configurazione precedente e non si accorgeranno mai di nulla.
I servizi CDN e i bilanciatori del carico sono in gran parte responsabili dei TTL bassi, soprattutto quando combinano CNAME con TTL bassi e record con TTL altrettanto bassi (ma indipendenti):
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Ogni volta che il CNAME o uno qualsiasi dei record A scadono, è necessario inviare una nuova richiesta. Entrambi hanno un TTL di 30 secondi, ma non è la stessa cosa. Il TTL medio effettivo sarà di 15 secondi.
Ma aspetta! È anche peggio. Alcuni risolutori si comportano molto male in questa situazione con due TTL bassi associati:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Il risolutore Level3 probabilmente funziona su BIND. Se continui a inviare questa richiesta, verrà sempre restituito un TTL pari a 1. In sostanza, raw.githubusercontent.com non viene mai memorizzato nella cache.
Ecco un altro esempio di una situazione del genere con un dominio molto popolare:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Almeno tre record CNAME. Ay. Uno ha un TTL decente, ma è completamente inutile. Altri CNAME hanno un TTL iniziale di 60 secondi, ma per i domini akamai.net il TTL massimo è di 20 secondi e nessuno di essi è in fase.
Che dire dei domini che interrogano costantemente i dispositivi Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Lo stesso problema di Firefox e TTL rimarrà bloccato a 1 secondo per la maggior parte del tempo quando si utilizza il risolutore Level3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Alla registrazione safebrowsing.googleapis.com Il valore TTL è 60 secondi, come i domini Facebook. E, ancora, dal punto di vista del cliente questi valori sono dimezzati.
Che ne dici di impostare un TTL minimo?
Utilizzando il nome, il tipo di richiesta, il TTL e il timestamp originariamente memorizzato, ho scritto uno script per simulare 1,5 milioni di richieste che passano attraverso un risolutore di cache per stimare il volume di richieste non necessarie inviate a causa di una voce della cache scaduta.
Il 47,4% delle richieste è stato effettuato dopo la scadenza del record esistente. Questo è irragionevolmente alto.
Quale sarà l'impatto sulla memorizzazione nella cache se viene impostato il TTL minimo?
L'asse X rappresenta i valori TTL minimi. I record con TTL di origine superiori a questo valore non sono interessati.
L'asse Y è la percentuale di richieste provenienti da un client che dispone già di una voce memorizzata nella cache, ma è scaduta e sta effettuando una nuova richiesta.
La quota di richieste “extra” si riduce dal 47% al 36% semplicemente impostando il TTL minimo a 5 minuti. Impostando il TTL minimo a 15 minuti il numero di queste richieste scende al 29%. Un TTL minimo di 1 ora li riduce al 17%. Differenza significativa!
Che ne dici di non cambiare nulla sul lato server, ma invece di impostare il TTL minimo nelle cache DNS del client (router, risolutori locali)?
Il numero di richieste richieste scende dal 47% al 34% con un TTL minimo di 5 minuti, al 25% con un minimo di 15 minuti e al 13% con un minimo di 1 ora. Forse 40 minuti sono ottimali.
L’impatto di questo piccolo cambiamento è enorme.
Quali sono le implicazioni?
Naturalmente, il servizio può essere spostato su un nuovo provider cloud, un nuovo server, una nuova rete, richiedendo ai client di utilizzare i record DNS più recenti. E un TTL abbastanza piccolo aiuta a rendere tale transizione fluida e impercettibile. Ma con la transizione alla nuova infrastruttura, nessuno si aspetta che i client migrino ai nuovi record DNS entro 1 minuto, 5 minuti o 15 minuti. L'impostazione del TTL minimo su 40 minuti anziché su 5 minuti non impedirà agli utenti di accedere al servizio.
Tuttavia, ciò ridurrà significativamente la latenza e migliorerà la privacy e l’affidabilità evitando richieste non necessarie.
Naturalmente, le RFC affermano che il TTL deve essere rigorosamente seguito. Ma la realtà è che il sistema DNS è diventato troppo inefficiente.
Se lavori con server DNS autorevoli, controlla i tuoi TTL. Hai davvero bisogno di valori così ridicolmente bassi?
Naturalmente ci sono buone ragioni per impostare TTL piccoli per i record DNS. Ma non per quel 75% del traffico DNS che rimane praticamente invariato.
E se per qualche motivo hai davvero bisogno di utilizzare TTL bassi per il DNS, assicurati allo stesso tempo che il tuo sito non abbia la memorizzazione nella cache abilitata. Per gli stessi motivi.
Se hai una cache DNS locale in esecuzione, ad esempio che consente di impostare TTL minimi, utilizzare questa funzione. Questo va bene. Non succederà niente di male. Impostare il TTL minimo su circa 40 minuti (2400 secondi) e 1 ora. Un intervallo abbastanza ragionevole.
Fonte: habr.com