ネットワークワーキンググループ P. Mockapetris RFC: 1035 ISI 1987年11月 廃止(Obsolates): RFC 882, 883, 973 ドメイン名：実装と仕様 1. 本文書の位置づけ 本RFCはドメインシステムとプロトコルを記述するものであり、読者は関連RFC である"ドメイン名：概念と機能(Domain Names - Concepts and Facilities)" [RFC-1034]で議論された概念を理解していることを前提とする。 ドメインシステムは、公式プロトコルとなっている機能及びデータタイプと、 依然として実験的状態の機能及びデータタイプが混在したものである。 ドメインシステムは意図的に拡張可能なものとしているため、新しいデータ タイプや実験的な振る舞いは、常に公式プロトコル外にあるシステムの一部 と期待されるべきである。公式プロトコルの部分は、標準問い合わせと応答、 インターネットクラスのRRのデータフォーマット(例えばホストアドレス)を 含む。過去のRFCが規定されて以来、幾つかの定義が変更された。従って、 幾つかの過去の定義は廃止される。 実験的機能や廃止された機能は、これらのRFCの中で明確にマークされる。 またそのような情報は注意深く使用されるべきである。 例に登場する値は、主として説明のために設定されたものであるから、 読者はこれらを最新または完全なものとして依存しないように特に注意せよ。 本文書の配布は制限されない。 目次 1. 本文書の位置づけ 1 2. はじめに 3 2.1. 概説 3 2.2. 一般的な構成 4 2.3. 慣例 7 2.3.1. 推奨される名前の構文 7 2.3.2. データ転送の順序 8 2.3.3. 大文字・小文字の種別 9 2.3.4. サイズの上限 10 3. ドメイン名空間とRRの定義 10 3.1. 名前空間の定義 10 3.2. RRの定義 11 3.2.1. フォーマット 11 3.2.2. TYPEの値 12 3.2.3. QTYPEの値 12 3.2.4. CLASSの値 13 Mockapetris [Page 1] RFC 1035 Domain Implementation and Specification November 1987 3.2.5. QCLASSの値 13 3.3. 標準的なRR 13 3.3.1. CNAMEのRDATA部のフォーマット 14 3.3.2. HINFOのRDATA部のフォーマット 14 3.3.3. MBのRDATA部のフォーマット(実験的) 14 3.3.4. MDのRDATA部のフォーマット(廃止) 15 3.3.5. MFのRDATA部のフォーマット(廃止) 15 3.3.6. MGのRDATA部のフォーマット(実験的) 16 3.3.7. MINFOのRDATA部のフォーマット(実験的) 16 3.3.8. MRのRDATA部のフォーマット(実験的) 17 3.3.9. MXのRDATA部のフォーマット 17 3.3.10. NULLのRDATA部のフォーマット(実験的) 17 3.3.11. NSのRDATA部のフォーマット 18 3.3.12. PTRのRDATA部のフォーマット 18 3.3.13. SOAのRDATA部のフォーマット 19 3.3.14. TXTのRDATA部のフォーマット 20 3.4. インターネット固有のRR 20 3.4.1. AのRDATA部のフォーマット 20 3.4.2. WKSのRDATA部のフォーマット 21 3.5. IN-ADDR.ARPAドメイン 22 3.6. 新しいタイプ、クラス、特別な名前空間の定義 24 4. メッセージ 25 4.1. フォーマット 25 4.1.1. ヘッダー部のフォーマット 26 4.1.2. 問い合わせ部のフォーマット 28 4.1.3. リソースレコードのフォーマット 29 4.1.4. メッセージ圧縮 30 4.2. トランスポート 32 4.2.1. UDPの使用法 32 4.2.2. TCPの使用法 32 5. マスターファイル 33 5.1. フォーマット 33 5.2. ゾーン定義のためのマスターファイル使用 35 5.3. マスターファイルの例 36 6. ネームサーバーの実装 37 6.1. アーキテクチャー 37 6.1.1. 制御 37 6.1.2. データベース 37 6.1.3. 時間 39 6.2. 標準問い合わせの処理 39 6.3. ゾーンのリフレッシュ及びリロードの処理 39 6.4. 逆問い合わせ(任意) 40 6.4.1. 逆問い合わせとその応答の内容 40 6.4.2. 逆問い合わせとその応答の例 41 6.4.3. 逆問い合わせの処理 42 Mockapetris [Page 2] RFC 1035 Domain Implementation and Specification November 1987 6.5. 補完問い合わせとその応答 42 7. リゾルバーの実装 43 7.1. ユーザーのリクエストから問い合わせへの変換 43 7.2. 問い合わせの送信 44 7.3. 応答の処理 46 7.4. キャッシュの使用 47 8. メールのサポート 47 8.1. メールエクスチェンジとの関連付け 48 8.2. メールボックスとの関連付け(実験的) 48 9. REFERENCES and BIBLIOGRAPHY 50 Index 54 2. はじめに 2.1. 概説 ドメイン名のゴールは、異なるホスト、ネットワーク、プロトコルファミリー、 インターネット、管理組織においても名前が利用できる方法で、リソースに 名前をつける仕組みを提供することである。 ユーザーの観点から見ると、ドメイン名はローカルエージェントの引数として 有用である。ローカルエージェントはリゾルバーと呼ばれ、引数として与えられた ドメイン名の情報を取得する。従って、ユーザーは特定のドメイン名に 関連するホストアドレスやメール情報等を要求することになるだろう。ユーザーが 特定のタイプの情報をリクエストできるように、ドメイン名と共に適切な問い合わせ タイプがリゾルバーに渡される。ユーザーにとって、ドメインツリーは単一の 情報空間である。リゾルバーは複数のネームサーバー間に情報が分散されている ことをユーザーから隠蔽する責任を負う。 リゾルバーの観点から見ると、ドメイン空間を構成するデータベースは、さまざまな ネームサーバーの間に分散されている。ドメイン空間の異なる部分は、それぞれ 異なるネームサーバーに保存される。ただし、特定のデータ項目は2台以上の ネームサーバーに冗長的に保存される。リゾルバーは、少なくとも一つのネーム サーバーの知識と共に処理を開始する。リゾルバーがユーザーの問い合わせを 処理する場合、既知のネームサーバーに情報を問い合わせ、その応答として、 リゾルバーは要求した情報か他のネームサーバーへの参照のどちらかを受信する。 それらの参照を使用することで、リゾルバーは他のネームサーバーの名前、 アドレスといった情報と、サーバーが保持する内容を学習する。リゾルバーは ドメイン空間の分散に対応し、ネームサーバー障害の際には、他のサーバーの 冗長データベースに助力を求めるなどしてその影響に対処する責任を持つ。 ネームサーバーは2種類の情報を管理する。一つめのデータは、ゾーンと呼ばれる 集合内に保持される。各ゾーンは、ドメイン空間において"切り取られた"特定の サブツリーの完全なデータベースである。このデータは権威を持つと呼ばれる。 ネームサーバーは、自身のゾーンが最新であることを確認するために定期的な 検査を実施する。もし最新でない場合、ローカルまたは他のネームサーバーに 保存されたマスターファイルから更新されたゾーンの新しいコピーを取得する。 Mockapetris [Page 3] RFC 1035 Domain Implementation and Specification November 1987 二つめのデータは、ローカルリゾルバーによって取得されたキャッシュデータ である。このデータは不完全かもしれないが、ローカルにないデータにくり返し アクセスする場合に取得プロセスのパフォーマンスを改善する。キャッシュ データは、タイムアウトの仕組みによって最終的に廃棄される。 この機能構造は、リゾルバーにおいてユーザーインターフェース、障害回復、 情報分散の問題を分離すると同時に、ネームサーバーにおいてデータベース更新と リフレッシュの問題を分離する。 2.2. 一般的な構成 ホストは、多様な方法でドメイン名システムに参加することができる。 具体的に、ドメインシステムから情報を取得するプログラムを稼働させる、 他のホストからの問い合わせに回答するネームサーバーを稼働させる、 両方の機能を様々に組み合わせるといった方法がある。最も単純な、 そして恐らくは最も典型的な構成を以下に示す。 ﾛｰｶﾙﾎｽﾄ | 外部 | +---------+ +----------+ | +--------+ | |ﾕｰｻﾞｰの問合わせ| |問合わせ | | | | ﾕｰｻﾞｰ |-------------->| |---------|->| 外部 | | ﾌﾟﾛｸﾞﾗﾑ | | ﾘｿﾞﾙﾊﾞｰ | | | ﾈｰﾑ | | |<--------------| |<--------|--| ｻｰﾊﾞｰ | | |ﾕｰｻﾞｰへの応答 | |応答 | | | +---------+ +----------+ | +--------+ | A | ｷｬｯｼｭ追加 | | 参照 | V | | +----------+ | | ｷｬｯｼｭ | | +----------+ | ユーザープログラムは、リゾルバーを通してドメイン名空間とやりとりを行う。 ユーザーの問い合わせ、ユーザーへの応答のフォーマットは、ホスト及びその オペレーティングシステム固有のものである。ユーザーの問い合わせは、典型的な 場合オペレーティングシステムのシステムコールであり、リゾルバーやその キャッシュはホストのオペレーティングシステムの一部になるだろう。 能力の低いホストは、サービスを必要とする各プログラムにリンクされる サブルーチンの形でリゾルバーを実装することを選択してもよい。 リゾルバーは、外部のネームサーバーへの問い合わせを経て取得した情報と ローカルキャッシュからユーザーの問い合わせに回答する。 リゾルバーは、特定のユーザーの問い合わせに回答するために複数の異なる 外部ネームサーバーに対して複数回の問い合わせをしなければならないかもしれない ため、ユーザーの問い合わせの解決には何回かのネットワークアクセスと不特定の 時間が必要となるかもしれないことに注意せよ。 Mockapetris [Page 4] RFC 1035 Domain Implementation and Specification November 1987 外部ネームサーバーへの問い合わせと対応する応答は、本文書に記載される標準的 フォーマットを持ち、恐らくデータグラムを使用するだろう。 能力に応じて、ネームサーバーは専用機器のスタンドアローンプログラムであるかも しれないし、大規模タイムシェアリングホストのプロセスであるかもしれない。 単純な構成は以下のようになるだろう。 ﾛｰｶﾙﾎｽﾄ | 外部 | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | | 応答 | | | | | | | ﾈｰﾑ |---------|->| 外部 | | ﾏｽﾀｰ |-------------->| ｻｰﾊﾞｰ | | | ﾘｿﾞﾙﾊﾞｰ| | ﾌｧｲﾙ | | | |<--------|--| | | |/ | | 問合わせ| +--------+ +---------+ +----------+ | この構成では、プライマリネームサーバーは自身のローカルファイルシステムに あるマスターファイルを読み込むことで一つ以上のゾーンに関する情報を取得し、 外部のリゾルバーから到着するこれらのゾーンに関する問い合わせに回答する。 DNSは、すべてのゾーンが二つ以上のネームサーバーによって冗長的にサポート されることを要求する。指定セカンダリネームサーバーは、DNSのゾーン転送 プロトコルを使用することで、プライマリサーバーからゾーンを取得したり 更新を検査したりすることができる。この構成は以下に示すようになる。 ﾛｰｶﾙﾎｽﾄ | 外部 | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | | 応答 | | | | | | | ﾈｰﾑ |---------|->| 外部 | | ﾏｽﾀｰ |-------------->| ｻｰﾊﾞｰ | | | ﾘｿﾞﾙﾊﾞｰ| | ﾌｧｲﾙ | | | |<--------|--| | | |/ | | 問合わせ| +--------+ +---------+ +----------+ | A | 保守 | +--------+ | +------------|->| | | 問合わせ | | 外部 | | | | ﾈｰﾑ | +------------------|--| ｻｰﾊﾞｰ | 保守応答 | +--------+ この構成では、ネームサーバーは定期的に外部ネームサーバーに仮想通信路を確立し、 ゾーンのコピーを取得したり既存のコピーが更新されてないかを検査したりする。 Mockapetris [Page 5] RFC 1035 Domain Implementation and Specification November 1987 これらの保守活動のために送信されるメッセージは問い合わせや応答と同じ形式に 従うが、メッセージの順序が若干異なる。 ドメイン名システムの全特性をサポートするホストにおける情報の流れは 以下のように示される。 ﾛｰｶﾙﾎｽﾄ | 外部 | +---------+ +----------+ | +--------+ | |ﾕｰｻﾞｰの問合わせ| |問合わせ | | | | ﾕｰｻﾞｰ |-------------->| |---------|->| 外部 | | ﾌﾟﾛｸﾞﾗﾑ | | ﾘｿﾞﾙﾊﾞｰ | | | ﾈｰﾑ | | |<--------------| |<--------|--| ｻｰﾊﾞｰ | | |ﾕｰｻﾞｰへの応答 | | 応答 | | | +---------+ +----------+ | +--------+ | A | ｷｬｯｼｭ追加 | | 参照 | V | | +----------+ | | 共有 | | | ﾃﾞｰﾀﾍﾞｰｽ | | +----------+ | A | | +---------+ ﾘﾌﾚｯｼｭ | | 参照 | / /| | V | +---------+ | +----------+ | +--------+ | | | | | 応答 | | | | | | | Name |---------|->| 外部 | | ﾏｽﾀｰ |-------------->| Server | | | ﾘｿﾞﾙﾊﾞｰ| | ﾌｧｲﾙ | | | |<--------|--| | | |/ | | 問合わせ| +--------+ +---------+ +----------+ | A | 保守 | +--------+ | +------------|->| | | 問合わせ | | 外部 | | | | ﾈｰﾑ | +------------------|--| ｻｰﾊﾞｰ | 保守応答 | +--------+ 共有データベースは、ローカルネームサーバーとリゾルバー向けのドメイン空間 データを保持する。典型的な場合、共有データベースの中身はネームサーバーの 定期的なリフレッシュ操作によって保守される権威を持つデータと、過去に リゾルバーが発行したリクエストで取得したキャッシュデータの混成である。 ドメインデータの構造と、ネームサーバーとリゾルバー間の同期の必要性は、 このデータベースの一般的な特性を暗示するが、実際に使用されるフォーマットは ローカルな実装者次第である。 Mockapetris [Page 6] RFC 1035 Domain Implementation and Specification November 1987 ホストのグループがそれぞれ動作を最適化できるように、情報の流れを調整する こともできる。能力の低いホストの負荷を軽減し、フルリゾルバーを実装しなくて 済むようにするためにこれが行われる場合もある。これは、要求される新しい ネットワークコード量を最小化したいと望むPCまたはホストには適切なものと なり得る。また、中央管理型のキャッシュはより高いヒット率を得られることを 前提として、この仕組みによりホストのグループが独立した大量のキャッシュを 保守するのではなく、少量のキャッシュを共有することが可能となる。 いずれの場合にせよ、リゾルバーはスタブリゾルバーに置き換えられる。これは、 サービスを実行していることが知られている一つ以上のネームサーバー内の 再帰サーバー部に組み込まれたリゾルバーへのフロントエンドとして動作するもの である。 ﾛｰｶﾙﾎｽﾄ | 外部 | +---------+ | | | 応答 | | ｽﾀﾌﾞ |<--------------------+ | | ﾘｿﾞﾙﾊﾞｰ | | | | |----------------+ | | +---------+ 再帰 | | | 問合わせ | | | V | | +---------+ 再帰 +----------+ | +--------+ | | 問合わせ | |問合わせ | | | | ｽﾀﾌﾞ |-------------->| 再帰 |---------|->| 外部 | | ﾘｿﾞﾙﾊﾞｰ | | ｻｰﾊﾞｰ | | | ﾈｰﾑ | | |<--------------| |<--------|--| ｻｰﾊﾞｰ | +---------+ 応答 | | 応答 | | | +----------+ | +--------+ | 中央 | | | ｷｬｯｼｭ | | +----------+ | 上に示したいずれの構成例においても、ドメインシステムの構成要素は、 それが可能である場合には常に信頼性のために複製されることに注意せよ。 2.3. 慣例 ドメインシステムは、下位層のものだが基本的な問題に対処する幾つかの 慣例を持つ。実装者は"自分のシステム内であれば"これらの慣例を自由に 侵害してよいが、他のホストから観測される"すべての"振る舞いについては、 これらの慣例を順守しなければならない。 2.3.1. 推奨される名前の構文 DNS仕様は、ドメイン名を構築するためのルールについては、可能な限り一般的で あるように努めている。アイディアは、既存のどのようなオブジェクトの名前で あっても、最小の変更でドメイン名として表現できるようにするというものである。 Mockapetris [Page 7] RFC 1035 Domain Implementation and Specification November 1987 しかし、オブジェクトにドメイン名を割り当てる際に、賢明なユーザーは ドメインシステムのルールと、オブジェクトに関する既存のルール(公開されて いるか既存のプログラムによって暗示されている)の両方を満足するような名前を 選択するだろう。 例えば、メールドメインに名前を付ける場合、ユーザーは本文書のルールとRFC-822 記載のルールの両方を満足すべきである。新しいホスト名を作成する場合、 HOSTS.TXTの古いルールに従うべきである。これらの作業は、古いソフトウェアを ドメインシステムを使用するものに切り替える際に生じる問題を回避する。 以下の構文に従うと、ドメイン名を使用する多数のアプリケーション (例えばメール、TELNET)で生じる問題がより少なくなるだろう。 ::= | " " ::=