ドメイン名をめぐる最近の話題

新潟インターネット研究会

金 東虎

1. ドメイン名システム

歴史

1970年代、ARPANETはわずか数百台のホストから構成される、 非常に小さなネットワークであった。 これらのホストに関する情報はすべて HOSTS.TXTという一つのファイルに収められていた。 ファイルの体裁はUnixの/etc/hostsとよく似ていた。 すなわち、ホストの名前とIPアドレスとの対応がずらずら並んでいたのである。

このファイルはSRI-NIC (Stanford Research Institute - Network Information Center)によって一元管理されていた。 ARPANETの各サイトの管理者は、自分のサイトのホスト情報に変更が生じると、 それを電子メールでSRI-NICに連絡し、 SRI-NICの担当者は手動でその変更をHOSTS.TXTに反映させたのである。 また、各サイトの管理者は定期的にSRI-NICからftpで最新のHOSTS.TXTを取り寄せ、 自分のサイトのホストテーブルを更新する作業を怠らないようにしていた。

当然のことながら、この仕組みはARPANETの規模が大きくなるにつれて破綻した。 そこで1983年に登場したのがDomain Name System (DNS)である。 ( RFC882 , RFC883 , RFC1034 , RFC1035 ) このシステムは Internetが数千万台のホストで構成される規模になった現在においても 十分に機能しており、なおかつ当分の間は大丈夫であろうと言われている。 すなわち、きわめて高いスケーラビリティを持ったシステムなのである。

DNS

ドメイン名システムは分散型データベースシステム (Distributed Database System) である。一般に分散型データベースシステムと言えば、 リレーショナルデータベースシステムの各リレーションが 地理的に分散配置されているモデルを思い浮かべる人が多いかもしれないが、 ドメイン名システムは違う。

ドメイン名システムのもっとも大きな特徴は、 そのデータベースの構造がツリーになっていることである。 計算機科学で出て来るツリーは、自然界の木とは異なる。 不思議なことに、根(ルート)が一番上にあり、下に向かって伸びていくのである。

ツリー構造を理解するためには、 Unixのファイルシステムを思い浮かべるのがよいかもしれない。 Unixファイルシステムにおける「ディレクトリ」がドメイン名システムにおける 「ドメイン」に相当する。 「サブディレクトリ」、「サブドメイン」についても同様に考えればよい。

Unixファイルシステムとドメイン名システムは構造としては似通っているが、 表記法はまるで逆になっている。 すなわち、Unixファイルシステムにおいては、 ルートから葉に向かって / (スラッシュ) で区切りながら記述していくが、 ドメイン名システムにおいては逆に、 葉の方からルートに向かって . (ドット) で区切りながら記述する。

ドメイン名システムのもう一つの大きな特徴は、 各ドメインを異なる組織が管理することができることにある。 ルートドメインはInterNICが管理し、jpドメインはJPNICが管理し、 niigata-u.ac.jpドメインは新潟大学が管理し、 dent.niigata-u.ac.jpドメインは新潟大学歯学部が管理する、 といった具合である。 ドメイン名システムにおいては、ドメインが異なっていれば、 たとえ名前が衝突していても違うものとみなされるので、 各ドメインの管理者は自由に名前を付けることができる。

ドメイン名空間

DNSツリーの全体をドメイン名空間と呼ぶ。

ドメイン名

DNSツリーの各ノードには(ドットを含まない)簡単な名前のラベルが付けられる。 このラベルの長さは63文字までとなっている。 当初は数字で始まってはいけないという制限があったが、この制限は RFC1123 で緩和された。 ルートドメインには空の(長さゼロの)ラベルがあらかじめ付けられている。 各ノードの完全なドメイン名はそのノードからルートに向かうパス上を、 ラベルを . (ドット) で区切りながら並べたものである。

ドメイン

ドメインとは単にドメイン名空間の中の、あるサブツリーのことである。 ドメインのドメイン名は、 そのサブツリーの中でのルート(最上位)ノードのドメイン名と同じになる。

