Hai ragione sul fatto che la cache DNS mitigherebbe la mancata disponibilità di un server dei nomi. È estremamente comune avere un TTL di 5 minuti o inferiore. Quindi, 5 minuti dopo che l'attacco DDOS ha bloccato Dyn, la tua cache non sarebbe stata valida e non saresti stato in grado di colpire GitHub, ecc.

Una piccola modifica al design delle cache DNS potrebbe fare una grande differenza. La maggior parte delle cache DNS rimuove una voce quando scade il TTL. Una cache potrebbe invece mantenere la voce, ma contrassegnarla come scaduta. Se arriva una query per una voce scaduta, la cache tenterà prima di risolvere il nome a monte e, se fallisce, restituirà la voce scaduta. Mi aspetto che questo sia tecnicamente una violazione del protocollo DNS, ma comunque un comportamento in caso di errore migliore.

Tuttavia, non mi aspetto che ciò accada. L'impatto del mancato funzionamento dei server DNS sarebbe comunque significativo: tutti i siti che non hai nella cache. L'attenzione rimarrà sul mantenimento dell'operatività dell'infrastruttura DNS.

Aggiornamento: @MatthieuM ha sottolineato che EdgeDNS fa questo.

@Shackledtodesk è corretto (+1), la cache del browser viene conservata per un breve periodo. Ironia della sorte, alcuni dei migliori riferimenti su questo fatto sono stati pubblicati da Dyn:

Un semplice programma che ho scritto per interrogare i primi 1000 siti Web (secondo Alexa) mostra 212 hit con un valore TTL di 300 (5 minuti), 192 risultati con un TTL di 3600 (1 ora), 116 risultati con un TTL di 600 (10 minuti) e 79 risultati con un TTL di 86400. Il resto dei risultati ha avuto risultati negli anni '50 e meno , che va da un TTL di 5 (1 hit) a un TTL di 864000 (1 hit).

Questa è una citazione di Ben Anderson, ricercatore e redattore tecnico di Dyn.

Guardando questi risultati puoi vedere che in una piccola quantità se il tuo browser sta invalidando la cache DNS. E la risoluzione DNS inizia a fallire.

Riferimento

• Perché la cache DNS del browser web può essere una brutta cosa

