La latenza del Domain Name System (DNS) è un componente chiave per avere una buona esperienza online. E per ridurre al minimo la latenza DNS, scegliendo con cura i server DNS e i relè di anonimizzazione gioca un ruolo importante.
Ma il modo migliore per ridurre al minimo la latenza è evitare di inviare query inutili per iniziare. Ecco perché il DNS è stato progettato, fin dal primo giorno, per essere un protocollo pesantemente cacheable. I singoli record hanno un time-to-live (TTL), originariamente impostato dagli amministratori di zona, e i resolver utilizzano queste informazioni per mantenere questi record in memoria per evitare il traffico non necessario.
Il caching è efficiente? Un rapido studio che ho fatto un paio di anni fa ha dimostrato che c’era spazio per migliorare. Oggi, voglio dare un nuovo sguardo allo stato attuale delle cose.
Per fare ciò, ho patchato un server DNS crittografato per memorizzare il TTL originale di una risposta, definito come il TTL minimo dei suoi record, per ogni query in arrivo. Questo ci dà una buona panoramica della distribuzione TTL del traffico del mondo reale, ma rappresenta anche la popolarità delle singole query.
Quella versione patchata è stata lasciata funzionare per un paio d’ore. Il set di dati risultante è composto da 1.583.579 tuple (nome, qtype, TTL, timestamp). Ecco la distribuzione TTL complessiva (l’asse X è il TTL in secondi):
Oltre a un bump trascurabile a 86.400 (principalmente per i record SOA), è abbastanza ovvio che i TTL siano nella gamma bassa. Ingrandiamo:
Va bene, le TTL superiori a 1 ora sono statisticamente insignificanti. Concentriamoci sull’intervallo 0-3. 600:
E dove la maggior parte delle TTL si trova tra 0 e 15 minuti:
La stragrande maggioranza è compresa tra 0 e 5 minuti:
Questo non è grande. La distribuzione cumulativa può rendere il problema ancora più evidente:
Metà di Internet ha un TTL di 1 minuto o meno, e tre quarti hanno un TTL di 5 minuti o meno.
Ma aspetta, questo è in realtà peggio. Questi sono TTL come definiti dai server autorevoli. Tuttavia, i TTL recuperati dai resolver client (ad esempio, router, cache locali) ottengono un TTL che i resolver upstream diminuiscono ogni secondo. Quindi, in media, la durata effettiva che un client può utilizzare una voce memorizzata nella cache prima di richiedere una nuova query è la metà del TTL originale.
Forse questi TTL molto bassi influenzano solo query non comuni e non siti Web e API popolari. Diamo un’occhiata:
Sfortunatamente, le query più popolari sono anche le più inutili da memorizzare nella cache. Ingrandiamo:
Verdetto: è davvero brutto, o meglio era già brutto, ed è peggiorato. Il caching DNS è diventato quasi inutile. Con un minor numero di persone che utilizzano il resolver DNS del proprio ISP (per buone ragioni), l’aumento della latenza diventa più evidente. Il caching DNS è diventato utile solo per i contenuti che nessuno visita. Inoltre, si noti che il software può interpretare TTL bassi in modo diverso.
Perché?
Perché i record DNS sono impostati con TTL così bassi?
- I bilanciatori di carico legacy vengono lasciati con le impostazioni predefinite.
- La leggenda metropolitana che il bilanciamento del carico basato su DNS dipende da TTLs (non lo fa).
- Amministratori che vogliono le loro modifiche da applicare immediatamente, perché potrebbe richiedere meno lavoro di pianificazione.
- Come amministratore DNS o load-balancer, il vostro dovere è quello di distribuire in modo efficiente la configurazione persone chiedono, non per rendere i siti web e servizi veloci.
- TTL bassi danno la pace della mente.
Non sto includendo ‘for failover’ in quell’elenco, poiché questo è diventato sempre meno rilevante. Se l’intento è quello di reindirizzare gli utenti a una rete diversa solo per visualizzare una pagina fail whale quando assolutamente tutto il resto è in fiamme, avere più di un minuto di ritardo è probabilmente accettabile.
I CDN e i bilanciatori di carico sono in gran parte da incolpare, specialmente quando combinano record CNAME con TTL brevi con record che hanno anche TTL brevi (ma indipendenti):
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
Una nuova query deve essere inviata ogni volta che il CNAME o uno qualsiasi dei record A scadono. Entrambi hanno un TTL di 30 secondi ma non sono in fase. Il TTL medio effettivo sarà di 15 secondi.
Ma aspetta! Questo è peggio. Alcuni resolver si comportano piuttosto male in una situazione di basso-TTL-CNAME+basso-TTL-record:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Questo è il resolver di Level3, che, penso, sta eseguendo BIND. Se continui a inviare quella query, il TTL restituito sarà sempre 1. Essenzialmente, raw.githubusercontent.com non verrà mai memorizzato nella cache.
Ecco un altro esempio di una situazione low-TTL-CNAME+low-TTL-records, con un nome molto popolare:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Non meno di tre record CNAME. Ahi. Uno di loro ha un TTL decente, ma è totalmente inutile. Altri CNAMEs hanno un TTL originale di 60 secondi; il akamai.net i nomi hanno un TTL massimo di 20 secondi e nessuno di questi è in fase.
Che ne dici di uno che i tuoi dispositivi Apple sondano costantemente?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
La stessa configurazione di Firefox e il TTL è bloccato a 1 la maggior parte del tempo quando si utilizza il resolver di Level3.
Che dire di Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com ha un TTL di 60 secondi. I nomi di Facebook hanno un TTL di 60 secondi. E, ancora una volta, dal punto di vista del cliente, questi valori dovrebbero essere dimezzati.
Che ne dici di impostare un TTL minimo?
Usando il nome, il tipo di query, il TTL e il timestamp inizialmente memorizzati, ho scritto uno script che simula gli oltre 1,5 milioni di query che passano attraverso un resolver di caching per stimare quante query sono state inviate a causa di una voce di cache scaduta. il 47,4% delle query è stato effettuato dopo la scadenza di una voce esistente nella cache. Questo è irragionevolmente alto.
Quale sarebbe l’impatto sul caching se fosse impostato un TTL minimo?
L’asse X è il TTL minimo impostato. I record il cui TTL originale era superiore a questo valore non sono stati influenzati. L’asse Y è la percentuale di query effettuate da un client che aveva già una voce memorizzata nella cache, ma una nuova query è stata fatta e la voce memorizzata nella cache era scaduto.
Il numero di query scende dal 47% al 36% semplicemente impostando un TTL minimo di 5 minuti. Impostando un TTL minimo di 15 minuti, il numero di query richieste scende al 29%. Un TTL minimo di 1 ora lo fa scendere al 17%. Questa è una differenza significativa!
Che ne dici di non cambiare nulla lato server, ma avere cache DNS client (router, resolver locali e cache instead) impostare invece un TTL minimo?
Il numero di query richieste scende 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. 40 minuti forse un punto debole. L’impatto di quel cambiamento minimo è enorme.
Quali sono le implicazioni?
Naturalmente, un servizio può passare a un nuovo provider cloud, un nuovo server, una nuova rete, richiedendo ai client di utilizzare record DNS aggiornati. E avere TTL ragionevolmente bassi aiuta a rendere la transizione priva di attrito. Tuttavia, nessuno si sposta su una nuova infrastruttura si aspetta che i client utilizzino i nuovi record DNS entro 1 minuto, 5 minuti o 15 minuti.
L’impostazione di un TTL minimo di 40 minuti invece di 5 minuti non impedirà agli utenti di accedere al servizio. Tuttavia, ridurrà drasticamente la latenza e migliorerà la privacy (più query = più opportunità di tracciamento) e l’affidabilità evitando le query non necessarie.
Naturalmente, le RFC dicono che le TTL dovrebbero essere rigorosamente rispettate. Ma la realtà è che il DNS è diventato inefficiente.
Se si utilizzano server DNS autorevoli, rivedere i TTL. Hai davvero bisogno che questi siano ridicolmente bassi?
Leggi: Come scegliere i valori TTL DNS
Certo, ci sono validi motivi per usare TTL DNS bassi. Ma non per il 75% di Internet per servire contenuti che sono per lo più immutabili, ma inutili da memorizzare nella cache. E se, per qualsiasi motivo, hai davvero bisogno di usare TTL DNS bassi, assicurati anche che la cache non funzioni sul tuo sito web. Per le stesse ragioni.
Se si utilizza una cache DNS locale come dnscrypt-proxy che consente di impostare TTL minimi, utilizzare tale funzione. Va bene cosi’. Non succederà niente di male. Imposta quel TTL minimo a qualcosa tra 40 minuti (2400 secondi) e 1 ora; questo è un intervallo perfettamente ragionevole.
Adattato dal post originale apparso su 00f.net