TLD

ルートドメインの直下にあるドメインをTop Level Domain (TLD)と呼ぶ。 ここでは、文字数によってTLD大きく3種類に分類してみる。

委任

ドメイン名システムが作られた大きな目的は、管理を集中させないことであった。 これは委任(delegation)で実現される。 ドメインの仕事を委任するのは、職場で仕事を任せるようなものである。 マネージャーは大きなプロジェクトの仕事をいくつかの小さな仕事に分けて、 スタッフおのおのに仕事の責任分担をするであろう。

同じように、 ある組織の管理しているドメインはいくつかのサブドメインに分けられる。 各サブドメインはそれぞれ別組織に委任することができるのである。 これによって、 委任された組織はそのサブドメインのすべてのデータの保守について責任を負う。 各組織で自由にデータを変更することもできるし、 そのサブドメインをさらにサブドメインに分けて仕事を委任することもできる。 親ドメインは単にそのサブドメインへのポインタだけを持っている。

ネームサーバ

ドメイン名空間についての情報を持つプログラムをネームサーバと呼ぶ。 普通、ネームサーバはドメイン名空間のある部分についての完全な情報を持っており、 その部分をゾーンと呼ぶ。 このとき、このネームサーバはそのゾーンについての権限(authority)を持っている、 と呼ぶ。 一つのネームサーバが複数のゾーンについての権限を持つことも、 もちろん可能である。

プライマリとセカンダリ

あるゾーンについての権限を持つネームサーバには2種類ある。 プライマリネームサーバとセカンダリネームサーバである。 プライマリネームサーバは、ゾーンの情報をファイルから読み込む。 セカンダリネームサーバは、権限を持つ他のネームサーバから、 ネットワーク経由でゾーン転送により情報を読み込む。

リゾルバ

ネームサーバにアクセスするクライアントをリゾルバと呼ぶ。

解決

ネームサーバは、ドメイン名空間の中で自分が権限を持っていない部分についても データを検索することができる。 このプロセスを名前の解決(resolution)と呼ぶ。

ルートネームサーバ

どのネームサーバも、 名前を解決するためにあらかじめ必要な情報はほんの少しである。 それはルートネームサーバのアドレスである。 ルートネームサーバはすべてのTLDについて、 権限を持っているネームサーバのアドレスを知っている。 ルートネームサーバに、あるドメイン名を問い合わせれば、 少なくともそのドメイン名が属するTLDについて、 その権限を持っているネームサーバのアドレスを教えてくれる。 次に、そのTLDについて権限を持っているネームサーバに問い合わせれば、 第2レベルドメインについて教えてくれる。 これを繰り返すことにより、名前の解決が実現する。

ルートネームサーバは世界に13個用意されている。 (DNSの技術的な制約により13個が最大である。) それらには、a.root-servers.net〜m.root-servers.net というわかりやすい名前が付けられている。ルートネームサーバのリストは ftp://rs.internic.net/domain/named.root にある。 ほとんどは、アメリカ国内に存在するが、うち1個は日本にあり、 WIDEにより運用されている。

逆引き

通常の名前の解決は、ドメイン名を与えて、 対応する(数字の)IPアドレスを聞き出すものである。 では、IPアドレスの方が分かっているときに、 対応するドメイン名を知りたいときはどうすればよいだろうか? これは、ログの出力を(人間にとって)見やすくしたり、 ある種の認証(authentication)を行なおうとするときに必要となる。

一つのアプローチは、DNSの全データを探索することである。 しかし、これはHOSTS.TXTの時代には可能であったろうが、 今となってはもちろん実行不可能である。

非常に巧妙な仕組みが考え出された。 ドメイン名空間の中に、 IPアドレスを名前として用いる部分空間をつくってしまうのである。 これがin-addr.arpaドメインである。 例えば、IPアドレス1.2.3.4は4.3.2.1.in-addr.arpaとなる。 逆順に並べることにより、各レベルでの委任が可能になるのである。 実に見事な仕組みである。

