Una bassa latenza DNS è un fattore chiave per un funzionamento veloce su Internet. Per minimizzarla, è fondamentale scegliere con attenzione i server DNS e . Ma prima di tutto, bisogna eliminare le query superflue.
Per questo motivo, il DNS è stato inizialmente progettato come un protocollo altamente cacheabile. Gli amministratori delle zone impostano il tempo di vita (TTL) per singoli record, e i resolver utilizzano queste informazioni per memorizzare i record nella cache, evitando così traffico non necessario.
È efficace la memorizzazione nella cache? Alcuni anni fa, una mia piccola ricerca ha mostrato che non è perfetta. Diamo un'occhiata alla situazione attuale.
Per raccogliere informazioni, ho patchato per mantenere il valore TTL per la risposta. Esso è definito come il TTL minimo dei suoi record per ogni richiesta in arrivo. Questo fornisce una buona panoramica della distribuzione del TTL nel traffico reale, oltre a considerare la popolarità di singole richieste. La versione patchata del server ha funzionato per alcune ore.
Il set di dati risultante è composto da 1.583.579 record (name, qtype, TTL, timestamp). Ecco la distribuzione generale del TTL (l'asse X rappresenta il TTL in secondi):
A parte un leggero picco a 86.400 (principalmente per i record SOA), è piuttosto chiaro che i TTL si trovano in un intervallo basso. Esaminiamo più da vicino:
Bene, i TTL superiori a 1 ora sono statisticamente poco significativi. Concentrandoci 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:
Questo non è molto positivo.
La distribuzione cumulativa rende il problema ancora più evidente:
Nella metà delle risposte DNS, il TTL è di 1 minuto o meno, mentre per tre quarti è di 5 minuti o meno.
Ma aspetta, in realtà è ancora peggio. Questi sono i TTL dai server autoritativi. Tuttavia, i risolutori client (ad esempio, router, cache locali) ricevono i TTL dai risolutori superiori, e questo si riduce ogni secondo.
Dunque, il client può effettivamente utilizzare ogni record, in media, per metà del TTL originale, dopo di che invierà una nuova richiesta.
Forse questi TTL molto bassi riguardano solo richieste insolite e non siti web e API popolari? Vediamo:
L'asse X è il TTL, l'asse Y rappresenta la popolarità delle richieste.
Purtroppo, le richieste più popolari sono anche le meno cachate.
Avviciniamo:
Verdetto: la situazione è davvero grave. Era già malmessa prima, ma ora è anche peggio. La memorizzazione nella cache del DNS è diventata praticamente inutile. Con sempre meno persone che utilizzano il resolver DNS del proprio provider (per buoni motivi), l'aumento della latenza è diventato più evidente.
La memorizzazione nella cache del DNS è utile solo per i contenuti che nessuno visita.
Si noti inoltre che il software può i bassi TTL.
Perché?
Perché viene impostato un TTL così basso per le registrazioni DNS?
- I bilanciatori di carico obsoleti sono rimasti con le impostazioni di default.
- Ci sono miti secondo cui il bilanciamento del carico DNS dipende dal TTL (non è così: fin dai tempi di Netscape Navigator, i client scelgono un IP casuale dal set di RR e provano un altro in modo trasparente se non riescono a connettersi).
- Gli amministratori desiderano applicare le modifiche immediatamente, perché è più facile pianificare in questo modo.
- L'amministratore del server DNS o del bilanciamento del carico ha il compito di implementare in modo efficiente la configurazione richiesta dagli utenti, piuttosto che accelerare il funzionamento dei siti e servizi.
- Bassi TTL offrono tranquillità.
- Le persone inizialmente impostano bassi TTL per i test e poi dimenticano di modificarli.
Non ho incluso nella lista il 'failover' 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 è andato in crash, probabilmente è accettabile un ritardo superiore a un minuto.
Inoltre, un TTL di un minuto significa che se i server DNS autorevoli vengono bloccati per più di un minuto, nessun altro potrà accedere ai servizi dipendenti. E la ridondanza non aiuterà se la causa è un errore di configurazione o un attacco. D'altra parte, con TTL ragionevoli, molti clienti continueranno a utilizzare la configurazione precedente senza accorgersene.
Nei TTL bassi sono in gran parte colpevoli i servizi CDN e i bilanciatori di carico, specialmente quando combinano CNAME con TTL piccoli e record con altri piccoli (ma indipendenti) TTL:
$ 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 uno qualsiasi dei record A, è necessario inviare una nuova richiesta. Entrambi hanno un TTL di 30 secondi, ma non coincidono. Il reale TTL medio sarà di 15 secondi.
Ma aspetta! È ancora peggio. Alcuni resolver si comportano molto male in una situazione 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. Fondamentalmente, 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 record CNAME. Ai. Uno 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 è in fase.
E per i 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 il TTL rimarrà gran 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
Per il record safebrowsing.googleapis.com il valore TTL è di 60 secondi, proprio come per i domini di Facebook. E, ancora una volta, dal punto di vista del cliente, questi valori si dimezzano.
Che ne dici di impostare un TTL minimo?
Utilizzando il nome, il tipo di richiesta, il TTL e il timestamp inizialmente salvato, ho scritto uno script per simulare 1,5 milioni di richieste che passano attraverso un risolutore cache, per valutare il volume di richieste superflue inviate a causa di una registrazione di cache scaduta.
Il 47,4% delle richieste sono state effettuate dopo la scadenza della registrazione esistente. Questo è un dato ingiustificatamente alto.
Quale sarà l'impatto sulla memorizzazione nella cache se viene impostato 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 delle richieste provenienti da un client che ha già una registrazione cache, ma la cui validità è scaduta e quindi effettua una nuova richiesta.
La quota di richieste "superflue" diminuisce dal 47% al 36% semplicemente impostando un TTL minimo di 5 minuti. Impostando un TTL minimo di 15 minuti, il numero di queste richieste scende al 29%. Un TTL minimo di un'ora riduce ulteriormente il numero a 17%. Una differenza significativa!
Che ne dite di non apportare alcuna modifica lato server e invece impostare dei TTL minimi nei cache DNS dei client (router, risolutori locali)?
Il numero di richieste necessarie diminuisce dal 47% al 34% quando si imposta un TTL minimo di 5 minuti, al 25% con un minimo di 15 minuti e al 13% con un minimo di 1 ora. Il valore ottimale potrebbe essere di 40 minuti.
L'impatto di questa piccola modifica è enorme.
Quali sono le conseguenze?
Certo, il servizio può essere trasferito a un nuovo fornitore di cloud, a un nuovo server, a una nuova rete, richiedendo ai clienti di utilizzare i record DNS più recenti. Un TTL sufficientemente basso facilita una transizione fluida e impercettibile. Tuttavia, con il passaggio a una nuova infrastruttura, nessuno si aspetta che i clienti aggiornino i loro record DNS in 1 minuto, 5 minuti o 15 minuti. Impostare un tempo di vita minimo di 40 minuti invece di 5 minuti non impedirà agli utenti di accedere al servizio.
Tuttavia, ciò consentirà di ridurre significativamente la latenza e aumentare la riservatezza e l'affidabilità, evitando richieste inutili.
Certo, le RFC dicono che bisogna rispettare rigorosamente il TTL. Ma la realtà è che il sistema DNS è diventato troppo inefficiente.
Se stai lavorando con server DNS autoritativi, controlla i tuoi TTL. Hai davvero bisogno di valori così ridicolmente bassi?
Certo, ci sono buone ragioni per impostare TTL bassi per i record DNS. Ma non per il 75% del traffico DNS, che praticamente non cambia.
E se per qualche motivo hai realmente bisogno di utilizzare TTL bassi per il DNS, assicurati che la cache sul tuo sito non sia abilitata. Per le stesse ragioni.
Se hai una cache DNS locale in funzione, come , che consente di impostare TTL minimi, utilizza questa funzione. Va bene. Non succederà nulla di male. Imposta un TTL minimo tra 40 minuti (2400 secondi) e 1 ora. Un intervallo del tutto ragionevole.
Fonte: habr.com
