アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
TTLが5分や10分だから影響を受けやすい気もする (スコア:3, 参考になる)
動的IPですか?と思えるほど短い。
だから影響出易いんじゃ?
TTLが長ければ、ISPの複数のNSに問い合わせすれば大抵どれかにはキャッシュが残っていると思う。
Re:TTLが5分や10分だから影響を受けやすい気もする (スコア:3, 興味深い)
TTLを短くしておかないとCDN中のどれか一つサーバがダウンした場合でも,
そのサーバのアドレスがDNSキャッシュに長時間残り続けることになり,
悪影響を及ぼす可能性があるので.
というわけで今回のが攻撃だったとしたら,なかなか巧いところ
を突いてきたな,という感じです.
Re:TTLが5分や10分だから影響を受けやすい気もする (スコア:2)
>そのサーバのアドレスがDNSキャッシュに長時間残り続けることになり,
>悪影響を及ぼす可能性があるので.
この辺が今一よく分からん。
この枝の他の所に書いたが、IPアドレスを3つ答えて冗長化しているのでしょ。
家のIEの動作は、20秒待って取得出来なければ次のIPアドレスのサーバーに拾いに行くよ。
hostsで偽のプライベートIPアドレスを複数記載してテストした時も20秒経てば次のサーバーに探しに行っていた(次からは拾えたサーバーに行く)。
環境によって20秒と言う時間は違うのかもし
Re:TTLが5分や10分だから影響を受けやすい気もする (スコア:1)
connectに失敗して次のAレコードを試す,というのはよくある話ですが,中途半端にconnectだけは成功したけど,(DoSられていて)GETで何も降ってこない場合に,また次のAレコードを試すような実装 がどれだけあるのか.
またakamaiのDNSを引きに行くのがブラウザだけなのか,と
Re:TTLが5分や10分だから影響を受けやすい気もする (スコア:2)
と言うのはよく分かるが、
>また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って意味無いな。