キャッシュ

ネームサーバは名前の解決にあたって入手したデータを すぐには捨てずに一定時間保存しておく。 どのゾーンについても権限を持たず、 もっぱらリゾルバからの問い合わせに答えることだけが仕事の ネームサーバも存在する。 このようなネームサーバをキャッシュオンリーネームサーバと呼ぶ。

リソースレコード

A
Address
CNAME
Canonical Name
MX
Mail eXchanger
NS
Name Server
PTR
PoinTeR

Virtual Domain

ドメイン名システムのツリー構造は、 実際のリンクがどのようにつながっているかという接続トポロジーとは、 まったく独立に構成できる。 この意味において、ドメイン名システムはヴァーチャルなものであると言える。 IPアドレス空間とドメイン名空間とはまったく独立なのであるから、 あるIPアドレスにどんなドメイン名を関連付けようと、 まったく自由である。

ただし、1台のホストに、 複数のドメイン名を関連付けて動かそうとした場合は、 少々工夫が必要になる。 Webサーバの場合は、2つの方法がある。 1つは、1台のホストに複数のIPアドレスを割り振ってしまう方法、 もう1つは、CNAMEレコードを使う方法である。 メールサーバの場合は、複数のMXレコードを定義しておき、 SMTPデーモンの設定ファイルを適切に記述することにより実現できる。

2. JPドメイン名

JUNET

1984年頃に実験が開始されたJUNET (Japan Unix/University NETwork)では、 当初からドメイン名によるアドレス表記をサポートしていた。 実は、当時のJUNETはTCP/IPによる通信ではなく、 主にUUCP (Unix to Unix CoPy)というプロトコルを使うネットワークであった。 そのため、上に述べたドメイン名システムの枠組とは少々事情が異なるが、 とにもかくにも、世界に先駆けて最初からドメイン名を導入した先見性は 評価されてしかるべきであろう。

JUNETではTLDとしてjunetを使用していた。 すなわち、keio.junet,titech.junet,u-tokyo.junetなどがJUNET誕生の頃の ドメイン名である。

1989年、国際的な枠組に合わせるため、 TLDをISO3166の2文字コードであるjpとする変更が大々的に行なわれた。 その際、従来の第2レベルドメインを第3レベルとし、 第2レベルには新たに属性ドメインとして2文字を追加することになった。

属性ドメイン

当初の属性の種類は、次の5つであった。 それぞれが3文字TLDにおける、edu,net,com,gov,orgにおおまかに対応する。

属性ドメインを3文字にしなかった理由は、 3文字TLDとの対応はあくまでおおまかななものであって、 一対一に対応するわけではないので、誤解を避けたかったということが一つ、 もう一つが、第2レベルを2文字にすると、xx.jpが元のjunetと同じ5文字 になるので具合が良い、というウソのような本当の話である。

第3レベル一意性要件

ドメイン名システムの枠組から考えて、第2レベルが増えたのであるから、 JPドメイン全体として名前空間が広がったことになる。 すなわち、第2レベルが異なれば、第3レベルが同一であっても、 ドメイン名としては衝突しないのであるから、OKのはずである。 しかし、当時はこれを認めないことにしたのである。 この制限は後に第3レベル一意性要件と呼ばれるようになる。 たとえば京王帝都電鉄株式会社がkeio.co.jpを取りたくても、 すでに慶應義塾大学がkeio.ac.jpを使用しているため不可とされたのである。

では、なぜ、名前空間が広がるせっかくの機会を利用せず、 わざわざ第3レベル一意性要件を設けたのであろうか? これは簡単、もし第2レベルの属性ドメインをやめることになっても、 大丈夫なように、という単純な理由である。 しかし、一度できてしまったものやルールはなかなかに変えられないのである。

NTT.JP問題

