ルートサーバへの問い合わせの多くが無駄なもの？ 77
ストーリー by wakatono
無駄無駄無駄無駄無駄ァ！ 部門より
無駄無駄無駄無駄無駄ァ！ 部門より
nobita曰く、"@ITの「DNS Tips」に「ルートサーバへの問い合わせの多くが無駄なもの？」という記事が追加されていました。
これによると、あるルートサーバに対する問い合わせの内、実に98%が不必要なものだそうです。
ひたすら無駄な問い合わせに答えるルートサーバを想像すると涙がでちゃう。人間だったらノイローゼ確実ではないですか!"
そもそも人間とちゃうやろ (スコア:4, すばらしい洞察)
>人間だったらノイローゼ確実ではないですか!
だから機械にやらせるんだよ
Re:そもそも人間とちゃうやろ (スコア:2, おもしろおかしい)
俺は人間をやめるぞ!!
Re:そもそも人間とちゃうやろ (スコア:1, おもしろおかしい)
ルートサーバのぼやき (スコア:2, おもしろおかしい)
一度でいい事を何度も言わなきゃならないって事は
そいつの頭が悪いってことです
無駄なんだ、だから嫌いなんだ
無駄…無駄…
Re:ルートサーバのぼやき (スコア:1, 参考になる)
Re:ルートサーバのぼやき (スコア:2, おもしろおかしい)
Re:ルートサーバのぼやき (スコア:1)
うちのサーバが、２億バイト送受信してる凄いなと思ったら、 会社のは１２億を超えてた。
主記憶64MBだから、メモリ・リークしてないのね。(あたりまえだけれど)
Re:ルートサーバのぼやき (スコア:1)
> うちのサーバが、２億バイト送受信してる凄いなと思ったら、会社のは１２億を超えてた。
> 主記憶64MBだから、メモリ・リークしてないのね。(あたりまえだけれど)
OS によっても異なると思うけど、これってバイト単位なんでしょうか?
会社で個人的に使ってるマシンは TurboLinux 6.5 Server (linux kernel 2.2.18)では、
netstat -s したときは、
Ip:
10234808 total packets received
とか、
Tcp:
(略)
2818118 segments received
2786644 segments send out
とか、パケット単位でしか見られませんでした。
kernel のバージョンによって異なるのかな。
$ cat /proc/net/dev
すれば バイト単位で見られました。
Re:ルートサーバのぼやき (スコア:1)
tcp:
378811740 packets sent
374502003 data packets (3704047248 bytes)
(snip)
163429997 packets received
142523091 acks (for 3704046205 bytes)
他で、サーバに 1GB 積んでるとか話が出てましたが
貧弱な環境下の方が馬脚が現れやすいと思うのです。
確認してみたら、ヒトケタ間違って記憶してたみたい。
ファイル・サーバとGb Hub の耐久テスト継続中。
Re:ルートサーバのぼやき (スコア:0)
主記憶が64MBだと、何故メモリリークしない??
いや、単純なる疑問です･･･
Re:ルートサーバのぼやき (スコア:1)
Re:ルートサーバのぼやき (スコア:0)
Re:ルートサーバのぼやき (スコア:0)
９８％が無駄なら,,, (スコア:2, おもしろおかしい)
一度、全部のルートが落ちて見るのもおもろいかもね。
スタージョンの法則 (スコア:2, おもしろおかしい)
最悪のケース (スコア:2, おもしろおかしい)
幸い「ルートサーバのアドレス教えて」と来る前にツッコミ入れて阻止しましたが、こんな事が世界中で起きてるのかなぁ・・・。
Re:最悪のケース (スコア:3, すばらしい洞察)
雑誌で買ってきたLinuxディストリビューションを入れると、
ほとんど自動的にDNSができあがることもある。
そのデフォルト設定にルートサーバーの羅列がある。
で、多くの人はそれで動けばそのまま放置するので、
世界中にそんなものがいっぱいあれば無駄だらけで仕方ないかも。
Re:最悪のケース (スコア:2)
当然ありますよ。ルートサーバが判らなかったらどうやってフルサービスリゾルバは名前解決するんですか。つーかネタ？
「ネームサーバの3つの働きとは」に図を用いた説明がありますが、フルサービスリゾルバはルートサーバを知らないと、下位のさーばがキャッシュされていない時やされていてもキャッシュのTTLが切れた時、名前解決できないですよね。時間が経過するにつれ、下位のサーバがキャッシュに入るので、結果としてルートサーバへの問い合わせは減っていきます。
BOMBAさんの話は、コンテンツサーバであるルートサーバを、フルサービスリゾルバに指定したら？とアドバイス(本人はそのつもり)をしてる奴がいたという話ですから(当然名前の解決は出来ない。.comのゾーンサーバ一覧が返されるだけ)、DNSサーバにルートサーバの羅列が～とかいう話とは、全く関係無いと思いますよ。
＃まぁ俺も森下さん達の本で勉強しただけなのでID:-) [atmarkit.co.jp]
Re:最悪のケース (スコア:1)
＃最悪のケース......(泣)
Re:最悪のケース (スコア:2)
＞みんな自分自身がフルサービスリゾルバとして活躍している現状
＞は正しいということ？
現状ってそうなんですか？てっきり私は自前でキャッシュサーバを動かしている自分が特殊なんだと思っていましたが.....
＃ちゅーか普通の人は自分でキャッシュサーバなんか動かさないと思う......
Re:最悪のケース (スコア:2)
ああ、そうでしたね、前提忘れてましたw
いや、別にかまわないんじゃないですか？プロバイダのキャッシュサーバへの
負荷が減って、「DNSの調子が悪いんですよー」って言う人が減るなら。
＃もちろん適切に設定をした状態で運用する、という大前提はありますけど......
Re:最悪のケース (スコア:1)
Unknown (スコア:2, 興味深い)
2.Unknown top-level domains (13 percent)
ってあるのですが、引いてみないことにはそれが存在しないのかということ自体判らないわけですんで厳密には無駄とはいえないのでは？
Re:Unknown (スコア:1, すばらしい洞察)
> 自体判らないわけですんで厳密には無駄とはいえないのでは？
microsoft.con のようなあからさまなtypoに対する
指摘作業までrootserverにやらせようとするのは
rootserverから見れば無駄なことをやらされてるという
判断になっても妥当だと思います。
Re:Unknown (スコア:2, おもしろおかしい)
Re:Unknown (スコア:1)
そういう未来の保障のために払い続けるコストを軽減する仕組みがキャッシュなんだろうけど、それを含めたシステムもろもろがうまく機能しているとは言いがたいんだろうなぁ。
DNSはインターネットの汚点だと思ってるのでID。
もっと多くの部分がP2Pになれると思うんだよな。
P2Pに夢持つなよ (スコア:1)
伝播するし設計上は問題ない(イケてない実装が多いことも問題らしいが)。
それよりも、P2Pにあまり夢持たないほうがいいよ。集中しているからこそ
パフォーマンスが出せ、管理できるという点が、以外と軽く見られがちだと
思う。多分、工夫するならキャッシュメカニズムを改善するのが常道かと。
DNSの上に独自P2Pな名前空間をwrapする研究をしていた事があるのでID。
# あーでもDHT使ってもう一度作ってみるかなぁ。
## もっと言うと、www.google.comのように「みんなが参照する名前」と、
## printer01.moge-division.hoge-company.com のように「一部しか参照しない
## 名前」と最適なシステムが異なると思ってるんだよねぇ‥‥‥。線引きが
## 難しいんだけどさ。
Re:Unknown (スコア:1, 興味深い)
# それでも2.は13%だしなぁ... 減って半分か?
人間だって(オフトピ) (スコア:2, すばらしい洞察)
問い合わせの60%は、んなこと聞いてくるなっ!!というようなものです。
動作条件満たしてないとか、前と同じ質問してくるとか・・・
404 Not Foundで (スコア:1)
密かに/.-jも (スコア:5, おもしろおかしい)
404の時はいろいろしゃべってます [slashdot.jp]
Re:密かに/.-jも (スコア:1)
しゃべって欲しかったな。英語読めないけど。
1を聞いて0を知れ!
Re:404 Not Foundで (スコア:0)
Re:404 Not Foundで (スコア:1, おもしろおかしい)
＃今更のツッコミ。
Re:404 Not Foundで (スコア:0)
http://www.higuchi.com/404/ [higuchi.com]ですね。
/.Jの過去記事 [slashdot.jp]にあります。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の原因と対策 (スコア:1)
ルートサーバどころか、2ch.netドメインの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の原因と対策 (スコア:2, 参考になる)
でしょうね、lame delegationって。
ここ [janog.gr.jp]あたりを見て頂ければいいかと。
ログ [janog.gr.jp]の方からの引用ですが、
98%も... (スコア:1)
半分以上は無駄なものかな、と思ってましたけど、
えらく多いですね。
たとえば、世の中のLame Serverを根絶したとして、
どれくらい減るものでしょう。
将来もこの仕組みのままやっていけるのか、少し心配です。
デジャ・ビュ (スコア:1, 興味深い)
だいぶ昔にこのニュースを見た経験がある…
> SDSC Press Release
> January 23, 2003
> San Diego Supercomputer Center Researchers Find Unnecessary
> Traffic Saturating a Key Internet "Root" Server
あ、1月のニュース。納得納得。
しかし物忘れの激しさに気付き、またショック。
INTERNET Watch とか (スコア:1)
lame-ttl (スコア:1)
# bind9 での値
例えば、デフォルトをもっと長くしちゃえば、相対して lame で重複する問い合わせって減ると思うんですけど、なんでしないでしょう?