パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

AkamaiへのDDosアタックでGoogleなどのDNSに障害」記事へのコメント

  • nslookupで調べたらTTLが短いよね。
    動的IPですか?と思えるほど短い。
    だから影響出易いんじゃ?
    TTLが長ければ、ISPの複数のNSに問い合わせすれば大抵どれかにはキャッシュが残っていると思う。
    • TTLが短いのはAkamaiの仕組み上,仕方の無い事と思われます.

      TTLを短くしておかないとCDN中のどれか一つサーバがダウンした場合でも,
      そのサーバのアドレスがDNSキャッシュに長時間残り続けることになり,
      悪影響を及ぼす可能性があるので.

      というわけで今回のが攻撃だったとしたら,なかなか巧いところ
      を突いてきたな,という感じです.
      • >TTLを短くしておかないとCDN中のどれか一つサーバがダウンした場合でも,
        >そのサーバのアドレスがDNSキャッシュに長時間残り続けることになり,
        >悪影響を及ぼす可能性があるので.

        この辺が今一よく分からん。
        この枝の他の所に書いたが、IPアドレスを3つ答えて冗長化しているのでしょ。
        家のIEの動作は、20秒待って取得出来なければ次のIPアドレスのサーバーに拾いに行くよ。
        hostsで偽のプライベートIPアドレスを複数記載してテストした時も20秒経てば次のサーバーに探しに行っていた(次からは拾えたサーバーに行く)。
        環境によって20秒と言う時間は違うのかもしれないが、探しに行かないブラウザってあるの?
        無いとは言い切れないと言う意味での「可能性」?

        ISPは複数のNSを設置して冗長化し、ユーザーはその複数のNSを冗長化して使うことによって各NSのキャッシュのTTLは違う値になる(問い合わせ時期が違うから)。
        TTLを一週間くらいに設定することによって、1日くらいNSが落ちていてもISPのキャッシュが利用されるので困らない。
        俺はこんな感じに設定すべきと思っていた。

        悪影響は滅多に無いはずだし、あるのならば違うブラウザを使うべきと思えるようなことへの対策としてTTLを5分と短くし、その結果ちょっとした攻撃を受けるだけで影響を受ける。
        これってTTL時間の設定ミスの気がしてならない。
        親コメント
        • >Akamaiは当初、同社だけでなくインターネットインフラに対する広範な攻撃があったと説明していたが、この説を翻した形。16日の発表によると、問題は米東部時間の15日午前8時半ごろから10時45分ごろにかけて発生した。ただ、DNSシステムが影響を受けたのは同社顧客の約4%のみで、2%で目に見える支障が出たが、ユーザーの20%以上に影響する大きな支障が出たのは同社顧客の1%に満たなかったとしている。
          >
          > 攻撃の影響でAkamaiのDNSに遅延が生じ、一部サイトでAkamaiのDNSサーバからの反応が低下してタイムアウトが発生。ただ、この攻撃でAkamaiのサービスに障害が起きたわけではなく、攻撃を受けている間も顧客向けのDNSリクエストとWebコンテンツのサービスは継続していたと強調している。
          http://www.itmedia.co.jp/news/articles/0406/17/news021.html

          何故一部のサイトだけ影響を受けたのかは書いていなかったが、やはり一部だけ影響を受けたと考えるとTTLが短いところだけ影響を受けた気がするな。
          殆どのサイトは影響を受けなかったと言うことは、アカマイのシステムの特長とはいえない気がする。
          親コメント
        • 確かに仰る通り複数Aレコードが返ってきたら,それを全部試しながらconnectしにいくのが期待される動作でしょうね.でも本当に全てのアプリケーションがそういう動作になっているかというと,それは怪しいのではないかと思います.
          connectに失敗して次のAレコードを試す,というのはよくある話ですが,中途半端にconnectだけは成功したけど,(DoSられていて)GETで何も降ってこない場合に,また次のAレコードを試すような実装 がどれだけあるのか.
          またakamaiのDNSを引きに行くのがブラウザだけなのか,という点も疑問です.
          およそレアなケースかもしれませんが,登録していたNSサーバが全て使えなくなった場合,とかもひょっとするとあるかもしれませんし.
          というように悪影響はないとは言い切れないと思いますよ.

          しかしこんなakamaiDNSの運用ポリシーはPaul Vixieにも批判されているようですね.結局はDNSサーバをDoSるか,WEBサーバをDoSるかの違いだけのように思います.
          親コメント
          • >connectに失敗して次のAレコードを試す,というのはよくある話ですが,中途半端にconnectだけは成功したけど,(DoSられていて)GETで何も降ってこない場合に,また次のAレコードを試すような実装がどれだけあるのか.

            と言うのはよく分かるが、

            >またakamaiのDNSを引きに行くのがブラウザだけなのか,という点も疑問です.
            >およそレアなケースかもしれませんが,登録していたNSサーバが全て使えなくなった場合,とかもひょっとするとあるかもしれませんし.
            >というように悪影響はないとは言い切れないと思いますよ.

            って、IPアドレス引けなければTTLの長短に関わらずアクセス出来ないよ。

            >しかしこんなakamaiDNSの運用ポリシーはPaul Vixieにも批判されているようですね.結局はDNSサーバをDoSるか,WEBサーバをDoSるかの違いだけのように思います.

            そうなんだけど、webサーバーの場合はTCPを使っているから3ウェイハンドシェイクが終わった奴だけまともに相手をすれば良いけど、DNSサーバーはUDPで答えるのが主流。この為ソースIPアドレスを偽った場合であってもまともに答える必要があるので、DNSサーバーはwebサーバーより攻撃耐性は無いと思う。

            「次のAレコードを試すような実装がどれだけあるのか」で、これを考慮するためにTTLを5分(等)にして、サーバーが落ちたら、落ちたサーバーのIPアドレスを通知しないんだろうけど、レイヤ3SWとかロードバランサーで違うサーバーに回した方がすっきりする様な気がする。
            それ以前に、折角3つのIPアドレスを通知してマルチホーミングにしているのに、次のAレコードを試さない実装だけしか考慮していないのはよく分からん。
            世界中の端末からサーバーまでの回線が確実に確保されているとはアカマイは知らないはず。
            と言うか、確保されていないことを想定してのマルチホーミングなのでは?
            サーバーが生きてても回線(ISP含む)が死んでいたらアクセス出来ないよね。単なるラウンドロビンだけの為に3つのIPアドレスを提示しているのだろうか?

            まぁ、アカマイは「DNSサーバーは耐え切れる」と思っての設計だろけど....
            思ったより各ISPのNSは根性が無くあきらめてしまうって感じなんだろう。

            ついでに、アカマイとグーグルの構造はよく分からんしあまり興味ないんで調べていないが、グーグルの管理下のドメインからアカマイの管理下のドメインに渡して、その後グーグルのIPアドレスを返しているよね。
            グーグルはアカマイで問題が発生しても、グーグル管理下のドメインから直接IPアドレスを返さないのね。折角TTLを15分にしているのに。
            監視し被害が沢山出る前に即効で切り替えないのならば、15分と言った短いTTLって意味無いな。
            親コメント

最初のバージョンは常に打ち捨てられる。

処理中...