メインコンテンツまでスキップ

2. はじめに (Introduction)

このRFCは、ドメインスタイルの名前 (Domain Style Names)、インターネットメールおよびホストアドレスのサポートにおけるその使用、ドメイン名機能を実装するために使用されるプロトコルとサーバーについて紹介します。

2.1. ドメイン名の歴史 (The history of domain names)​

ドメインシステム開発の原動力は、インターネットの成長でした:

  • ホスト名からアドレスへのマッピング (Host name to address mappings) は、ネットワークインフォメーションセンター (Network Information Center, NIC) によって単一のファイル (HOSTS.TXT) で管理されており、すべてのホストがFTPで取得していました [RFC-952, RFC-953]。このスキームによる新しいバージョンの配布に消費される総ネットワーク帯域幅は、ネットワーク内のホスト数の2乗に比例し、複数レベルのFTPが使用される場合でも、NICホストの送信FTP負荷はかなりのものでした。ホスト数の爆発的な成長は、将来にとって良い兆候ではありませんでした。

  • ネットワークの人口構成 (The network population) も変化していました。元のARPANETを構成していたタイムシェアリングホストは、ワークステーションのローカルネットワークに置き換えられていました。ローカル組織は独自の名前とアドレスを管理していましたが、HOSTS.TXTの変更がインターネット全体に反映されるためには、NICの変更を待たなければなりませんでした。組織は名前空間 (Name Space) に何らかのローカル構造も望んでいました。

  • インターネット上のアプリケーション (The applications) はより洗練されたものになり、汎用的な名前サービスの必要性が生じていました。

その結果、名前空間とその管理に関するいくつかのアイデアが生まれました [IEN-116, RFC-799, RFC-819, RFC-830]。提案は多様でしたが、共通のスレッドは階層的な名前空間のアイデアであり、階層は組織構造にほぼ対応し、名前は階層レベル間の境界を示す文字として "." を使用していました。分散データベースと汎用リソースを使用した設計が [RFC-882, RFC-883] で説明されました。いくつかの実装での経験に基づいて、システムはこのメモで説明されているスキームに進化しました。

「ドメイン (Domain)」または「ドメイン名 (Domain Name)」という用語は、ここで説明されているDNSを超えた多くのコンテキストで使用されています。多くの場合、ドメイン名という用語は、ドットで示される構造を持つ名前を指すために使用されますが、DNSとは関係ありません。これはメールアドレッシングで特に顕著です [Quarterman 86]。

2.2. DNS設計目標 (DNS design goals)​

DNSの設計目標はその構造に影響を与えます。それらは以下の通りです:

  • 一貫した名前空間 (Consistent name space): 主な目標は、リソースを参照するために使用される一貫した名前空間です。アドホックなエンコーディングによって引き起こされる問題を回避するために、名前の一部としてネットワーク識別子、アドレス、ルート、または同様の情報を含むことを要求すべきではありません。

  • 分散管理 (Distributed maintenance): データベースの膨大なサイズと更新の頻度は、パフォーマンスを向上させるためにローカルキャッシュを使用して、分散方式で管理する必要があることを示唆しています。データベース全体の一貫したコピーを収集しようとするアプローチは、ますます高価で困難になり、したがって避けるべきです。同じ原則が名前空間の構造、特に名前の作成と削除のメカニズムにも当てはまります。これらも分散されるべきです。

  • ソースによるトレードオフの制御 (Source control of tradeoffs): データの取得コスト、更新の速度、キャッシュの精度の間にトレードオフがある場合、データのソースがトレードオフを制御する必要があります。

  • 汎用性 (General utility): このような機能を実装するコストは、単一のアプリケーションに制限されず、一般的に有用であることを要求しています。ホストアドレス、メールボックスデータ、その他未定の情報を取得するために名前を使用できる必要があります。名前に関連付けられたすべてのデータは型でタグ付けされ、クエリは単一の型に制限できます。

  • プロトコル独立性 (Protocol independence): 異なるネットワークやアプリケーションで名前空間を有用にしたいため、異なるプロトコルファミリーまたは管理で同じ名前空間を使用する機能を提供します。たとえば、ホストアドレスの形式はプロトコル間で異なりますが、すべてのプロトコルにはアドレスの概念があります。DNSは、型だけでなくクラスでもすべてのデータをタグ付けするため、アドレス型のデータに対して異なる形式を並列使用できます。

  • トランスポート独立性 (Transport independence): 名前サーバートランザクションを、それらを伝送する通信システムから独立させたいと考えています。一部のシステムは、クエリと応答にデータグラムを使用し、信頼性を必要とするトランザクション（例: データベース更新、長いトランザクション）にのみ仮想回線を確立することを望む場合があります。他のシステムは仮想回線のみを使用します。

  • 広範なホスト機能範囲 (Wide host capability range): システムは、幅広いホスト機能で有用である必要があります。パーソナルコンピューターと大規模なタイムシェアリングホストの両方がシステムを使用できる必要がありますが、おそらく異なる方法で使用されます。

