Sie haben Recht, dass der DNS-Cache verhindern würde, dass ein Nameserver nicht verfügbar ist. Es ist äußerst üblich, eine TTL von 5 Minuten oder weniger zu haben. Daher wäre Ihr Cache 5 Minuten nach dem DDOS-Angriff von Dyn ungültig gewesen und Sie hätten Github usw. nicht treffen können.

Eine kleine Designänderung an DNS-Caches kann einen großen Unterschied machen. Die meisten DNS-Caches entfernen einen Eintrag, wenn die TTL abläuft. Ein Cache könnte stattdessen den Eintrag behalten, ihn jedoch als abgelaufen markieren. Wenn eine Abfrage für einen abgelaufenen Eintrag eingeht, versucht der Cache zunächst, den Namen im Upstream aufzulösen. Wenn dies fehlschlägt, geben Sie den abgelaufenen Eintrag zurück. Ich gehe davon aus, dass dies technisch gegen das DNS-Protokoll verstößt, aber immer noch ein besseres Fehlerverhalten darstellt.

Ich erwarte jedoch nicht, dass dies geschieht. Die Auswirkungen eines Ausfalls von DNS-Servern wären immer noch erheblich - alle Websites, die Sie nicht in Ihrem Cache haben. Der Fokus wird weiterhin darauf liegen, die DNS-Infrastruktur betriebsbereit zu halten.

Update: @MatthieuM hat darauf hingewiesen, dass EdgeDNS dies tut.

@Shackledtodesk ist korrekt (+1), der Browser-Cache bleibt für kurze Zeit erhalten. Ironischerweise wurden einige der besten Referenzen zu dieser Tatsache von Dyn veröffentlicht:

Ein einfaches Programm, das ich geschrieben habe, um die 1000 besten Websites abzufragen (laut Alexa), zeigt 212 Treffer mit einem TTL-Wert von 300 (5 Minuten), 192 Treffer mit einer TTL von 3600 (1 Stunde), 116 Treffer mit einer TTL von 600 (10 Minuten) und 79 Treffer mit einer TTL von 86400. Der Rest der Ergebnisse hatte Treffer in den 50er Jahren und weniger Dies reicht von einer TTL von 5 (1 Treffer) bis zu einer TTL von 864000 (1 Treffer).

Dies ist ein Zitat von Ben Anderson, einem Forscher und technischen Redakteur bei Dyn.

Wenn Sie sich diese Ergebnisse ansehen, können Sie feststellen, dass Ihr Browser über einen kleinen Zeitraum den DNS-Cache ungültig macht. Und Ihre DNS-Auflösung schlägt fehl.

Referenz

• Warum DNS-Caching im Webbrowser eine schlechte Sache sein kann

_{PS: Um die Verletzung zusätzlich zu beleidigen, argumentiert der verlinkte Artikel von Dyn, dass der DNS-Cache des Browsers eine schlechte Sache ist. sub>}

Browser zwischenspeichern keine DNS-Einträge

Dies ist eine Funktion des Resolvers, der eine Ergänzung zum Netzwerkstapel darstellt.

DNS Caching würde nicht viel helfen

Die mirai versklavten Geräte sind in der Lage, eine beliebige Anzahl verschiedener Angriffe auszuführen, wie vom CnC angewiesen. Sowohl beim Angriff auf Krebbs Sicherheit als auch auf DYN füllten die Angreifer einfach ihre Bandbreite mit Verkehr - es war eigentlich egal, um welchen Verkehr es sich handelte. Während DNS für einen indirekten Verstärkungsangriff ausgenutzt werden kann, gilt dies meines Wissens nicht für Angriffe auf Krebss und DYN. DNS wurde bei letzterem Angriff verwendet, da es unpraktisch war, echten Datenverkehr aus dem Angriffsdatenverkehr herauszufiltern.

Wenn die DNS-Einträge an einer anderen Stelle zwischengespeichert wurden, auf die normale Benutzer zugreifen können (in DNS-Caches, nicht in Browsern) Der Angriff hätte viel weniger Auswirkungen gehabt, das DYN-Geschäftsmodell zielt jedoch hauptsächlich auf DNS-Hosting und Endbenutzerbereitstellung ab. Letzteres wäre trotzdem gestört worden. Das Vorhandensein der Daten in Zwischen-Caches / anderen Endbenutzer-Anbietern hängt vom Verkehrsaufkommen und der Ablaufzeit ab (meiner Erfahrung nach sind Ablaufzeiten von weniger als 2 Stunden unwirksam). Darüber hinaus verfügt eine Site mit hohem Datenverkehr über mehrere geografische Präsenzpunkte sowie mehrere A-Einträge an jedem POP. Multicast-Adressen sind teuer und (aufgrund des Edns-Client-Subnetzes) nur für DNS erforderlich (ohne DOS-Angriffe) ).