さて、junetから属性付きのjpへの変更は、わりあいとスムーズにすすんだが、 問題も発生した。 日本のいくつかの組織は、 すでにCSNETなどでアメリカとのに間に直のリンクを持っており、 そこで使用していたのが属性なしのjpドメインだったのである。 いくつかの組織とはNTT、KEK(高エネルギー研究所)、SONYなどである。 このうちSONYなどの民間企業の多くは、 国内のネットワークコミュニティに協調してco.jpへと移行した。 しかし、ntt.jp,nttdata.jp,kek.jpの3組織は、 属性付きへの移行を実施しなかったのである。 その後、ntt.jp,nttdata.jpについては長い移行期間と膨大な費用を使って、 先頃属性付きへの移行が完了した。

junet-adminからJPNICへ

JUNET時代にはドメイン名の割り当てはjunet-adminと呼ばれるボランタリな グループが担当していた。 当時は、3文字のドメイン名は、よほど有名でない限り不可、 なんていう今では信じられないガイドラインが存在した。 もちろん、有名かそうでないかはメンバーの恣意的な判断によっていたのである。

こうした状況から脱皮するために、 JCRN (Japan Committee for Research Network) を母体として、 1991年12月、日本ネットワークインフォメーションセンター (Japan Network Information Center、略称 JNIC)が結成された。 さらに、1993年3月、独立した団体として新たにJPNICが発足した。 そして、1997年3月、社団法人となったのである。

JPNICにおいては、 運営委員会やドメイン名割り当て検討グループ(DOM-WG)などの活動は、 依然としてボランタリな性格を色濃く残してはいるものの、 大筋としては、きちんと給料をもらっている正職員による組織だった業務遂行へと 変化している。

地域型ドメインの導入

1993年、主に個人や地域密着型組織を収容することを目的として、 地域型ドメイン名が導入された。 第2レベルに都道府県および政令指定都市を割り当て、 第3レベルに市町村名を入れ、 第4レベルを実際の対象に割り当てる方式である。

当初、実験として導入されたが、一度導入してしまったら、 なかったことにはそうそうできないのである。 現在では正式なものとなっている。

第2レベルの文字列は、JPNICによって指定されているが、 第3レベルについては、オンデマンドで対応している。 全国の市町村は高々3,000ほどしかないのであるから、 あるとき一斉に文字列を確定してしまえばいい、 と筆者はことあるごとに主張しているが、いまだ受け入れられていない。

さらに、JUNET時代からnagano.ac.jpやibaraki.ac.jpが存在していたので、 地域型ドメインを導入したことによって、 もはや属性ドメインの廃止は不可能になった。 したがって、第3レベル一意性要件は意味を持たなくなったのであり、 早急に撤廃すべきであったが、それには1996年末まで時間がかかった。

NEドメインの導入

1992年、WIDEのアクティビティの一つとして、当時のパソコン通信大手3者、 すなわちアスキーネット:-)、NIFTY-Serve(当時はどういうつづりだったかな?)、 PC-VANの接続が検討された。 属性ドメインをどうするかが、大きな問題の一つであったが、 結局 or.jp に落ち着いた。 これは、パソコン通信の会員の集合を一つの団体とみなすことができる、 というある種こじつけ的な意味付けによるものであった。 当時、or.jp は非営利団体のためのもの、というイメージが強く、 相当な違和感があった。 しかし、それはイメージが間違っており、 当初から or.jp の定義は非営利団体ではなく、「その他」の団体だったのである。 とはいうものの、「商用」パソコン通信という連想から、 当時niftyserve.co.jpあてのエラーメールがずいぶんと目撃されたものである。

1996年5月、JPNIC総会後の会場において、 ネットワークサービスのための新たな属性として、 netドメインの導入が検討されていることが発表された。