2.3. 使用に関する仮定 (Assumptions about usage)​

ドメインシステムの構成は、ユーザーコミュニティのニーズと使用パターンに関するいくつかの仮定から導き出され、汎用データベースシステムに見られる多くの複雑な問題を回避するように設計されています。

仮定は以下の通りです:

  • データベースサイズ (Database size): 総データベースのサイズは、最初はシステムを使用するホストの数に比例しますが、最終的には、メールボックスやその他の情報がドメインシステムに追加されるにつれて、それらのホスト上のユーザー数に比例して増加します。

  • 更新頻度 (Update frequency): システム内のほとんどのデータは非常にゆっくりと変化します（例: メールボックスバインディング、ホストアドレス）が、システムはより迅速に変化するサブセット（秒または分のオーダー）を処理できる必要があります。

  • 管理境界 (Administrative boundaries): データベースの責任を分散するために使用される管理境界は、通常、1つ以上のホストを持つ組織に対応します。特定のドメインセットに責任を持つ各組織は、組織自身のホストまたは組織が使用するように手配した他のホスト上で、冗長な名前サーバーを提供します。

  • 信頼できるサーバー (Trusted servers): ドメインシステムのクライアントは、この「信頼できる」セット外の名前サーバーへの参照を受け入れる前に、使用したい信頼できる名前サーバーを識別できる必要があります。

  • 可用性と一貫性 (Availability vs consistency): 情報へのアクセスは、瞬時の更新や一貫性の保証よりも重要です。したがって、更新プロセスは、すべてのコピーが同時に更新されることを保証するのではなく、ドメインシステムのユーザーを通じて更新が浸透することを許可します。ネットワークまたはホストの障害により更新が利用できない場合、通常のコースは、更新を続けながら古い情報を信じることです。一般的なモデルは、更新のためのタイムアウトでコピーが配布されることです。ディストリビューターはタイムアウト値を設定し、配布の受信者は更新を実行する責任があります。特別な状況では、非常に短い間隔を指定するか、所有者がコピーを禁止できます。

  • クエリ解決アプローチ (Query resolution approaches): 分散データベースを持つシステムでは、特定の名前サーバーが他のサーバーでしか答えられないクエリを提示される場合があります。この問題に対処する2つの一般的なアプローチは、「再帰的 (Recursive)」（最初のサーバーが別のサーバーでクライアントのクエリを追跡する）と「反復的 (Iterative)」（サーバーがクライアントを別のサーバーに参照し、クライアントがクエリを追跡する）です。両方のアプローチには利点と欠点がありますが、データグラムスタイルのアクセスには反復的アプローチが好まれます。ドメインシステムは反復的アプローチの実装を要求しますが、オプションとして再帰的アプローチを許可します。

データの起源と管理 (Data origin and management)​

ドメインシステムは、すべてのデータがドメインシステムを使用するホストに散在するマスターファイル (Master Files) に由来することを前提としています。これらのマスターファイルは、ローカルシステム管理者によって更新されます。マスターファイルは、ローカル名前サーバーによって読み取られるテキストファイルであり、したがって名前サーバーを通じてドメインシステムのユーザーが利用できるようになります。ユーザープログラムは、リゾルバー (Resolvers) と呼ばれる標準プログラムを通じて名前サーバーにアクセスします。

マスターファイルの標準形式により、ホスト間で交換できます（FTP、メール、またはその他のメカニズムを介して）。この機能は、組織がドメインを望んでいるが名前サーバーをサポートしたくない場合に便利です。組織は、テキストエディターを使用してマスターファイルをローカルで維持し、名前サーバーを実行する外部ホストに転送し、名前サーバーのシステム管理者と調整してファイルをロードさせることができます。

各ホストの名前サーバーとリゾルバーは、ローカルシステム管理者によって構成されます [RFC-1033]。名前サーバーの場合、この構成データには、ローカルマスターファイルの識別と、外部サーバーからロードする非ローカルマスターファイルに関する指示が含まれます。名前サーバーは、マスターファイルまたはコピーを使用してゾーン (Zones) をロードします。リゾルバーの場合、構成データは、情報の主要なソースである必要がある名前サーバーを識別します。

