ネットワークワーキンググループ P. Mockapetris RFC: 1034 ISI 廃止(Obsolates): RFC 882, 883, 973 1987年11月 ドメイン名：概念と機能 1. 本文書の位置づけ このRFCは、ドメイン名システム(DNS)を紹介するものであり、関連RFCである "ドメイン名：実装と仕様(Domain Names - Implementation and Specification)" [RFC-1035]で得られる多くの詳細は省略している。[RFC-1035]は、本文書で議論 される概念を読者が理解していることを前提としている。 DNSの機能とデータタイプのサブセットが公式プロトコルの構成要素である。 公式プロトコルは標準問い合わせとその応答、そしてインターネットクラス (例えばホストアドレス)のデータフォーマットの大部分を含んでいる。 しかし、ドメインシステムは意図的に拡張可能なものとしている。研究者達は、 新しいデータタイプ、問い合わせタイプ、クラス、機能等を継続的に提案、実装、 実験し続けている。従って、この公式プロトコルの構成要素は本質的に 変化しないまま維持され、実運用サービスとして運用されることが期待される 一方で、実験的な振る舞いは、常に公式プロトコルの範囲外の拡張に属するもの だと期待されるべきである。実験的機能や廃止された機能は、これらのRFCの中で 明確にマークされる。またそのような情報は注意深く使用されるべきである。 例に登場する値は、主として説明のために設定されたものであるから、 読者はこれらを最新または完全なものとして依存しないように特に注意せよ。 本文書の配布は制限されない。 2. はじめに 本RFCは、ドメイン形式の名前と、インターネットメールやホストアドレス検索 をサポートするためのドメイン名の使用法、ドメイン名の機能を実装するために 使用されるプロトコルとサーバー等を紹介する。 2.1. ドメイン名の歴史 ドメインシステムの開発を推進したものは、インターネットの成長であった。 ・ホスト名とアドレスの対応付けは単一のファイル(HOSTS.TXT)に保存されて おり、ネットワークインフォメーションセンター(NIC)によって保守され、 全ホストからFTPで取得されていた[RFC-952, RFC-953]。 Mockapetris [Page 1] RFC 1034 Domain Concepts and Facilities November 1987 この仕組みでは、新しいバージョンの配付で消費される全ネットワーク 帯域は、ネットワーク内のホスト数の二乗に比例する。たとえ複数階層 から成るFTP配送が使用されるとしても、頂点にあるNICホストのFTP出力 の負荷は相当な量になる。ホスト数の爆発的増加は、将来への良い兆候とは 言えなかった。 ・ネットワーク参加者達の性質も変化しつつあった。初期のARPANETを構成 していたタイムシェアリングホストは、ワークステーションのローカルな ネットワークに置き換わりつつあった。ローカルな組織は、保持する機器の 名前とアドレスを管理していたが、その変更がインターネット全域に 行き渡るには、NICによるHOSTS.TXTの変更を待たなければならなかった。 また、組織は名前空間において、何らかのローカルな構造が構築できる ことを望んでいた。 ・インターネット上のアプリケーションはより洗練されつつあり、汎用の名前 サービスの必要が生じつつあった。 これら一連の結果として、名前空間とその管理に関する幾つかのアイディアが 生まれた[IEN-116, RFC-799, RFC-819, RFC-830]。それらの提案は多様であったが、 共通するテーマは、名前空間を階層化し、その階層を大まかに組織構造に対応 させること、また階層レベル間の境界をマークする文字として"."を使用する というアイディアであった。分散型データベースと一般化されたリソースを 使用する設計は[RFC-882, RFC-883]に記述された。幾つかの実装経験に基づいて、 システムは本文書に記述される仕組みへと進化した。 "ドメイン"または"ドメイン名"という用語は、ここで記述されるDNSの範囲を越えて 多くのコンテキストで使用される。非常に多くの場合、ドメイン名という用語は ドットで示される構造を持つ名前を参照するために使用されるが、DNSとは無関係 である。これはメールのアドレッシングにおいて特にあてはまる[Quarterman 86]。 2.2. DNSの設計のゴール DNSの設計のゴールはその構造に影響を与えている。それらは以下の通りである。 ・主たるゴールは、リソースを参照するために使用される、一貫性のある 名前空間である。その場限りの(ad hoc)エンコーディングによって生じる 問題を回避するために、名前はネットワークID、アドレス、経路、同様の 情報を名前の一部として含めることを要求されるべきではない。 ・データベースの大きさと更新頻度は、データベースが分散型の方式で 保守され、パフォーマンス改善のためにローカルなキャッシュ処理を 伴わなければならないことを示唆している。 Mockapetris [Page 2] RFC 1034 Domain Concepts and Facilities November 1987 データベース全体の一貫性のあるコピーの収集を試みるアプローチは、 非常にコスト高で困難なものになるので、回避されるべきである。 同じ原則が名前空間の構造と、名前の生成と削除を行う仕組みにも適用 される。つまり、これらもまた分散型とすべきである。 ・データを取得するコストと、更新の早さ、キャッシュの正確性の間に トレードオフが存在する状況では、データの情報源がトレードオフを 制御すべきである。 ・そのような機能の実装コストは、それが一般的に有用で、単一 アプリケーションに制限されないことを要求する。従って、名前を 使用して、ホストアドレス、メールボックスのデータ、その他現時点で 不確定の情報を検索できるようにすべきである。名前に関連付けられた データはすべてタイプによってタグ付けされ、問い合わせは単一のタイプに 限定できるようにする。 ・我々は、異なるネットワーク及びアプリケーションにおいても名前空間が 有用であることを望むので、異なるプロトコルファミリーまたは管理方式で 同じ名前空間を使用できる機能を提供する。例えば、すべてのプロトコルは アドレスの概念を持つが、ホストアドレスのフォーマットはプロトコル間で 異なる。DNSは全データに対してクラスだけでなくタイプでもタグ付けする ので、異なるデータフォーマットを持つアドレスタイプの並列使用を許容 できるようになる。 ・我々は、ネームサーバーのトランザクションが関連データを配送する通信 システムに対して独立であることを望む。あるシステムは問い合わせと応答に データグラムを使用し、信頼性の必要なトランザクション(例えばデータ ベース更新や長時間のトランザクション)に対してだけ仮想通信路の確立を 希望するかもしれない。一方で、他のシステムは仮想通信路だけを単独で 使用するだろう。 ・ドメインシステムは、ホストが提供する機能の広範囲に渡って有用である べきである。パーソナルコンピューターも、大規模なタイムシェアリング ホストも、手段は異なるかもしれないが、どちらもドメインシステムを使用 できるようにすべきである。 2.3. 使用法に関する想定 ドメインシステムの組織構造は、ユーザーコミュニティにおけるシステムの 必要性とその利用パターンに関する幾つかの想定に由来している。また、汎用 データベースシステムで見られる複雑な問題の多くを回避するように設計 されている。 先に記した想定は以下の通りである。 Mockapetris [Page 3] RFC 1034 Domain Concepts and Facilities November 1987 ・データベースのトータルサイズは、初めはシステムを使用するホスト数 に比例する。しかし、メールボックスや他の情報がドメインシステムに追加 されることから、最終的にはシステムを使用するホスト上のユーザー数に 比例して増大するようになる。 ・システム内の大半のデータはゆっくりと変化する(例えばメールボックスとの 関連付けやホストアドレス)。システムはより短時間(秒または分のオーダー) で変化するデータのサブセットも処理するはずである。 ・データベースの責任を分散するために使用される管理境界は、通常、 1台以上のホストを保持する組織に対応する。特定のドメインの集合に 関する責任を持つ各組織は、その組織の保有ホストか、組織が使用する よう手配されたホストのどちらかによって、冗長なネームサーバーを 提供する。 ・ドメインシステムのクライアントは、優先して使用する"信頼する" ネームサーバーの集合から外れたサーバーへの参照を受け容れる前に、 信頼するネームサーバーを特定するはずである。 ・情報へのアクセスは、即時的更新や一貫性の保証よりも重要である。そのため、 更新処理は、全コピーが同時に更新されることを保証するのではなく、更新が ドメインシステムのユーザーを通して浸透的に伝わっていくことを許容する。 ネットワークまたはホストの障害のために更新が利用できない場合の通常の 処理は、更新の努力を継続しつつ古い情報を信用することである。一般的な モデルは、リフレッシュのタイムアウト値を設定されたコピーが配付される というものである。情報配信者がタイムアウト値を設定し、配付の受け手が リフレッシュを実行する責任を持つ。特殊な状況では極めて短い間隔を指定 することもできる。あるいは、情報所有者がコピーを拒否することもできる。 ・分散型データベースを持つどのシステムにおいても、他のサーバーだけが回答 できる問い合わせを特定のネームサーバーが受信する場合がある。この問題に対処 する二つの一般的なアプローチは、最初のサーバーがクライアントに替わって 他のサーバーに問い合わせを続行する"再帰(recursive)"と、サーバーがクライ アントに別のサーバーを参照させ、クライアントが問い合わせを続行する"反復 (iterative)"である。どちらのアプローチも利点と欠点を持つが、データグラム 型のアクセスに対しては反復アプローチの方が望ましい。ドメインシステムは 反復アプローチの実装を要求するが、オプションとして再帰アプローチも許容 する。 Mockapetris [Page 4] RFC 1034 Domain Concepts and Facilities November 1987 ドメインシステムは、全データはドメインシステムを使用するホスト上に散在する マスターファイルに由来するという前提を持つ。これらのマスターファイルは、 ローカルシステムの管理者によって更新される。マスターファイルはローカルな ネームサーバーに読み込まれるテキストファイルであるから、ドメインシステムの ユーザーからはネームサーバーを通して利用可能となる。ユーザープログラムは、 リゾルバーと呼ばれる標準的プログラムを通してネームサーバーにアクセスする。 マスターファイルの標準的フォーマットにより、ホスト間で(FTP、メール、他の 仕組み経由での)マスターファイルのやりとりが可能となる。この機能は、 ある組織がドメインは欲しいがネームサーバーのサポートはしたくない といった場合に有用である。そのような組織は、マスターファイルをテキスト エディターを使用してローカルに保守し、それをネームサーバーが稼働している 外部のホストに転送し、そのネームサーバーの管理者にファイルをロードする ように手配するといったことができる。 各ホストのネームサーバーとリゾルバーは、ローカルなシステム管理者によって 設定される[RFC-1033]。ネームサーバーの場合、この設定データにはローカル マスターファイルの識別情報と、ローカルに存在しないマスターファイルを 外部のサーバーからロードするための指示が含まれる。ネームサーバーは、自身が 管理するゾーンをロードするために、マスターファイルかそのコピーを使用する。 リゾルバーの場合、設定データは情報の主たる情報源となるべきネームサーバーを 特定する。 ドメインシステムは、データへのアクセス手段及び他のネームサーバーを参照する 手段を定義する。またドメインシステムは、取得したデータをキャッシュする手段と、 システム管理者の定義に従う定期的なデータのリフレッシュ手段も定義する。 システム管理者は以下を提供する。 ・ゾーン境界の定義 ・データのマスターファイル ・マスターファイルの更新 ・望ましいリフレッシュポリシーの表明 ドメインシステムは以下を提供する。 ・リソースデータの標準的フォーマット ・データベースに問い合わせる標準的手法 ・ネームサーバーがローカルデータを外部のネームサーバーでリフレッシュ する標準的手法 Mockapetris [Page 5] RFC 1034 Domain Concepts and Facilities November 1987 2.4. DNSの構成要素 DNSは、以下に示す三つの主要な構成要素を持つ。 ・"ドメイン名空間"と"リソースレコード"。これらは、ツリー構造を持つ 名前空間と、名前に関連付けられたデータに関する仕様である。 概念的には、ドメイン名空間ツリーの各ノードとリーフは情報の集合に 名前を付けたものであり、問い合わせ作業とは特定の集合から特定のタイプ の情報を抽出する試みである。問い合わせは、関心のあるドメイン名を指定 し、要求されたリソース情報のタイプを記述する。例えば、インターネットは ホストを特定するために、ホストのドメイン名を使用する。具体的に、 アドレスリソースを問い合わせると、インターネットホストアドレスが 返される。 ・"ネームサーバー"。これはドメインツリーの構造と情報の集合を保持する サーバープログラムである。ネームサーバーは、ドメインツリーの任意の 部分に関する構造または情報の集合をキャッシュしてもよいが、一般に 特定のネームサーバーは、自身が管理するドメイン空間のサブセットに 関する完全な情報と、ドメインツリーの任意の部分から情報に到達する ために使用可能な他のネームサーバーへのポインターを保持する。 ネームサーバーは、ドメインツリーの一部を知っており、その部分に関しては 完全な情報を持つ。その場合、ネームサーバーは名前空間のその部分に関する "権威(AUTHORITY)"である、と呼ばれる。権威を持つ(authoritative)情報は "ゾーン(ZONE)"と呼ばれる単位に組織化され、これらのゾーンは ゾーンのデータに対して冗長化サービスを提供するネームサーバーへと 自動的に配付されるようにすることができる。 ・"リゾルバー"。これはクライアントのリクエストに応えてネームサーバー から情報を抽出するプログラムである。リゾルバーは少なくとも一つのネーム サーバーにアクセスし、そのネームサーバーの情報を使用して問い合わせに 直接回答するか、他のネームサーバーへの参照を使用して問い合わせを続行 出来なければならない。リゾルバーは大抵の場合、ユーザープログラムに 直接アクセス可能なシステムルーチンになるだろう。従って、リゾルバー とユーザープログラムの間にプロトコルは必要ない。 これら三つの構成要素は、大まかにドメインシステムの三つのレイヤーまたは 見え方に対応する。 ・ユーザーの観点から見ると、ドメインシステムとは、ローカルリゾルバー へのシンプルな手続きかOSコールを通してアクセスされるものである。 ドメイン空間は単一のツリーで構成され、ユーザーはツリーのどの部分 からでも情報をリクエストすることができる。 ・リゾルバーの観点から見ると、ドメインシステムとは、多数の未知のネーム サーバーで構成されるものである。 Mockapetris [Page 6] RFC 1034 Domain Concepts and Facilities November 1987 各ネームサーバーはドメインツリー全体のデータの一つ以上の断片を持つが、 リゾルバーはこれらの各データベースを本質的に静的なものと見なす。 ・ネームサーバーの観点から見ると、ドメインシステムとは、ゾーンと 呼ばれるローカルな情報の独立した集合で構成されるものである。 ネームサーバーは、 幾つかのゾーンのローカルなコピーを保持する。 ネームサーバーは、ローカルファイルまたは外部のネームサーバーの マスターのコピーによって、そのゾーンを定期的にリフレッシュしなければ ならない。ネームサーバーは、多数のリゾルバーから到着する複数の 問い合わせを並列に処理できなければならない。 パフォーマンスを得るために、実装はこれらの機能を併せ持ってもよい。例えば、 ネームサーバーと同じマシン上のリゾルバーは、ネームサーバーに管理される ゾーンを構成するデータベースとリゾルバーに管理されるキャッシュを共有 するかもしれない。 3. ドメイン名空間とリソースレコード 3.1. 名前空間の仕様と用語 ドメイン名空間はツリー構造である。ツリー上の各ノードとリーフはリソースの 集合(空でもよい)に対応する。ドメインシステムは、内部ノードの使用と リーフの使用を区別しない。本文書が使用する"ノード"という用語は、両方を 参照する。 各ノードはラベルを持ち、その長さはゼロから63オクテットである。兄弟 (訳注: 同じ親を持つ)でないノード同士では同じラベルが使用できるが、 兄弟ノードは同じラベルを持つことが出来ない。ラベルが一つ予約される。 それはルートに対して使用されるヌル(null)ラベル(長さゼロのラベル)である。 ノードのドメイン名は、ツリーのルートからそのノードまでのパス上にある ノードのラベルを一覧に並べたものである。慣習により、ドメイン名を構成する ラベルは、左から右へ、最も具体的な(最も下位な、ルートから最も遠い)部分から 最も包括的な(最も上位な、ルートに最も近い)方向へと印字され、読まれる。 ドメイン名を操作するプログラムは、内部的にはドメイン名をラベルの並び として表現すべきである。各ラベルはラベルのオクテット長にオクテット形式の ラベル文字が続くものとなる。すべてのドメイン名はヌル文字のラベルを持つ ルートで終わるので、内部的な表現は、ドメイン名を終端させるためにラベル長 ゼロを使用することができる。 慣習により、ドメイン名は大文字・小文字どちらででも保存可能である。 しかし、現在のドメイン名に関する全機能に関して、ドメイン名の比較は、 ASCII文字集合で最上位ビットがゼロであるならば、大文字小文字を区別 せずに実行される。これは、ラベル"A"のノードも、ラベル"a"のノードも 自由に生成できるが、両者を兄弟ノードにはできないこと、またそのような ラベルは"a"または"A"のどちらでも参照できることを意味する。 Mockapetris [Page 7] RFC 1034 Domain Concepts and Facilities November 1987 ドメイン名またはラベルを受信した場合、大文字・小文字の種別を保存すべき である。この選択の理由は、我々はいつか新しいサービスのためにすべてが バイナリーのドメイン名を追加する必要が生じるかもしれないからである。 このようにしておくことで、そうなったとしても、既存のサービスは変更 されなくともよくなる。 ユーザーがドメイン名をタイプする必要がある場合、各ラベルの長さは省略され、 ラベルはドット(".")によって区切られる。完全なドメイン名はルートラベルで 終了するので、印字はドットで終了する形となる。以下を区別するために、この 性質を利用する。 ・完全なドメイン名を表現する文字列(しばしば"絶対(absolute)"と 呼ばれる)。例えば "poneria.ISI.EDU."。 ・ドメイン名の先頭ラベル部分を表現する文字列で、ドメイン名として 完全ではなく、ローカルソフトウェアがローカルドメインの知識を 使用して補完されるべきもの。(しばしば"相対(relative)"と呼ばれる)。 例えば、ISI.EDU ドメインで使用される "poneria"。 相対名(relative name)は、よく知られている起点か探索リストとして使用される ドメイン名のリストのどちらかに対して相対的とみなされるものである。相対名が 現れるのは、大抵の場合次の2箇所である。一つはユーザーインターフェースで、 ここでは実装によって相対名の解釈に幅が生じる。もう一つはマスターファイル内で、 ここでは相対名はドメイン名の単一の起点に対して相対となる。最も一般的な 解釈は、ルート"."を単一の起点または探索リストの要素の一つとして使用する というものである。つまり、複数ラベルで構成される相対名は、しばしば タイピングを減らすために末尾のドットが省略されたものと解釈される。 実装をシンプルにするため、ドメイン名を表現するトータルオクテット数(すなわち、 全ラベルのオクテットと、各ラベルのオクテット長の和)は255に制限される。 ドメインはドメイン名によって特定され、ドメインを指定するドメイン名の位置 またはその下方のドメイン名空間の対応部分によって構成される。ドメインが別の ドメインに包含される場合、そのドメインのサブドメインになる。この関係は、 サブドメインの名前がそれを包含するドメイン名で終わっているかどうかを見る ことで検査することができる。例えば、A.B.C.DはB.C.D、C.D、D、" "のサブ ドメインである。 3.2. 使用に関する管理ガイドライン ポリシーの問題として、DNS技術仕様は、特定のツリー構造やラベル選択ルールを 要求しない。そのゴールは、任意のアプリケーション構築に使用できるように、 可能な限り一般的なものにすることである。具体的にドメインシステムは、 名前空間がネットワーク境界、ネームサーバー等に従って組織化される必要が ないように設計された。このようにした論拠は、名前空間が暗黙の意味を持つ べきでないということではなく、むしろ暗黙の意味を持たせるという選択を 直近の問題に対して使用するかは結論を出さないということ、従って ツリーの異なる部分はそれぞれ異なる暗黙の意味を持てるということである。 Mockapetris [Page 8] RFC 1034 Domain Concepts and Facilities November 1987 例えば、IN-ADDR.ARPAドメインは、その役割がネットワーク番号またはホスト 番号を名前に変換することなので、ネットワークアドレスまたはホストアドレス によって組織化され、分散される。これに対し、NetBIOSドメイン[RFC-1001, RFC-1002]はフラットである。その方がアプリケーションに適しているからである。 しかし、ホストやメールボックス等に使用される名前空間の"通常(normal)"部分 に適用される幾つかのガイドラインが存在している。それらは名前空間をより同質な ものとし、成長に備え、ソフトウェアを古いホストテーブル対応から切り替える際の 問題を最小化しようとするものである。ツリーのトップレベルに関する政治的 判断は、RFC-920に由来している。トップレベルに関する現在のポリシーは、 [RFC-1032]で議論されている。MILNETのソフトウェア切り替えに関する問題は [RFC-1031]でカバーされている。 いずれ複数のゾーンに分割されるだろう下位ドメインは、最終的な分割をリネーム 無しで実行できるように、そのドメインの最上位で分岐を提供すべきである。 特殊な文字を使用していたり、数字で始まったりする等のノードラベルは、より 制限の強い選択に依存する古いソフトウェアに障害を引き起こす可能性がある。 3.3. 使用に関する技術ガイドライン 何らかのオブジェクトの名前情報を保持するためにDNSを使用できるように する前に、二つの要求事項を満たさなければならない。 ・オブジェクト名とドメイン名を対応付けるための規定。 これはオブジェクトに関する情報にどのようにアクセスされるか を記述する。 ・オブジェクトを記述するためのRRタイプとデータフォーマット。 これらのルールは、非常にシンプルにも極めて複雑にもすることができる。 非常に多くの場合、設計者は既存のフォーマットを考慮し、既存の使用法に 対する上位互換性を立案したりしなければならない。複数の変換処理や、 変換処理のレベルが要求されてもよい。 ホストの場合の変換処理は、ドメイン名の通常のテキスト表現のサブセット となっているホスト名の既存の構文と、ホストアドレス等を記述するRRの フォーマットに依存する。また、アドレスからホスト名への信頼性のある 逆変換処理を必要とするため、アドレスからIN-ADDR.ARPAドメインへの 特別な変換処理も定義される。 メールボックスの変換処理は少しだけ複雑である。通常のメールアドレス @は、次のようにドメイン名に変換処理される。 が(そこにドットが含まれていても関係なく)単一のラベルに変換 され、がドメイン名の通常のテキストフォーマット(ドットが ラベルの区切りを意味する)を使用してドメイン名に変換され、これら二つを 連結して単一のドメイン名を形成する。 Mockapetris [Page 9] RFC 1034 Domain Concepts and Facilities November 1987 従って、メールボックスHOSTMASTER@SRI-NIC.ARPAは、ドメイン名 HOSTMASTER.SRI-NIC.ARPAとして表現される。このような設計を行った理由 を評価するには、メール交換の仕組み[RFC-974]も考慮しなければならない。 典型的なユーザーがこれらのルールの定義に関わることはない。しかしこれらの ルールが大抵の場合、古い使用法との上位互換を維持する要望、異なる定義の オブジェクト間のやりとり、ルール定義の際に新しい機能を追加するという 避けがたい要請等の間で行われた多くの妥協の結果であることは理解すべきである。 あるオブジェクトをサポートするためのDNSの使用方法は、DNS固有の制約 よりもしばしばより重要である。 3.4. 名前空間の例 以下の図は現在のドメイン名空間の一部を示すもので、本RFCの多数の例で使用 されているものである。このツリーは実際の名前空間の非常に小さいサブセット であることに注意せよ。 | | +---------------------+------------------+ | | | MIL EDU ARPA | | | | | | +-----+-----+ | +------+-----+-----+ | | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC | +--------+------------------+---------------+--------+ | | | | | UCI MIT | UDEL YALE | ISI | | +---+---+ | | | | LCS ACHILLES +--+-----+-----+--------+ | | | | | | XX A C VAXA VENERA Mockapetris この例において、ルートドメインは直下に三つのサブドメイン MIL、EDU、ARPA を持つ。LCS.MIT.EDUドメインは、直下にXX.LCS.MIT.EDUという名前のサブ ドメインを持つ。すべてのリーフもまたドメインである。 3.5. 推奨される名前の構文 DNS仕様は、ドメイン名構築に関するルールについては可能な限り一般的である ように努めている。 Mockapetris [Page 10] RFC 1034 Domain Concepts and Facilities November 1987 アイディアは、既存のどのオブジェクトの名前も、最小の変更でドメイン名 として表現できるようにするというものである。しかし、オブジェクトに ドメイン名を割り当てる際に、賢明なユーザーはドメインシステムのルールと、 オブジェクトに関する既存のルール(公開されているか既存のプログラムに よって暗示されている)の両方を満足するような名前を選択するだろう。 例えば、メールドメインに名前を付ける場合、ユーザーは本文書のルールとRFC-822 記載のルールの両方を満足すべきである。新しいホスト名を作成する場合、 HOSTS.TXTの古いルールに従うべきである。これらの作業は、古いソフトウェアを ドメインシステムを使用するものに切り替える際に生じる問題を回避する。 以下の構文に従うと、ドメイン名を使用する多数のアプリケーション (例えばメール、TELNET)で生じる問題がより少なくなるだろう。 ::= | " " ::=