8月、ドメイン名に関わる諸問題を議論するためのメーリングリスト domain-talkがスタートした。 domain-talkの最大の特徴は、望めば誰でもが参加できるオープンな場である、 という点に尽きる。 当初、domain-talkはどこかの国の行政における公聴会のように、 一般の意見も聴きました、というポーズを作るためのものではないか、 という批判もあったが、筆者はその批判はあたらないと思っている。

domain-talkにおいて、ある発言者が、netドメインではなく、 neドメインがいいと言い出し、なぜかこれに決まってしまった。 netなら「ネット」と発音しやすいのに、 neだと「エヌイー」とどうも舌足らずな感じである。 結果的には、頭の2文字を機械的に切り出す、 という方針がこのときに定まった。

12月、neドメインが導入された。 orドメインからの移行には1997年3月まで特別措置が取られた。 orドメインとの並行利用は1999年3月までである。

GRドメインの導入

「その他」の属性orドメインの整理はさらに進められることになった。 従来、任意団体は最高裁の判例に基づき、権利能力なき社団として扱われきた。 権利能力なき社団とは、早い話が訴訟の対象になる実体を意味する。 権利能力なき社団の要件としては、きちんとした会則、多数決の原則、 代表者が交代しても団体が存続する、などがある。

社団法人などの法人格を持つ団体と、 法人格を持たない任意団体とを別の属性に分けよう、 という提案があり、議論やアンケートを経て、 grドメインの新設が決定され、1997年12月から実施された。

JPドメイン名におけるabuse例

新潟県におけるJPドメイン名例

教育用ドメインの検討

主に教育関係者から、教育用ドメインが欲しいという要望が多く出されている。 アンケートやdomain-talkでの熱い議論を経て、 1998年6月、JPNICからedドメインの新設が提案された。 しかし、なおも賛否その他の議論が続いている。

ブランドドメインの検討

商用利用ニーズの高まりにより、 ブランドドメインの導入が検討されている。 しかし、あまり進展はない。

イベントドメインの検討

単期間のイベント用のドメインが欲しいという声がある。 しかし、これもあまり進展がない。

個人用ドメインの検討

個人を収容するドメインが欲しいという声がある。 議論は行なわれており、WIDEのWGによる研究も進められているが、 いまだ具体化はしていない。

業種別ドメインの検討

第2レベルに業種名を持ってくる方式が、何人かから出されている。 筆者には大変魅力的に思えるが、さして進展はない。

ドメイン名に対する課金

旧JUNETでは、会費も手数料も存在しなかった。 しかし、NICを運営するにはどうしたってコストがかかる。 JNICが発足するにあたって、そのコストをどうやってまかなうかが問題となった。 当時、インターネットに参加する各サイトから直接会費を徴収することは、 とても不可能なことと思われた。 それだけの手間暇をかける体制をすぐには作れないからである。

そこで、各サイト単体ではなく、 WIDEやSINETといったネットワークプロジェクト単位で会費を集めることになった。 すなわち、ネットワークプロジェクトはJPNICの会員となり会費を納める、 各サイトは所属するJPNIC会員に対し何らかの形で費用を支払うのである。 これが、ドメイン名維持管理料に相当するが、あくまでも相当するだけであって、 JPNIC的にはドメイン名維持管理料なるものは存在しない。

しかし、今となっては、直接徴収が不可能とはとても思えない。 そろそろJPNICの収支構造そのものに、 大きなメスを入れる時期が来ているのでなかろうか?

JPNIC用語としての「接続」

あるJPドメイン名が有効に機能するためには、 JPドメインに関して権限を持つネームサーバ上に NSレコードが登録されていなければならない。 JPドメインに関して権限を持つネームサーバを管理しているのは、 もちろんJPNICである。 では、JPNICはどのような条件で、ネームサーバへの登録を行なうのであろうか?