_{PS: Per aggiungere la beffa al danno, l'articolo collegato di Dyn sostiene che la cache DNS del browser è una brutta cosa.}

I browser non memorizzano nella cache i record DNS

Questa è una funzione del resolver che è un'aggiunta allo stack di rete.

DNS Il caching non aiuterebbe molto

I dispositivi schiavi mirai sono in grado di eseguire un numero qualsiasi di attacchi diversi come indicato dal CnC. Nel caso sia dell'attacco alla sicurezza di Krebbs che a DYN, gli aggressori hanno semplicemente riempito la loro larghezza di banda con il traffico, in realtà non importava quale fosse il traffico. Sebbene il DNS possa essere sfruttato per un attacco di amplificazione indiretto, è mia opinione che ciò non si applichi nel caso degli attacchi a Krebss e DYN. Il DNS è stato utilizzato in quest'ultimo attacco in quanto rendeva impraticabile filtrare il traffico reale dal traffico di attacco.

Se i record DNS sono stati memorizzati nella cache altrove accessibili agli utenti normali (nelle cache DNS, non nei browser), allora l'attacco avrebbe avuto un impatto molto minore, tuttavia il modello di business DYN si rivolge principalmente all'hosting DNS e alla fornitura all'utente finale. Quest'ultimo sarebbe stato interrotto a prescindere. La presenza dei dati nelle cache intermedie / altri fornitori di utenti finali è basata sul volume di traffico e sul tempo di scadenza (è mia esperienza che i tempi di scadenza inferiori a 2 ore sono inefficaci). Inoltre, un sito ad alto traffico avrà più punti di presenza geografici insieme a più record A in ogni POP: gli indirizzi multicast sono costosi e (a causa di edns-client-subnet) non sono richiesti oltre al DNS (in assenza di attacchi DOS ).

Il DNS è stato progettato principalmente per fornire una mappatura stabile (e vagamente coerente ) dei nomi agli indirizzi. Ai bei vecchi tempi, il Time To Live (TTL) sui record DNS era in genere compreso tra 3600 e 86400 secondi. Ci si aspettava che chiunque chiedesse un particolare record avresti sempre ottenuto la stessa risposta .

Alcune persone hanno poi pensato che se avessero usato TTL veramente brevi avrebbero potuto eseguire stupidi trucchi DNS ® che costringe il DNS a fare cose che non era previsto .

Ad esempio, alcune appliance di bilanciamento del carico hanno server DNS integrati che monitorano l'integrità del back- end server e forniscono una risposta diversa a ciascuna richiesta in entrata in base al loro carico corrente.

Alcuni operatori esaminano l'indirizzo di origine della query in arrivo e inviano risposte diverse per reindirizzare il client al cluster di applicazioni più vicino (noto anche come "bilanciamento del carico del server globale").

A proposito dell'attacco della scorsa settimana a Dyn: una buona pratica DNS era che distribuivi i tuoi server DNS autorevoli su più reti (e / o operatori) in modo che un attacco o un'interruzione su uno ti lascerebbe comunque con il DNS in esecuzione.

Tuttavia i "trucchi" sopra menzionati implicano algoritmi e "intelligenza" che non sono inerenti al DNS stesso così che diventa molto difficile (se non impossibile) fare affidamento sulla resilienza incorporata del DNS. Un sistema che genera risposte sintetizzate invece di utilizzare un file di zona non può essere condiviso tra più operatori utilizzando AXFR.

La cache DNS mitiga gli attacchi DDOS ai provider DNS, ma la cache DOVREBBE durare solo per un breve periodo.

Il tempo massimo di memorizzazione nella cache di un record di risorse è specificato dal server, chiamato TTL.

Il significato del campo TTL è un limite di tempo per quanto tempo un RR può essere conservato in una cache. Questo limite non si applica ai dati autorevoli nelle zone; è anche scaduto, ma a causa dei criteri di aggiornamento per la zona. Il TTL viene assegnato dall'amministratore per la zona in cui hanno origine i dati. Mentre TTL brevi possono essere utilizzati per ridurre al minimo la memorizzazione nella cache e un TTL zero impedisce la memorizzazione nella cache, la realtà delle prestazioni di Internet suggerisce che questi tempi dovrebbero essere dell'ordine dei giorni per l'host tipico. Se è possibile prevedere una modifica, il TTL può essere ridotto prima della modifica per ridurre al minimo l'incongruenza durante la modifica, e quindi riportato al valore precedente dopo la modifica.

(tratto da RFC 1034)

Il server può dire al risolutore che il record può essere memorizzato nella cache per oltre 68 anni, che di solito è abbastanza a lungo per riparare un attacco. Ma i server di solito non lo fanno. I grandi siti web non vogliono che un guasto nella rete li influenzi per molto tempo. Un modo per farlo è impostare il TTL dei record di risorse su un tempo relativamente breve, ad esempio 5 minuti. In questo modo, possono modificare il record DNS nel caso in cui alcuni dei loro server non funzionino. E i client che interrogano il RR ogni 5 minuti non sono molto sovraccarichi che interrogarlo solo una volta.

Inoltre, le applicazioni di solito memorizzano il RR nella RAM. Quindi i record vengono persi una volta riavviata l'applicazione. (Ci sono eccezioni. Ad esempio, puoi scaricare la cache di BIND nel filesystem.)

Voglio menzionare Namecoin qui. Memorizza i nomi di dominio sul disco, in una blockchain. Se il tuo sito web utilizza un dominio .bit, è improbabile che vada giù solo a causa del provider DNS.