Perché le cache DNS dei browser non attenuano gli attacchi DDOS sui provider DNS?

È corretto che la cache DNS si attenui a un server dei nomi non disponibile. È estremamente comune avere un TTL di 5 minuti o inferiore. Quindi, 5 minuti dopo che l'attacco DDOS ha eliminato Dyn, la tua cache non sarebbe stata valida e non avresti potuto colpire github, ecc.

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

Tuttavia, non mi aspetto di vederlo accadere. L'impatto dei server DNS non funzionanti sarebbe comunque significativo: tutti i siti che non sono presenti nella cache. L'attenzione rimarrà sul mantenere l'infrastruttura DNS operativa.

Aggiornamento: @MatthieuM ha sottolineato che EdgeDNS fa questo.

I browser non memorizzano nella cache i record DNS

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

La cache DNS non sarebbe di grande aiuto

I mirai dispositivi schiavizzati sono in grado di eseguire qualsiasi numero di differenti attacchi come indicato dal CnC. Nel caso sia dell'attacco alla sicurezza di Krebbs che di DYN, gli aggressori hanno semplicemente riempito la loro larghezza di banda con il traffico - non importava realmente quale fosse il traffico. Mentre il DNS può essere sfruttato per un attacco di amplificazione indiretto, è a mia conoscenza che questo non si applica nel caso degli attacchi su Krebss e DYN. Il DNS è stato utilizzato nell'ultimo attacco in quanto rendeva poco pratico filtrare il traffico reale dal traffico di attacco.

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

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

Alcune persone poi hanno capito che se usavano TTL veramente corti che potevano eseguire Stupid DNS Tricks® che costringevano il DNS a fare cose che non era destinato a fare .

Ad esempio, alcune appliance di bilanciamento del carico hanno server DNS integrati che monitorano lo stato dei server back-end 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 entrata e inviano risposte diverse per reindirizzare il client al cluster applicativo più vicino (ovvero "Global Load Balancing del server").

A proposito dell'attacco della scorsa settimana su Dyn - un buon allenamento del DNS era che dovresti distribuire i tuoi autorevoli server DNS su più reti (e / o operatori) in modo che un attacco o un'interruzione su uno ti lascerebbe comunque con DNS in esecuzione.

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

La cache DNS attenua gli attacchi DDOS sui provider DNS, ma la cache DOVREBBE durare per un breve periodo.

Il tempo massimo in cui un record di risorse deve essere memorizzato nella cache è specificato dal server, chiamato TTL.

The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change.

(tratto da RFC 1034)

Il server può dire al resolver che il record può essere memorizzato nella cache per oltre 68 anni, che di solito è abbastanza lungo per poter correggere un attacco. Ma i server di solito non lo fanno. I grandi siti Web non vogliono che un guasto nella rete li danneggi a lungo. Un modo per farlo è impostare il TTL dei propri record di risorse in un tempo relativamente breve, ad esempio 5 minuti. In questo modo, possono modificare il loro record DNS nel caso in cui alcuni dei loro server falliscano. E i client che eseguono query sull'RR ogni 5 minuti non sono molto sovraccarichi rispetto a una sola query.

Inoltre, le applicazioni di solito memorizzano nella cache la RR nella RAM. Quindi i record vengono persi dopo il riavvio dell'applicazione. (Ci sono delle eccezioni. Puoi scaricare la cache di BIND sul filesystem, per esempio.)

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.