ドメイン名登録手数料を支払ったとき? 否、登録手数料は単にそのドメイン名の一意性が保証されるためのものである。 正解は、いずれかのJPNIC会員がそのJPドメイン名に対して 「接続」を承認したときなのである。 この「接続」は、必ずしも回線がつながったり、サーバが動いたり、 ということを意味しない。 単に「接続」承認という手続きが必要なのである。 JPNIC会員が納めるべきJPNIC会費の額は、 この接続承認を行なったドメイン名の数に比例する、というわけである。

なんともわかりにくいシステムである。 特に「接続」という用語が誤解を招きやすい。 筆者は「接続」に代わる用語を使用しようという提案をしているが、 いいネーミングがなかなか見つからない。 たとえば、「オンネット (on net)」「オフネット (off net)」 というのはどうであろうか?

ドメイン名登録規則の整備

JNIC発足以来、ドメイン名登録規則は、加筆修正を繰り返してきたが、 その過程で誤謬や矛盾が入り込んでしまったり、 そもそも技術者の書いた文章なので、わかりにくいという問題点があった。 ようやく最近になって、法律の専門家をまじえての大幅な見直しが行なわれた。 現在のものはかなり改善されている。

3. gTLD

InterNIC

com,org,netなどのドメイン名の登録業務は、 SRI-NICからInterNICへと引き継がれた。 InterNICはNSF (National Science Foundation)との契約により、 データベース部門をAT&Tが、登録業務部門をNSI (Network Solutions社)が、 それぞれ委託運用を行なってきた。

1995年9月、それまで無料であったドメイン名登録に対して、 今日から手数料の徴収を開始する、とのアナウンスが突如行なわれた。 事前予告なしだったのは、駆け込みを防ぐためであったと言われる。 初回の手数料は、$100であり、これが2年分の維持料に充当される。 3年目からは毎年$50である。 この時点ですでに登録済みであったドメイン名に対しては、 最初から$50が請求される。

噴出する諸問題

1995年といえば、 インターネットの商用利用が爆発的に広がりつつあった年である。 1年に数十万の規模で新たなドメイン名が登録されるのであるから、 これを一企業が独占するのはきわめておいしいビジネスと言える。 当然、司法省による調査が始まり、また他の企業からの訴訟も相次いだ。 また、知的所有権(商標)にからむ訴訟、紛争も次々と起きるようになった。 さらに、 商用利用に適するcomドメインへの集中は「ドッと混む問題」とも揶揄された。

InterNICの独占に反対して、 独自にルートネームサーバを立ち上げ、 勝手にドメイン名を割り当てるAlterNICなども現れた。

John Postel氏の提案

1996年、 John Postel氏が新しいTLDを作ることに関するインターネットドラフトを発表した。 その内容は、初年度50の登録組織に対して合計150の新TLDを割り当てる、 というものであった。 この提案はインターネットコミュニティの間で議論を呼んだものの、 提案以上の進展には至らなかった。

IAHC

1996年10月、IAHC (International Ad Hoc Committee) が発足した。 IAHCのメンバー構成は、 であった。日本からは村井純氏が参加した。 誰でも参加できるメーリングリストを開設され、 そこにはわずかな間に4,000通以上ものメールが飛び交った。

gTLD-MoU

何度かのドラフト公開を経て、1997年2月、IAHCは勧告を発表した。 これは、gTLD-MoU (generic Top Level Domain - Memorandum of Understanding) と名付けられた。 gTLD-MoUでは、初年度において次の7つのgTLDを新設することとした。 gTLD-MoUは、世界中の組織が署名をし、ITUが保管することによって、 効力を持とうという考えである。 この考えに賛同した200以上の組織が署名を済ませている。

レジストラ

1997年7月、登録を行なう組織であるレジストラの公募が始まった。 当初、レジストラの数は全世界で28を上限とし、 超える応募があった場合には抽選とすることになっていたが、 これはインターネットコミュニティからの強い反発を招き、 結局、一定の資格要件を満たしてさえいれば、OKということになった。

