Una bassa latenza DNS è un fattore chiave per un rapido funzionamento su Internet. Per minimizzarla, è importante selezionare attentamente i server DNS e . Ma prima di tutto è necessario liberarsi delle richieste inutili.
Per questo motivo, il DNS è stato originariamente creato come protocollo altamente cacheabile. Gli amministratori delle zone impongono un tempo di vita (TTL) per singoli record e i resolver utilizzano queste informazioni quando memorizzano i record in memoria, per evitare traffico non necessario.
La memorizzazione nella cache è efficace? Un paio di anni fa, una mia piccola indagine ha mostrato che non è perfetta. Diamo un'occhiata alla situazione attuale.
Per raccogliere informazioni, ho patchato per mantenere il valore TTL per la risposta. Viene definito come il TTL minimo dei suoi record, per ogni richiesta in entrata. Questo fornisce una buona panoramica della distribuzione del TTL nel traffico reale, e tiene conto anche della popolarità di singole richieste. La versione patchata del server ha funzionato per alcune ore.
Il set di dati risultante è composto da 1.583.579 registrazioni (name, qtype, TTL, timestamp). Ecco la distribuzione complessiva dei TTL (l'asse X rappresenta il TTL in secondi):
A parte un leggero picco a 86.400 (principalmente per le registrazioni SOA), è piuttosto evidente che i TTL si trovano in un intervallo basso. Approfondiamo:
Bene, i TTL superiori a 1 ora sono statisticamente insignificanti. Concentrati quindi sull'intervallo 0–3600:
La maggior parte dei TTL è compresa tra 0 e 15 minuti:
La stragrande maggioranza è compresa tra 0 e 5 minuti:
Non è affatto bene.
La distribuzione cumulativa rende il problema ancora più evidente:
Nella metà delle risposte DNS, il TTL è di 1 minuto o meno, e tre quarti hanno un TTL di 5 minuti o meno.
Ma aspetta, in realtà tutto è ancora peggiore. Infatti, questi sono TTL dai server autorevoli. Tuttavia, i resolver client (come router, cache locali) ottengono il TTL dai resolver superiori, che diminuisce ogni secondo.
Pertanto, il client può sostanzialmente utilizzare ogni record, in media, per metà del TTL originale, dopodiché invierà una nuova richiesta.
Forse questi TTL molto bassi riguardano solo richieste insolite, e non siti web o API popolari? Diamo un'occhiata:
L'asse X è il TTL, l'asse Y è la popolarità delle richieste.
Sfortunatamente, le richieste più popolari sono anche quelle peggio salvate in cache.
Avviciniamoci:
Verdetto: è davvero tutto male. Era già brutto, e adesso è anche peggio. La memorizzazione nella cache DNS è diventata praticamente inutile. Poiché sempre meno persone utilizzano il risolutore DNS del proprio provider (per motivi validi), l'aumento della latenza diventa più evidente.
La memorizzazione nella cache DNS è utile solo per contenuti che nessuno visita.
Si prega di notare che il software può TTL bassi in modo diverso.
Perché è così?
Perché per le voci DNS viene impostato un TTL così basso?
- I bilanciatori di carico obsoleti hanno mantenuto le impostazioni predefinite.
- Ci sono miti che affermano che il bilanciamento del carico DNS dipenda dai TTL (non è vero: dai tempi di Netscape Navigator, i client scelgono un indirizzo IP casuale dal set RR e provano in modo trasparente un altro se non riescono a connettersi)
- Gli amministratori desiderano applicare le modifiche immediatamente, poiché è più semplice pianificare.
- L'amministratore del server DNS o del bilanciatore di carico considera come compito principale quello di implementare efficacemente la configurazione richiesta dagli utenti, e non quello di accelerare le prestazioni dei siti e dei servizi.
- Bassi TTL offrono tranquillità.
- Le persone impostano inizialmente bassi TTL per i test e poi dimenticano di modificarli.
Non ho incluso nella lista la 'gestione dei guasti', poiché è sempre meno rilevante. Se è necessario reindirizzare gli utenti a un'altra rete solo per visualizzare una pagina di errore, quando tutto il resto è completamente rotto, probabilmente è accettabile una latenza superiore a 1 minuto.
Inoltre, un TTL di un minuto significa che se i server DNS autorevoli sono bloccati per più di un minuto, nessuno sarà in grado di accedere ai servizi dipendenti. E la ridondanza non aiuterà 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 noteranno nulla.
Gran parte della responsabilità dei bassi TTL ricade sui servizi CDN e sui bilanciatori di carico, specialmente quando combinano CNAME con bassi TTL e registrazioni con altrettanto bassi TTL (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 scade un CNAME o una qualsiasi delle registrazioni A, è necessario inviare una nuova richiesta. Entrambi hanno un TTL di 30 secondi, ma non coincidono. Il TTL medio effettivo sarà di 15 secondi.
Ma aspetta! La situazione è ancora peggiore. Alcuni resolver si comportano molto male in una situazione del genere con due TTL bassi collegati:
$ 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 resolver 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 questa situazione 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 registrazioni CNAME. Ahia. Una ha un TTL decente, ma è completamente inutile. Negli altri CNAME il TTL iniziale è di 60 secondi, ma per i domini akamai.net il TTL massimo è di 20 secondi e nessuno di essi è sincronizzato.
E per quanto riguarda i domini che interpellano continuamente 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 il TTL si blocca per la maggior parte del tempo a 1 secondo utilizzando il resolver 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
La registrazione safebrowsing.googleapis.com ha un valore TTL di 60 secondi, proprio come i domini di Facebook. E, di nuovo, dal punto di vista del cliente, questi valori si riducono della metà.
E se impostassimo un TTL minimo?
Utilizzando il nome, il tipo di richiesta, il TTL e il timestamp salvato inizialmente, ho scritto uno script per simulare 1,5 milioni di richieste che passano attraverso un resolver in caching, per valutare il volume di richieste inutili inviate a causa di una registrazione cache scaduta.
Il 47,4% delle richieste è stato effettuato dopo la scadenza di una registrazione esistente. Questo è incredibilmente elevato.
Quale sarà l'impatto sul caching se impostiamo un TTL minimo?
L'asse X rappresenta i valori minimi di TTL. Le registrazioni con TTL iniziali superiori a questo valore non sono interessate.
L'asse Y rappresenta la percentuale di richieste da parte di un cliente che ha già una registrazione memorizzata nella cache, ma il cui termine è scaduto e sta effettuando una nuova richiesta.
La percentuale di richieste 'superflue' diminuisce dal 47% al 36% impostando semplicemente un TTL minimo di 5 minuti. Impostando un TTL minimo di 15 minuti, il numero di tali richieste scende al 29%. Un TTL minimo di 1 ora riduce ulteriormente il numero al 17%. Una differenza significativa!
Che ne dici di non cambiare nulla sul lato server, ma invece di impostare TTL minimi nelle cache DNS dei clienti (router, resolver locali)?
Il numero di richieste necessarie diminuisce dal 47% al 34% impostando un TTL minimo di 5 minuti, al 25% con un minimo di 15 minuti e al 13% con un minimo di 1 ora. Forse il valore ottimale è 40 minuti.
L'impatto di questa minima modifica è enorme.
Quali sono le conseguenze?
Certo, il servizio può essere trasferito a un nuovo fornitore di cloud, nuovo server, nuova rete, richiedendo ai clienti di utilizzare le ultime registrazioni DNS. E un TTL sufficientemente basso aiuta a rendere questa transizione fluida e senza intoppi. Ma con il passaggio a una nuova infrastruttura, nessuno si aspetta che i clienti passino a nuove registrazioni DNS in 1 minuto, 5 minuti o 15 minuti. Impostare un termine di vita minimo di 40 minuti invece di 5 minuti non impedirà agli utenti di accedere al servizio.
Tuttavia, questo consentirà di ridurre notevolmente la latenza e migliorare la privacy e l'affidabilità, evitando richieste non necessarie.
Certo, le RFC dicono che bisogna rispettare rigorosamente il TTL. Ma la realtà è che il sistema DNS è diventato troppo inefficiente.
Se lavori con server DNS autoritativi, ti preghiamo di controllare i tuoi TTL. Hai davvero bisogno di valori così ridicolmente bassi?
Certo, ci sono buone ragioni per impostare TTL bassi per le registrazioni DNS. Ma non per il 75% del traffico DNS che non cambia praticamente mai.
E se per qualche motivo hai davvero bisogno di utilizzare TTL bassi per DNS, assicurati anche che la memorizzazione nella cache non sia abilitata sul tuo sito. Per le stesse ragioni.
Se hai un cache DNS locale in esecuzione, come , che consente di impostare TTL minimi, utilizza questa funzione. Va bene. Non succederà nulla di brutto. Imposta un TTL minimo compreso tra 40 minuti (2400 secondi) e 1 ora. È un intervallo piuttosto ragionevole.
Fonte: habr.com