Der DNS wurde hauptsächlich entwickelt, um eine stabile (und lose kohärente ) Zuordnung von Namen zu Adressen bereitzustellen. In den guten alten Tagen lag die Time To Live (TTL) für DNS-Einträge normalerweise im Bereich von 3600 bis 86400 Sekunden. Es wurde erwartet, dass jeder, der nach einem bestimmten Datensatz fragte, immer die gleiche Antwort erhalten würde .

Einige Leute dachten dann, wenn sie wirklich kurze TTLs verwenden würden, könnten sie dumme DNS-Tricks ausführen ®, die den DNS dazu zwingen, Dinge zu tun, für die er nicht vorgesehen war .

Einige Load-Balancing-Appliances verfügen beispielsweise über integrierte DNS-Server, die den Zustand des Back- überwachen. Beenden Sie die Server und stellen Sie basierend auf ihrer aktuellen Auslastung eine andere Antwort auf jede eingehende Anforderung bereit.

Einige Bediener überprüfen die Quelladresse der eingehenden Abfrage und senden unterschiedliche Antworten zurück, um den Client zum nächsten Anwendungscluster umzuleiten (auch bekannt als "Global Server Load Balancing").

Apropos Angriff der letzten Woche auf Dyn - Früher war es eine gute DNS-Praxis, Ihre autorisierenden DNS-Server auf mehrere Netzwerke (und / oder Betreiber) zu verteilen Bei einem Angriff oder Ausfall eines DNS müssen Sie immer noch DNS ausführen.

Bei den oben genannten "Tricks" handelt es sich jedoch um maßgeschneiderte Tricks Algorithmen und "Intelligenz", die dem DNS selbst nicht eigen sind, so dass es sehr schwierig (wenn nicht unmöglich) wird, sich auf die integrierte Ausfallsicherheit des DNS zu verlassen. Ein System, das synthetisierte Antworten generiert, anstatt eine Zonendatei zu verwenden, kann mit AXFR nicht von mehreren Operatoren gemeinsam genutzt werden.

Der DNS-Cache verringert DDOS-Angriffe auf DNS-Anbieter, der Cache sollte jedoch nur eine kurze Zeit dauern.

Die maximale Zeit, die ein Ressourceneintrag zwischengespeichert werden soll, wird vom Server als TTL angegeben.

Die Bedeutung des TTL-Felds ist ein Zeitlimit dafür, wie lange eine RR in einem Cache aufbewahrt werden kann. Diese Grenze gilt nicht für maßgebliche Daten in Zonen. Es wird auch eine Zeitüberschreitung festgestellt, jedoch durch die Aktualisierungsrichtlinien für die Zone. Die TTL wird vom Administrator für die Zone zugewiesen, aus der die Daten stammen. Während kurze TTLs verwendet werden können, um das Caching zu minimieren, und eine TTL von Null das Caching verbietet, legen die Realitäten der Internetleistung nahe, dass diese Zeiten für den typischen Host in der Größenordnung von Tagen liegen sollten. Wenn eine Änderung erwartet werden kann, kann die TTL vor der Änderung reduziert werden, um Inkonsistenzen während der Änderung zu minimieren, und nach der Änderung wieder auf ihren vorherigen Wert erhöht werden.

(aus RFC entnommen) 1034)

Der Server kann dem Resolver mitteilen, dass der Datensatz über 68 Jahre zwischengespeichert werden kann, was normalerweise lang genug ist, um einen Angriff zu beheben. Server tun dies jedoch normalerweise nicht. Große Websites möchten nicht, dass ein Fehler im Netzwerk sie für lange Zeit beeinträchtigt. Eine Möglichkeit, dies zu tun, besteht darin, die TTL ihrer Ressourceneinträge auf eine relativ kurze Zeit festzulegen, z. B. 5 Minuten. Auf diese Weise können sie ihren DNS-Eintrag ändern, falls einige ihrer Server ausfallen. Und Clients, die die RR alle 5 Minuten abfragen, sind nicht viel überlastet, als sie nur einmal abzufragen.

Außerdem zwischenspeichern die Anwendungen die RR normalerweise im RAM. Die Datensätze gehen also verloren, sobald die Anwendung neu gestartet wird. (Es gibt Ausnahmen. Sie können beispielsweise den BIND-Cache im Dateisystem ablegen.)

Ich möchte hier Namecoin erwähnen. Es speichert Domänennamen auf der Festplatte in einer Blockchain. Wenn Ihre Website eine .bit-Domain verwendet, ist es unwahrscheinlich, dass sie nur aufgrund des DNS-Anbieters ausfällt.