ブラウザーのDNSキャッシュがDNSプロバイダーへのDDOS攻撃を緩和しないのはなぜですか？
DNSプロバイダーDynに対する最近のDDoS攻撃、およびその他の同様の攻撃が成功するのはなぜですか？ DDoS攻撃によってエンティティがダウンする可能性があることは確かです。そのエンティティがDNSサーバーを制御している場合、それらのネームサーバーへのクエリは失敗し、それらのネームサーバーの下にリストされているドメインは、まだIP情報を持っていないホストから到達できません。
ただし、ブラウザはDNSレコードをキャッシュするため、多くのホストは（少なくともキャッシュエントリが期限切れになるまで）それらのドメインのIP情報をすでに持っているため、ネームサーバーがダウンしているという事実は、キャッシュを持つホストには関係ありません。しかし、これはそうではないようです：昨日の攻撃中に、githubやnpmなどにアクセスできませんでした。
DNSキャッシュは、ネームサーバーが利用できなくなることを軽減することは間違いありません。 TTLが5分以下であることが非常に一般的です。したがって、DDOS攻撃がDynをダウンさせてから5分後には、キャッシュが無効になり、 githubなどをヒットする.
DNSキャッシュの小さな設計変更により、大きな違いが生じる可能性があります。ほとんどのDNSキャッシュは、TTLが期限切れになるとエントリを削除します。キャッシュはエントリを保持できますが、期限切れとしてマークします。期限切れのエントリに対するクエリが受信されると、キャッシュは最初に上流の名前を解決し、それが失敗した場合は、期限切れのエントリを返します。これは、技術的にはDNSプロトコルに違反していると考えられますが、より適切な失敗動作です。
しかし、私はこれが起こることを期待していません。 DNSサーバーがダウンした場合の影響は依然として重要です-キャッシュにないすべてのサイト。 DNSインフラストラクチャの運用を維持することに引き続き焦点が当てられます。
更新：@MatthieuMは EdgeDNS がこれを行うことを指摘しました。
@Shackledtodeskは正しい（+1）、ブラウザのキャッシュは短時間保持されます。皮肉なことに、この事実に関する最高の参考文献のいくつかがダインによって公開されています。
（Alexaによると）トップ1000のWebサイトをクエリするために書いた簡単なプログラムは、300 [5分]のTTL値で212ヒット、3600（TTLで192ヒットを示しています。 1時間）、TTLが600（10分）で116ヒット、TTLが86400で79ヒット。残りの結果は、50年代以下のヒットであり、範囲TTLの5（1ヒット）からTTLの864000（1ヒット）まで。
これは、Dynの研究者でテクニカルライターであるベンアンダーソンからの引用です。
これらの結果を見ると、ブラウザがDNSキャッシュを無効にしている場合に、少し時間が経過していることがわかります。そして、DNS解決が失敗し始めます。
参照
PS：侮辱を傷つけるために、Dynのリンクされた記事は、ブラウザのDNSキャッシュは悪いことだと主張しています。
ブラウザはDNSレコードをキャッシュしません
これは、ネットワークスタックの補助であるリゾルバの機能です。
DNSキャッシングはあまり役に立ちません
miraiスレーブデバイス は、CnCの指示に従って、さまざまな攻撃を実行できます。クレブスセキュリティとDYNの両方の攻撃の場合、攻撃者は帯域幅をトラフィックで埋めるだけでした-実際にはトラフィックが何であるかは問題ではありませんでした。 DNSは間接増幅攻撃に悪用される可能性がありますが、クレブスおよびDYNへの攻撃の場合には適用されないことは私の理解です。 DNSは、攻撃トラフィックから実際のトラフィックを除外することが実用的でなくなったため、後者の攻撃で使用されました。
DNSレコードが通常のユーザーがアクセスできる別の場所（ブラウザーではなくDNSキャッシュ上）にキャッシュされた場合、攻撃の影響ははるかに少なくなりますが、DYNビジネスモデルは主にDNSホスティングとエンドユーザープロビジョニングを対象としています。後者は関係なく中断されたでしょう。中間キャッシュ/その他のエンドユーザープロバイダーにデータが存在するかどうかは、トラフィックの量と有効期限に基づいています（私の経験では、有効期限が2時間未満の場合は効果がありません）。さらに、トラフィック量の多いサイトには、各POPに複数のAレコードとともに複数の地理的存在ポイントがあります-マルチキャストアドレスは高価で、（edns-client-subnetにより）DNS以外には必要ありません（DOS攻撃がない場合）。 ）。
DNSは主に、名前からアドレスへのstable（およびloosely coherent）マッピングを提供するように設計されました。古き良き時代、DNSレコードのTime To Live（TTL）は、通常3600〜86400秒の範囲でした。特定のレコードを要求した人はだれでもあなたは常に同じ答えを得るでしょうであると予想されました。
その後、一部の人々は、本当に短いTTLを使用すれば、DNSを強制的に実行するStupid DNSTricks®を実行できると考えました意図するものではありませんでした。
たとえば、一部の負荷分散アプライアンスには、バックエンドサーバーの状態を監視し、現在の負荷に基づいて各受信要求に対する異なる応答を提供する統合DNSサーバーがあります。
一部のオペレーターは、着信クエリのソースアドレスを確認し、さまざまな回答を返送して、クライアントを最も近いアプリケーションクラスター（別名「グローバルサーバーロードバランシング」）にリダイレクトします。
先週のDynへの攻撃-かつてのDNSの良い習慣は、権威のあるDNSサーバーを複数のネットワーク（またはオペレーター）に分散させて、1つのネットワークへの攻撃や停止が発生してもDNSを実行できるようにすることでした。
ただし、前述の「トリック」には、DNS自体に固有ではないカスタムアルゴリズムと「インテリジェンス」が含まれているため、DNSの組み込みの復元力に依存することが（不可能ではないにしても）非常に困難になります。ゾーンファイルを使用する代わりに合成回答を生成するシステムは、AXFRを使用して複数のオペレーター間で共有することはできません。
DNSキャッシュはDNSプロバイダーへのDDOS攻撃を軽減しますが、キャッシュは短時間だけ持続する必要があります。
リソースレコードがキャッシュされる最大時間は、TTLと呼ばれるサーバーによって指定されます。
TTLフィールドの意味は、RRをキャッシュに保持できる時間の制限です。この制限は、ゾーン内の信頼できるデータには適用されません。タイムアウトも発生しますが、ゾーンの更新ポリシー。TTLは、データが発生するゾーンの管理者によって割り当てられます。短いTTLを使用してキャッシュを最小限に抑えることができ、ゼロTTLはキャッシュを禁止します。インターネットパフォーマンスの現実は、これらの時間は通常のホストの日数である必要があることを示唆しています。変更が予想される場合、TTL変更中の不整合を最小限に抑えるために変更し、変更後に元の値に戻しました。
（RFC 1034から取得）
サーバーは、レコードを68年以上キャッシュできることをリゾルバーに通知できます。これは通常、攻撃を修正するのに十分な長さです。しかし、サーバーは通常そうしません。大きなWebサイトは、ネットワークの障害が長期間にわたって影響を与えることを望まない。これを行う1つの方法は、リソースレコードのTTLを5分などの比較的短い時間に設定することです。これにより、一部のサーバーでDNSレコードを変更できますそして、RRを5分ごとにクエリするクライアントは、一度だけクエリするよりも過負荷ではありません。
さらに、アプリケーションは通常、RRをRAMにキャッシュします。したがって、アプリケーションを再起動すると、レコードは失われます。 （例外があります。たとえば、BINDのキャッシュをファイルシステムにダンプできます。）
ここでNamecoinについて触れたいと思います。ディスク上のドメイン名をブロックチェーンに格納します。ウェブサイトが.bitドメインを使用している場合、DNSプロバイダーだけが原因でダウンする可能性はほとんどありません。