パスワードを忘れた? アカウント作成
3680 story

.orgの管理はISOCへ? 8

ストーリー by Oliver
どこでも今よりはマシかも 部門より

brake-handle曰く、"本家の記事も出ているが、ZDNetの記事によるとTLDの1つ、.orgの新しい管理者がInternet Society(ISOC)となる可能性が出てきた(ZDNet日本語版速報)。ICANNが11の候補団体の中から推奨したもの。
.orgは現在.comとともにVeriSignの管理下にあるが、来年1月を持ってVeriSignは.orgの管理を終了することになっている。それにともない、後継者探しが行われていた。その候補であるISOCは非営利団体とされているが、ICANNwatch記事によるとメンバーにMicrosoftや3Comなどの大物が含まれていることや、ICANNの中心人物にISOCのメンバーがいることが指摘されており、管理団体の独立性を疑問視している。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2002年08月21日 18時21分 (#150173)
    .eduドメインの管理がVeriSignからDEUCAUSEに移った
    http://www.watch.impress.co.jp/internet/www/article/2001/0413/edu.htm
    とき、VeriSignはいわれのない請求書を.eduドメインを持っている人に
    送り付けてきました。かなりの混乱を巻き起こしました。
    http://www.educause.edu/edudomain/news_fee_policy.asp
    .orgドメインを持っている人は注意しましょう。
  • 昔からよく言われてるように、ドメインの管理に関しては中立で公平で公共的でなければならないにもかかわらず利益がすごく取れてしまうのでこういう事になってるわけですよね。
    ニュースサイトをチェックするまでもなく、営利組織(またはその関連組織)が管理に回ることになるんだろうなー・・・というかとは、もうみんな思ってるんじゃないでしょうか?
    公平中立はやっぱり無理?
    --
    ---------- ------ ISHII Nayuta
    • ドメインを切り売りしているだけだったら、見た目楽そうな商売です。実際にコストがかかるのは、大抵そのドメインを走らせる方なんですよね。仕事場でSOAを持って分かったのですが、例えば停電やネットワーク構成変更などの時にも名前が絶えず引けるようにしておくには、セカンダリの手配やNSを世界に伝搬させるためのタイムラグなど、かなり気を使います。

      単なる思いつきですが、セカンダリとしてのzone所有やupdateを上位domainの管理者に義務づけるというのはどうでしょう? 使う側としては、TLDにもなれば引けないことはあり得ないので可用性が上がります。また、ドメインを引く場合にはroot、TLDと引いていくので、TLDのNSがqueryに答えることができればInternet全体のdns traffic軽減にもつながります。

      primaryとのconsistency確保など、TLD管理者にとっては新しい負担ができます。ですが、末端じゃこんなことをいつもやっていたわけなので、こんなことだけで音を上げて欲しくはありません。

      親コメント
      • しばらく考えないと意味が不明でしたが、
        つまり、co.jpのNameServerが、hoge.co.jpのセカンダリをかねる、ということに読めました
        それって、分散管理していた意味がなくて、Internet全体はともかく、上位のNameServerの負荷(検索、アップデート、メモリ、流量など)がトンでもなく上がる気が(.COMとか)、、
        あと、停電のときに別の場所にある鯖からDNSだけ引けてもあんまり意味がないような、、(たとえばmail鯖が動いているなら、DNS鯖も動けると思いますが)
        親コメント
        • それって、分散管理していた意味がなくて、Internet全体はともかく、上位のNameServerの負荷(検索、アップデート、メモリ、流量など)がトンでもなく上がる気が(.COMとか)

          まず注意。networkがhostに与える負荷を考える場合は、データサイズではなくてpacket数で考えるのが鉄則です(割込頻度を支配するのはpacket数)。これを踏まえると、一番networkを重くしてくれるのは、queryとそれに対するanswerです。個々のpacketは小さいくせに(特にquery)、packetの数は大量になってしまいます。updateはSOAのserial numberが上がった時だけですし、packetも大きいので楽です。メモリは高々数十MB程度、link上のrouter数が多い場合のospfや大量にpeeringしているbgpが走っているrouterと同程度です。つまり、query以外の問題はすでに解決しているのです。

          ではqueryをどうするか。TLDのNSがzoneを持っている場合、co.jp.のNSにfoo.hoge.co.jp.を聞いた時点で直ちにその結果が返ります。hoge.co.jp.のNSを返す必要がないため、packet数が節約できます。また、TLD NSの中だけで閉じたrecursive queryになるので、networkよりはずっと高速です。

          あと、停電のときに別の場所にある鯖からDNSだけ引けてもあんまり意味がないような、、(たとえばmail鯖が動いているなら、DNS鯖も動けると思いますが)

          MXとdns serverは同じである必要はありません。どこかはなれたところにsecondary MXを置いている場合には十分意味があります(本来はそうすべきもの)。

          親コメント
  • 日本のZDNNにも、詳細記事「.org」管理者の最有力候補はISOC。ICANNが推薦 [zdnet.co.jp]がでました。訳文ですね。
    --
    ---------- ------ ISHII Nayuta
  • by hebereke (10558) on 2002年08月22日 14時22分 (#150738) 日記
    結局このシナリオ [mycom.co.jp]通りに進んでしまったという事でしょうか。

    # 「あの時代のネットは今からは想像も出来ないほど自由闊達で…」と今日を語る日が来るのだろうか。
    • >結局このシナリオ [mycom.co.jp]通りに進んでしまったという事でしょうか。

      違うよ。よく読めよ。
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...