アカウント名:
パスワード:
タレコミ元の元ネタであるSDSC: A National Laboratory for Computational Science and Engineering [sdsc.edu]によると、
だそうです。
2番目以降はなぜ起きるか想像がつきますが、最初の"Repeated and identical queries"の原因がよくわかりません。
これの起きる理由と対策をどなたかお教えください。
# 単なるDoS?
○Lame Delegation ・上位から指定されたネームサーバが、ゾーンの情報を持っていない場合をLAMEという ・最初は正しく設定されていたが、後にマスターが消え、スレーブだけで運用しているエラー例もある ・一部がLameでも再問い合わせが発生し、無駄なトラフィックに
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
No.1の原因と対策 (スコア:1, 興味深い)
タレコミ元の元ネタであるSDSC: A National Laboratory for Computational Science and Engineering [sdsc.edu]によると、
だそうです。
2番目以降はなぜ起きるか想像がつきますが、最初の"Repeated and identical queries"の原因がよくわかりません。
これの起きる理由と対策をどなたかお教えください。
# 単なるDoS?
Re:No.1の原因と対策 (スコア:2, 興味深い)
ネームサーバが引いた結果をキャッシュする期間が短いと、再度問合せ
しますよね。
内容が変更されていないのに、再度問合せをされるのは無駄ともいえます。
変更頻度が多い場合は短くしたほうがいいですが、ほとんど変更しない、
アクセス数が極めて大きいサイトのDNS TTLは大きくすべきじゃないでしょうか。
ふと思いついて、日本でも有数（下手すると世界有数？）のアクセス数を
集めるという某巨大掲示板の最も人気の高いサーバのDNSを調べたところ、
TTLがたったの300秒（５分）しかありません。
私にはDNSサーバの詳しい動作はわかりませんが、TTLが切れた時にルートサーバに
問合せを始めるのか、そのドメインのDNSサーバに問い合わせるのかわかりません。
もし前者なら、この５分という極めて短いTTLの影響はルートサーバには大きな
負担かと思います。
Re:No.1の原因と対策 (スコア:1)
影響がないと思うのですが、違うんでしょうか?
#タレコんだものの、DNSを理解していない・・・
Re:No.1の原因と対策 (スコア:1)
重なるホストが無くなったんですね。
昔はgtldもrootも同じホストでやってた奴とか居て、タフな奴とか思ってたけ
ど、流石にメゲたか。
Re:No.1の原因と対策 (スコア:0)
でも、
利用者が様々なドメインに属するリンクをいっぱい貼ってる。
第一、リンク先に飛ぶ前に、おなじみの広告サイト(http://ime.nu
の下)もみんな見る。
# これまた半可通のAC
Re:No.1の原因と対策 (スコア:1)
ルートサーバどころか、2ch.netドメインのDNSサーバすら無関係になると思うのですが。
これを機会に勉強します。
#武蔵川部屋の朝稽古見学を抜け出してカキコ。福岡在住です。
Re:No.1の原因と対策 (スコア:0)
問い合わせをするのはクライアントホストのレゾルバですね。
当然、そっちが知ってるDNSに聞くはず...。
でもルートサーバが無意味に近い問い合わせ攻めになるのは
変りなさそう。
TTLが切れた時にルートサーバに問合せを始めるのか (スコア:1, 参考になる)
問い合わせません(おおむね)。
ある企業examples.jpのAレコードを問い合わせる場合
jpのネームサーバのキャッシュがあれば、
jpネームサーバへ問い合わせに行きます。
いま調べたところjpネームサーバでのNSとAのTTLは86400秒なので
ある企業のTTLが300秒でもルートサーバにクエリはそんなに行かないはずです。
(resolv.confにルートサーバが列挙してある等「DNSキャッシュサーバが介在してない」場合は除く)
上で書いたjpのTTL値は
dig jp. @A.DNS.JP ns
とか
dig A.DNS.JP @A.DNS.JP
とかして確かめることができます。
# 1.の理由は"UDPだから"あたりが正解じゃないかと思う
Re:No.1の原因と対策 (スコア:1)
NS RR(下位ネームサーバ名の書いてあるレコード)のTTLだけ
大きくしておけば、A RR(アドレスの書いてあるレコード)のTTLは
5分程度でもパフォーマンスに殆んど影響を与えない、という
論文を読みました。
‥‥‥調べてみたら300秒なので、かなりイケてない感じでした :-(
2ch.net. 300 IN NS ns2.he.net.
2ch.net. 300 IN NS ns3.he.net.
2ch.net. 300 IN NS ns1.he.net.
Re:No.1の原因と対策 (スコア:0)
Re:No.1の原因と対策 (スコア:2, すばらしい洞察)
サーバを入れ替える時(前)に短くすればいいのだ。
Re:No.1の原因と対策 (スコア:0)
Re:No.1の原因と対策 (スコア:0)
ネットワークとサーバ運用の設計からやり直しましょう。という話しになるね。
Re:No.1の原因と対策 (スコア:0)
普段のTTLが無効になるタイミングで短くなってればいいだけだから。
Re:No.1の原因と対策 (スコア:0)
推測 (スコア:0)
＞問合せを始めるのか、そのドメインのDNSサーバに問い合わせるのかわかりません。
＞もし前者なら、この５分という極めて短いTTLの影響はルートサーバには大きな負担かと思います。
まず。
DNSのキャッシュが切れていれば、上位のDNSサーバに問い合わせが
行くはずで
Re:No.1の原因と対策 (スコア:2, 参考になる)
でしょうね、lame delegationって。
ここ [janog.gr.jp]あたりを見て頂ければいいかと。
ログ [janog.gr.jp]の方からの引用ですが、