全部で88の組織がレジストラとして決定した。 日本からは、国際調達情報、アーク、東京インターネット、 の3組織が決定した。 アメリカが25組織ともっとも多く、次いでドイツが13組織である。 これは、ドイツのNICの登録手数料がやたらに高いのが一因らしい。 ちなみに、AlterNICは含まれていない。

CORE

レジストラは、地球規模に分散してサービスを競い合う。 そのレジストラの代表で組織するのが CORE (Council Of REgistrars) である。 この他に POC (Policy Oversight Committee)、 PAB (Policy Advisory Body)、 ACPs (Administrative Challenge Panels) などの組織がある。

SRS

各レジストラは、どのgTLDについても登録業務を行なえる。 そのためにデータベースを共有しなければならないが、 これが SRS (Shared Registry System) である。 1997年11月、COREはSRSの開発をEmergent社に委託した。

ずれ込みながらもスタート?!

こうして、CORE-gTLDのスタートは目前に迫った。 加えて、NSFからInterNICへの委託契約は1998年3月末に切れることが決定していた。 気の早いレジストラおよびその代理店は、 先行予約をせっせと受け付け始めた。 ドメイン名新時代の幕開けが近付いたのである。

4. インターネットガバナンス

グリーンペーパー

1998年1月30日、アメリカ商務省電気通信情報庁は 「インターネットの名前及びアドレスの技術的管理の改善についての提案」 (通称 グリーンペーパー ) を、突然発表した。 その内容は、インターネットコミュニティには驚くべきものであった。 そこには、IAHCやgTLD-MoUのことがまったく一言も触れられていなかったのである。

では、内容もまったく関係がなかったかと言えばそうではない。 gTLDの新設、レジストラの概念、紛争解決のための手段、などなど、 かなりgTLD-MoUと似通った内容が含まれていた。 にもかかわらず、一切言及しない、つまり意図的に無視したのである。

インターネットは誰のもの?

みんなで考えてみよう。

WorldNIC

一方、NSFからInterNICへの業務委託契約のうち、 ドメイン名登録業務に関するNSIへの委託は暫定的に1998年9月末までに延長された。 AT&Tへの委託の方は通り3月末で打ち切られた。 NSIはWorldNICのサービスを本格的に始めるなど、 ドメイン名登録ビジネスを手放す気はないようだ。

1998年4月、InterNICのドメイン名登録手数料が、初年度$100、 3年目からの$50が、それぞれ、$70と$35に値下げされた。 なぜ、こんな値下げが可能になったのだろうか? 実は、ドメイン名登録手数料のうち、$30と$15は、 インターネットのインフラを整備するための基金としてNSFが徴収していたのである。 契約の暫定延長に際して、この部分の支出は廃止されたので、 そっくりそのまま、手数料の値下げに反映することができたわけである。

しかし、こんな話、誰が把握していたのであろうか? 事実、アメリカ議会でさえも、 これは議会が承認していない違法な税金徴収にあたる、として怒ったのである。 基金の額は4,600万ドルに及ぶと言う。

ホワイトペーパー

1998年6月5日、グリーンペーパーに対して寄せられた多数のコメントを踏まえて、 最終案 (通称 ホワイトペーパー) が発表された。 グリーンペーパーのときの猛反発とは違い、 インターネットコミュニティはおおむね好意的に反応しているようである。

EUはさっそく7月7日に、ホワイトペーパーを受けての 会合 を開いた。 ISOCは7月下旬にジュネーブで開かれるINET'98の会期中に、 急遽 サミットを開催することを決定した。

どうやら、IANAが改組される方向で、この問題は一応の決着がつきそうである。 もっとも、それですべての問題が解決されるはずもなく、 この先どうなるかは、まったく予断を許さないのではあるが。

郵政省の研究会

1998年3月から、 郵政省において「インターネット・ドメインネームに関する研究会」が5回に わたって開催され、その成果が7月7日に報告書としてまとめられた。 報告書は間もなくWebサイトでも閲覧可能になる予定とのことである。

A. 付録