- + はじめに
- + 第1章 資源管理とレジストリ
- + 第2章 JNIC発足前の資源管理とJPNICの設立
- + 第3章 JPNICによる資源管理への本格的な体制整備
- + 第4章 ドメイン名における資源管理方針の変遷
- + 第5章 本格的インターネット時代のIPアドレスポリシー
- + 第6章 グローバルなIPアドレス管理体制の確立へ
- + 第7章 ICANNによるグローバルなドメイン名管理体制
- + 第8章 汎用JPドメイン名とJPRSの設立
- + 第9章 登録情報の「公開」と「開示」
- + 第10章 IPv4アドレス在庫枯渇とIPv6
- + 付録1:IPアドレスとドメイン名の説明
- + 付録2:インターネット資源管理の変遷
- + 歴史編纂チームについて
- + 修正履歴
第1章 資源管理とレジストリ
インターネットは、地球上のさまざまなコンピュータを接続し、 今ではスマートフォン・タブレットなどに代表されるモバイルターミナルをも併せて接続する、 地球規模のグローバルなコンピュータネットワークとして急速に発展しました。 このように急速な発展を遂げた理由には、本質の一つとして、 インターネットが全体を集中的に管理しない、 「自律分散管理」を基本とするシステムであったことが挙げられます。
しかし、 インターネットに接続されたそれぞれのネットワークやコンピュータを識別するための「番号」や「名前」の管理はその例外で、 インターネット全体で集中的・統一的に管理されています。
IPアドレス[1]やAS番号[2]、 ドメイン名[3]は、 対象となるネットワークやコンピュータを、 インターネット上で一意に識別するための識別子であり、 一元的な管理を実現するためには、 インターネット全体で集中的・統一的に管理された機構が必要になるからです。
集中的・統一的な管理と言っても、 それが一か所で管理されているということではありません。 インターネットの拡大の中で、 スケーラビリティの確保とローカルポリシー運営のために階層的管理構造が「委任(delegation)」という仕組みで形成されています。 委任は、ドメイン名やIPアドレスの管理のうちの一部分を、 別の管理者に委ねる仕組みです。
そしてこのような、 インターネット上の番号や名前の割り当て・登録を担当する組織のことを「レジストリ(登録管理機関)」と呼びます。 現在のインターネットの管理構造につながる世界初のレジストリは、 スタンフォード研究所(Stanford Research Institute; SRI)のネットワークインフォメーションセンター(SRI-NIC、 エスアールアイ・ニック)が担当していました。 そのため、組織名称として「NIC(Network Information Center、 ニック)」を使用しているレジストリが現在も数多く存在しています。
JPNICは、 日本においてIPアドレスやAS番号を管理するインターネットレジストリです。 JPNICは、日本の国コードトップレベルドメイン(Country Code Top Level Domain; ccTLD、シーシーティーエルディー)である、 JPドメイン名のレジストリも担当していましたが、 その業務は2002年4月に株式会社日本レジストリサービス(JPRS)が引き継ぎ、 現在に至っています。
JPNICやJPRSは、グローバルにIPアドレスやドメイン名を管理する、 Internet Corporation for Assigned Names and Numbers (ICANN、アイキャン)を頂点とした管理機構の一部として、 それぞれの管理業務を担当しています。 この章では、 「IPアドレスとドメイン名のそもそもの違い」を述べるとともに、 「レジストリの役割」をまとめます。
IPアドレスとドメイン名の管理の違い
IPアドレスとドメイン名の資源管理の歴史を振り返る前に、 資源管理という立場から見たIPアドレスとドメイン名の違いについて、 改めて解説します。 この違いから、同じ資源管理と言っても、 IPアドレスとドメイン名では資源の性格が異なっていて、 それにより業務もおのずと異なったものになるということを説明します。
IPアドレスは、IPv4の場合32ビット、 IPv6の場合128ビットの固定長ビット列(数値)によって表される値で、 インターネット上のホストにそれぞれ異なった値を割り当てることで、 インターネット上のホストを識別します。 IPアドレスはネットワークを識別する「ネットワーク部」と、 そのネットワーク内のホストを識別する「ホスト部」と呼ばれる、 二つの部分に分けられます。
IPにおける通信では、パケットは複数のルーターを経由して、 送信元から送信先に送られます。 各ルーターは、 パケットの送信先のIPアドレスのネットワーク部を参照し、 パケットの送り先(次のルータ)を決定します。 IPアドレスはビット列のため高速かつ効率的に処理ができ、 コンピュータ処置に適したアドレスであると言えます。
一方、 ドメイン名はラベルをドットで連結した「文字列」によってホストを識別する、 人間にとって認識しやすい識別子であり、その文字列から、 組織、サービス、商品や情報などがある程度類推できます。 ドメイン名は、各ラベルによって階層的に管理されます。
一般的にユーザーは、ドメイン名を用いて相手先を指定しますが、 実際のパケットのやりとりではIPアドレスが識別子として用いられるため、 実際に通信する際にはドメイン名に対応するIPアドレスを知る必要があります。 また逆に、アクセス元を調査する場合など、 IPアドレスからドメイン名を知りたい場合もあります。 このドメイン名とIPアドレスの対応を管理しているのがDNS (Domain Name System)[4]であり、 DNSは、ドメイン名に対応するIPアドレスを見つけたり、 IPアドレスからドメイン名を示したりしてくれます。
そして、 ドメイン名をIPアドレスに変換するための正引きDNSサーバを運用しているのが「ドメイン名レジストリ」で、 IPアドレスからドメイン名に変換するための逆引きDNSサーバを運用しているのが「IPアドレスレジストリ」です。 各レジストリは管理対象となるDNSの情報を管理し、 DNSサーバを運用します。 このDNSもラベルによって階層的に管理されています。
また、IPアドレスとドメイン名には、それが単にビット列か、 文字列かという違いだけでなく、 ネットワークの構造に依存しているかいないかという大きな違いがあります。
IPアドレスは前述の通り「ネットワーク部」と「ホスト部」によって構成されていますが、 接続されているISPなど、 上位のネットワークが変更になることによってネットワーク部のアドレスが変更になる場合があり、 結果としてすべての機器のIPアドレスが変更されることになります(これをリナンバリングと呼びます)。
一方、ドメイン名は、ネットワークの構造に依存しません。 つまり、接続させているネットワークを変えたり(構成変更)、 ISPを変えたりしても、 DNSの設定を変えることで同じ名前を使い続けることができるという、 ポータブルな性質があります。
グローバルなインターネットにおいては、 現在も接続しているネットワークのあちこちで頻繁に構成変更が行われ、 その都度リナンバリングも行われています。 しかし、ドメイン名に関しては、 DNSにおいて対応するホストのアドレスやネームサーバホストを新しいIPアドレスに更新することによって、 ユーザーはこれまで通り、特段の設定変更等を行うことなく、 同じドメイン名のホストに対して引き続きアクセスすることができます。
IPアドレスレジストリの業務
IPアドレスは前述の通り、IPv4の場合32ビット、 IPv6の場合128ビットの数値によって表される値です。 番号自体は通常、「文字としての意味」は持たないため、 ドメイン名のように意味の差異がない均質な資源の分配となり、 文字列が競合・衝突するような競争的な側面も持ちません。 しかし、使用可能なIPアドレスは有限であるため、 効率的な利用や時に節約的な側面も必要となります。 そのため、 必要な人が必要な分を使うという公平性が重んじられています。 また、IPアドレス、ドメイン名ともに、 インターネット上のホストを識別するものであることから、 重複なく一意に関係付けられなければなりません。 こうした調整を行うのが、「レジストリ」の基本的な役割です。
レジストリの一般的な役割については後述しますが、ここでは、 IPアドレスの特性を活かすための「IPアドレスレジストリの業務」についてまとめます。
IPアドレスレジストリは、 未分配のIPアドレス空間と分配済みのIPアドレスの両方を、 「一意性」「登録」「経路集成」「節約」「公平性」という五つの原則に従って管理しています。 IPアドレスの分配にあたっては、 申請者からIPアドレスの利用計画を提示してもらい、 「経路集成」「節約」などといった管理原則に則った運用が行われるか、 希望するIPアドレスの数が適切かなどをあらかじめ審査し、 必要な分配量を決定します。 そして、分配したアドレスをデータベースに登録管理することにより、 そのアドレスの一意性を保証します。
IPアドレスは、世界的に共通の未分配空間から、 五つの地域レジストリによって階層的に分配されます。 地域によっては、 さらに国別のレジストリが存在する場合もありますが、 どのレジストリにおいても、 分配はほぼ同一の基準によって行われます。 各レジストリの関係は、競合ではなく、 むしろ均質性を担保するための協調関係にあります。 各レジストリにおける分配管理ルール(ポリシー)策定や運用は、 それぞれの地域やコミュニティの状況に合わせた独自のものとなっていますが、 グローバルな公平性を確保するために、 政策的な面よりも技術的な観点を重視し、 できる限り統一的なものに調整されます。
そして、IPアドレスの分配には、 人手による適切な事前審査が必要です。 IPアドレスレジストリは申請を受け取ると、 添付された利用計画を精査し、 希望する量がルールに従って適切であると確認した後に分配を行います。 分配のルールは、使用可能なIPアドレスが有限であることから、 必要な量に制限し、 不要なアドレスは分配しないことが原則となっています。
そのため、分配のためのポリシー策定は、 レジストリが関わるコミュニティからのボトムアップのアプローチを経て、 誰でも議論に参加できるオープンな場において、 公平であるか等の観点から、 コミュニティ全体のコンセンサスを得た上で進められることが原則となっています。 このようなルール策定および調整の場を提供し、 ルール策定を行うことも、 IPアドレスレジストリの重要な役割となります。
ドメイン名の文字列としての価値
ドメイン名レジストリの業務を説明する前に、 ドメイン名の「文字列としての特性」を最初に整理します。
数値であるIPアドレスの管理が有限資源の分配という色が強いのに対して、 ドメイン名の文字の組み合わせは事実上無限に近いと言えます。 その一方で、IPアドレスは数値で意味はあまり持たないのに対して、 ドメイン名は文字列であり、 ユーザーにとって実社会に存在するものを連想させたり意味を持ったりするため、 そのための配慮が必要となります。
人間は、ドメイン名の文字列から商標、 商号や個人名などの固有名詞や、 利用可能なサービスの名前などを連想します。 また、一般名詞や地域名などを利用した、 ビジネス的な価値をもった文字列もあります。 それがユーザーから見たドメイン名の魅力です。
このように、 ビット列であるIPアドレスと違い文字列であるドメイン名は、 それ自体が市場的、社会的な価値を実社会で持つがゆえに、 価値のある文字列の奪い合いなどのトラブルや紛争を引き起こすことがあります。 また、スローガン、わいせつ語、差別語など、 言葉として社会的に公で使うのに不適切な語に対する対応に迫られたり、 ラベルの持つ言語的な意味に関し、 異体字や類似性も考慮した登録のルール作りが必要になります。
同じ文字列を希望する申請者に対する扱いを調整するには、 基本的には先着順、すなわち「早いもの勝ち」というのが原則です。 また、IPアドレスのように利用することが前提ではなく、 利用する予定はなくても、 その名前を第三者が利用できないようにするため、 防衛的に登録することも認められています。
このようにドメイン名に対しては、商標、 商号といった商標権や知的財産権を関連付けられる権利侵害などのトラブル、 似た文字列でインターネットユーザーの錯誤を引き起こし何らかの被害を与えるなりすまし、 フィッシングの可能性が考えられるため、 それらを事前または事後に解決する仕組み(後述する「サンライズピリオド」や「DRP」など)も必要となります。
ドメイン名レジストリの業務
ドメイン名レジストリは、 登録済みドメイン名の情報と登録者情報を管理しています。 ドメイン名を必要としているユーザーは、 希望するドメイン名としての文字列を決め、 ドメイン名レジストリに登録申請を行います。 レジストリは申請を受けると、登録ルールに合っているかを審査し、 その名前が未登録であることを確認した後、申請を受理し、 登録済みのドメインの情報としてレジストリデータベースに追加します。
ドメイン名は複数のラベルがドットで連結されることによって構成されています。 そして、ドメイン名レジストリは、それぞれのラベルごとに、 階層的に構成されています。 このため、登録ルールもそれぞれのドメイン名レジストリがユーザーや社会の要求に対応する形で独自に決めることができます。 また、ドメイン名のルールでは、IPアドレスのルールと比べて、 知的財産やその他の紛争/トラブル回避といった点が、 より重要となってきます。
一方で、登録できる文字列が豊富であることから、 IPアドレスのような節約指向はそれほど重視されていません。 IPアドレスは使う予定のないアドレスは分配されませんが、 ドメイン名の場合、商標や商号保護の目的など、 当該文字列を第三者が登録することを防ぐために、 利用の予定がなくても防衛的に登録しておくことも広く行われています。
IPアドレスの場合はその割り当ての可否が事前審査であるのに対し、 ドメイン名の場合、事前審査はその文字列が登録済みかどうか、 登録者が登録資格を有しているか等を判定する、 最低限度の審査にとどめるのが一般的です。 そのドメイン名が第三者の何らかの権利を侵害しているかどうかを、 登録時にすべて判断することは、 基本的には困難であることから、一般的には、 そのドメイン名が使われた際の使われ方については、 申し立てに応じた事後の対応となっています。
このような、商標等の紛争を事後に解決する手段として、 「ドメイン名紛争処理方針(Domain Name Dispute Resolution Policy; DRP、ディーアールピー)」と呼ばれる紛争解決のルールが定められています。 また、新たなドメイン名や属性などを設けるにあたっては、 先着順による登録の開始前に一定期間特別な期間を置き、 紛争を軽減化するために商標や商号を優先的に登録させる仕組みを導入する場合があります。 この期間を「優先登録期間(サンライズピリオド)」と呼びます。
その他、成りすましや、 不適切な情報発信が関係するドメイン名の扱いなど、 ドメイン名レジストリだけでは対応することが難しい問題に関しては、 関連組織と連携して対応する必要もあります。 ドメイン名レジストリにとっては、 このようないろいろな紛争やトラブルを事後処理するためのルールの策定や制度、 関係組織の連携体制を確立することが重要な業務となります。
ドメイン名の登録は基本的に先着順のため、 登録処理の即時性も期待されます。 また、申請数も、IPアドレスはブロック単位ですが、 ドメイン名は一つ一つとなり、IPアドレスに比べ多くなるため、 レジストリシステムにも処理性能が求められます。
さらに、ドメイン名レジストリは、 管理するドメイン名をインターネット上で利用可能にするための正引きDNSサーバを運用する必要があり、 このDNSサーバには高い安定性と信頼性、可用性が期待されます。 そのための設備投資も必要です。
IPアドレスレジストリはその分配ポリシーがグローバルに均等であり、 公平を原則とするため、 IPアドレスレジストリ間の競争にはなじまないことは述べましたが、 一方のドメイン名は、 その公正競争を確保するためにも「レジストリ・レジストラモデル」が採用されていることが多く、 公正競争によっても品質向上が求められます。 つまりユーザーはドメイン名を登録する際、 登録するレジストリやレジストラを選択できます。 希望するドメインが空いているか、TLDのイメージ、値段、 信頼性などのいろいろな視点で、 レジストリやレジストラを選択します。 ドメイン名レジストリは市場競争原理の中でサービスを提供しています。
特に、ICANNによる新gTLDの増加施策により(第7章参照)、 その競争はより激しくなり、 レジストリは品質やサービスの向上が必然的に求められます。
レジストリの役割
ここでは、レジストリの基本的な役割について整理します。
レジストリデータベースの運用管理
割り当てや登録情報を蓄積し管理する、 「レジストリデータベース」の運用・管理を担当します。
規則の制定
IPアドレス・AS番号の割り当てやドメイン名の登録に関する規則(+ポリシー、 細則)を策定します。
IPアドレス・AS番号に代表される番号資源の場合、 一つの番号空間が全世界で共有されることから、 グローバルな整合性が確保された規則を適用する必要があります。 そのため、 レジストリでは顧客に番号資源を割り当てるローカルインターネットレジストリ(Local Internet Registry; LIR、エルアイアール、 日本ではIPアドレス管理指定事業者)や、 上位レジストリ(JPNICの場合、Asia Pacific Information Centre; APNIC、エーピーニック)、コミュニティと協調しながら、 規則を策定しています。
ドメイン名も、 全世界で用いられる分野別トップレベルドメイン(Generic Top Level Domain; gTLD、 ジーティーエルディー)の規則はICANNの場で作られます。 国や地域に割り当てられる国コードトップレベルドメイン(Country Code Top Level Domain; ccTLD、シーシーティーエルディー)では、 グローバルルールはICANNの場で作られますが、 個々のサービスは各レジストリに委ねられており、 それぞれの国や地域のニーズに合ったルールが作られています。 「.jp」の場合は、 JPRSが日本のコミュニティの声やドメイン名市場のニーズ等を踏まえて策定しています。
申請の受け付け
IPアドレスやドメイン名の申請があった場合、規則に基づいて、 割り当てや登録を実施します。 また、申請内容に基づいて、 レジストリデータベースの内容を更新します。
WHOISサービスの提供
レジストリが管理するIPアドレスやドメイン名の登録者情報は、 WHOIS(フーイズ)と呼ばれるサービスにより、 インターネットユーザーが誰でも参照できる形で公開されます。 レジストリは、 自身が管理するレジストリデータベースとの整合性を確保する形でWHOISサービスを運営します。
1982年、RFC 812(NICNAME/WHOIS)[5]によって、 WHOISの技術情報や仕様・運用規則などが定められました(2004年に現在のRFC3912[6]に改版)。 JPドメイン名では、 1992年にJNIC(JPNICの前身)がWHOIS実験サービスを開始し、 1993年にJPNICが正式サービスを開始しました。 現在では、JPドメイン名はJPRS、IPアドレスはJPNICが、 それぞれのWHOISサービスを運営しています。
割り当て情報や登録情報をインターネットユーザー全体に公開することは、 レジストリの重要な役割です。 前述の通り、 インターネットは「自律分散管理」を基本とするシステムであるため、 インターネットには全体を統括管理する組織が存在しません。 もし、接続者間において何らかのトラブルが発生した場合は、 関係者が連絡を取り合い、 調整することで問題を解決するようになっています。 このためには、 特定のネットワークやドメイン名を管理・利用している組織や、 ユーザーとの確実な連絡が必須であり、 レジストリが運営するWHOISサービスは、 そのための連絡先情報の提供という重要な役割を担います。
このように、 WHOISサービスは技術的な問題が発生した場合の当事者間における連絡先情報の確保を目的として利用されてきました。 現在では、 セキュリティインシデントやドメイン名と商標などの関係に関わるトラブルの解決のために利用されるなど、 インターネットの利用の拡大とともに、 その使われ方も多様になってきています。
DNS - Domain Name System
DNS(ディーエヌエス)は、 IPアドレスとドメイン名の対応情報などを提供する、 インターネットにおける基本的なサービスの一つです。
JPNICでは、 分配された各IPアドレスブロックを管理する逆引きDNSサーバへの委任情報を、 APNICと共同で提供しています。 一方、JPRSでは、 登録された各ドメイン名を管理する正引きDNSサーバへの委任情報を提供しています。
インターネットの前身であるARPANET(Advanced Research Projects Agency Network、アーパネット)では、 接続機器を特定するホスト名とIPアドレスの対応表をHOSTS.TXTと呼ばれるファイルで管理し提供していました。 しかし、登録情報の増加や更新頻度の増大などの理由により、 1980年代初頭には既にこの仕組みは限界に達していました。 それを解決するために1983年にDNSの最初の仕様がRFC882[7]とRFC883[8]としてまとめられ、 1987年に現在の仕様であるRFC 1034[9]とRFC 1035[10]に改版されました。
日本では、 1989年にJPドメイン名を管理するためのDNSサーバ(JP DNSサーバ)の運用が始まりました。 その後、JP DNSサーバの運用はJPRSへ引き継がれ、 インターネットの広がりとともに増強されてきました。 2014年現在、JP DNSサーバは、 セカンダリサーバ運用組織の協力も得ながら全世界の26拠点で運用されています。
DNSには数多くの機能付加や改良が行われました。 中でも特に重要なものとして、 DNSのセキリュリティ拡張機能であるDNSSEC(ディーエヌエスセック)[11]の基本仕様が、 2005年にRFC 4033[12]、4034[13]および4035[14]として標準化されました。
情報発信・教育啓発活動
円滑な資源管理のために必要なインターネット基盤技術、 ガバナンスなどの分野における情報提供や教育啓発活動などにより、 全体的なレベルアップやリテラシーの向上を図ることは、 多くのレジストリが自らの役割ととらえ、実践しています。
JPNICも同様な考え方から、ニュースレター、メーリングリスト、 メールマガジン、Webサイトなどのメディアを通じ、 情報発信を積極的に行っています。
特に、インターネット技術者が中心に集う「Internet Week」は、 1997年に第1回が開催された後、 1999年からはJPNICの主催により毎年開催しています。 Internet Weekの起源は、 その時点における日本のインターネットの状況を総覧するための「IP Meeting」に求めることができます。 最初のIP Meeting(当時は「日本インターネットワークミーティング」という名称で開催)は、 1990年に慶應義塾大学湘南藤沢キャンパス(SFC)で開催されました。
←はじめに | Ver.1.0-2014年11月17日 | 第2章→ |
[1] https://www.nic.ad.jp/ja/tech/glos-ij.html#02-IPadoresu
[2] https://www.nic.ad.jp/ja/tech/glos-ah.html#01-ASbangou
[3] https://www.nic.ad.jp/ja/tech/glos-ta.html#14-domeinmei
[4] https://www.nic.ad.jp/ja/tech/glos-ah.html#01-DNS
[5]
Ken Harrenstien, Vic White, "NICNAME/WHOIS", RFC 812,
Network Information Center, SRI International, 1 March 1982
http://www.ietf.org/rfc/rfc812.txt
[6]
L. Daigle, VeriSign, Inc., "WHOIS Protocol
Specification", RFC 3912, September 2004
http://www.ietf.org/rfc/rfc3912.txt
[7]
P. Mockapetris, ISI, "DOMAIN NAMES - CONCEPTS and
FACILITIES", RFC 882, November 1983
http://www.ietf.org/rfc/rfc882.txt
[8]
P. Mockapetris, ISI, "DOMAIN NAMES - IMPLEMENTATION
and SPECIFICATION", RFC 883, November 1983
http://www.ietf.org/rfc/rfc883.txt
[9]
P. Mockapetris, ISI, "DOMAIN NAMES - CONCEPTS AND
FACILITIES", RFC 1034, November 1987
http://www.ietf.org/rfc/rfc1034.txt
[10]
P. Mockapetris, ISI, "DOMAIN NAMES -
IMPLEMENTATION AND SPECIFICATION", RFC 1034, November 1987
http://www.ietf.org/rfc/rfc1035.txt
[11] https://www.nic.ad.jp/ja/tech/glos-ah.html#01-DNSSEC
[12]
R. Arends, R. Austein, M. Larson, D. Massey,
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005
http://www.ietf.org/rfc/rfc4033.txt
[13]
R. Arends, R. Austein, M. Larson, D. Massey,
S. Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005
http://www.ietf.org/rfc/rfc4034.txt
[14]
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005
http://www.ietf.org/rfc/rfc4035.txt