ドメインシステムは、データにアクセスし、他の名前サーバーへの参照を行うための手順を定義します。ドメインシステムは、取得したデータをキャッシュし、システム管理者によって定義されたデータの定期的な更新のための手順も定義します。

責任の分担 (Division of responsibilities)​

システム管理者が提供するもの:

  • ゾーン境界の定義
  • データのマスターファイル
  • マスターファイルの更新
  • 希望する更新ポリシーの記述

ドメインシステムが提供するもの:

  • リソースデータの標準形式
  • データベースをクエリする標準メソッド
  • 名前サーバーが外部名前サーバーからローカルデータを更新する標準メソッド

2.4. DNSの要素 (Elements of the DNS)​

DNSには3つの主要なコンポーネントがあります:

ドメイン名前空間とリソースレコード (DOMAIN NAME SPACE and RESOURCE RECORDS)​

ドメイン名前空間とリソースレコード (DOMAIN NAME SPACE and RESOURCE RECORDS) は、ツリー構造の名前空間と名前に関連付けられたデータの仕様です。概念的には、ドメイン名前空間ツリーの各ノードとリーフは情報のセットに名前を付け、クエリ操作は特定のセットから特定の型の情報を抽出する試みです。クエリは、関心のあるドメイン名と、必要なリソース情報の型を記述します。たとえば、インターネットは一部のドメイン名を使用してホストを識別します。アドレスリソースのクエリは、インターネットホストアドレスを返します。

名前サーバー (NAME SERVERS)​

名前サーバー (NAME SERVERS) は、ドメインツリーの構造とセット情報に関する情報を保持するサーバープログラムです。名前サーバーは、ドメインツリーの任意の部分に関する構造またはセット情報をキャッシュできますが、一般的に特定の名前サーバーは、ドメインスペースのサブセットに関する完全な情報と、ドメインツリーの任意の部分からの情報につながる他の名前サーバーへのポインターを持っています。名前サーバーは、完全な情報を持っているドメインツリーの部分を知っています。名前サーバーは、名前空間のこれらの部分に対して権威 (AUTHORITY) があると言われます。権威情報は、ゾーン (ZONEs) と呼ばれる単位に編成され、これらのゾーンは、ゾーン内のデータに対して冗長サービスを提供する名前サーバーに自動的に配布できます。

リゾルバー (RESOLVERS)​

リゾルバー (RESOLVERS) は、クライアントリクエストに応答して名前サーバーから情報を抽出するプログラムです。リゾルバーは、少なくとも1つの名前サーバーにアクセスでき、その名前サーバーの情報を使用してクエリに直接応答するか、他の名前サーバーへの参照を使用してクエリを追跡する必要があります。リゾルバーは通常、ユーザープログラムから直接アクセス可能なシステムルーチンです。したがって、リゾルバーとユーザープログラムの間にプロトコルは必要ありません。

ドメインシステムの3つのビュー (Three views of the domain system)​

これら3つのコンポーネントは、ドメインシステムの3つのレイヤーまたはビューにほぼ対応しています:

  • ユーザーの視点から (From the user's point of view)、ドメインシステムは、ローカルリゾルバーへの単純なプロシージャまたはOSコールを通じてアクセスされます。ドメインスペースは単一のツリーで構成され、ユーザーはツリーの任意のセクションから情報を要求できます。

  • リゾルバーの視点から (From the resolver's point of view)、ドメインシステムは未知数の名前サーバーで構成されています。各名前サーバーには、ドメインツリー全体のデータの1つ以上の部分がありますが、リゾルバーはこれらのデータベースの各々を本質的に静的と見なします。

  • 名前サーバーの視点から (From a name server's point of view)、ドメインシステムは、ゾーンと呼ばれるローカル情報の個別のセットで構成されています。名前サーバーには、一部のゾーンのローカルコピーがあります。名前サーバーは、ローカルファイルまたは外部名前サーバーのマスターコピーからゾーンを定期的に更新する必要があります。名前サーバーは、リゾルバーから到着するクエリを同時に処理する必要があります。

パフォーマンスのために、実装はこれらの機能を結合する場合があります。たとえば、名前サーバーと同じマシン上のリゾルバーは、名前サーバーによって管理されるゾーンとリゾルバーによって管理されるキャッシュで構成されるデータベースを共有する場合があります。

に最終更新