2. Introduction (はじめに)
2. Introduction (はじめに)
2.1. Overview (概要)
ドメイン名 (domain names) の目標は, リソースに名前を付けるためのメカニズムを提供することです。この名前は, 異なるホスト (hosts), ネットワーク (networks), プロトコルファミリー (protocol families), インターネット (internets), および管理組織 (administrative organizations) で使用できます。
ユーザーの観点からは, ドメイン名はリゾルバー (resolver) と呼ばれるローカルエージェント (local agent) への引数として役立ちます。リゾルバーはドメイン名に関連付けられた情報を取得します。したがって, ユーザーは特定のドメイン名に関連付けられたホストアドレスまたはメール情報を要求できます。ユーザーが特定のタイプの情報を要求できるようにするために, 適切なクエリタイプ (query type) がドメイン名とともにリゾルバーに渡されます。ユーザーにとって, ドメインツリー (domain tree) は単一の情報空間 (information space) です。リゾルバーは, ネームサーバー (name servers) 間のデータの分散をユーザーから隠す責任があります。
リゾルバーの観点からは, ドメイン空間 (domain space) を構成するデータベースは, さまざまなネームサーバーに分散されています。ドメイン空間のさまざまな部分は異なるネームサーバーに保存されていますが, 特定のデータ項目は2つ以上のネームサーバーに冗長 (redundantly) に保存されます。リゾルバーは少なくとも1つのネームサーバーの知識から始まります。リゾルバーがユーザークエリを処理するとき, 既知のネームサーバーに情報を要求します。その見返りとして, リゾルバーは必要な情報を受け取るか, 別のネームサーバーへの参照 (referral) を受け取ります。これらの参照を使用して, リゾルバーは他のネームサーバーの識別情報と内容を学習します。リゾルバーは, ドメイン空間の分散を処理し, 他のサーバーの冗長データベースを参照することでネームサーバーの障害の影響に対処する責任があります。
ネームサーバーは2種類のデータを管理します。最初の種類のデータは, ゾーン (zones) と呼ばれるセットに保持されます。各ゾーンは, ドメイン空間の特定の「剪定された」(pruned) サブツリーの完全なデータベースです。このデータは権威 (authoritative) と呼ばれます。ネームサーバーは定期的にチェックして, ゾーンが最新であることを確認し, そうでない場合は, ローカルに保存されているマスターファイル (master files) または別のネームサーバーから更新されたゾーンの新しいコピーを取得します。2番目の種類のデータは, ローカルリゾルバーによって取得されたキャッシュデータ (cached data) です。このデータは不完全である可能性がありますが, 非ローカルデータに繰り返しアクセスする場合の検索プロセスのパフォーマンスを向上させます。キャッシュデータは最終的にタイムアウトメカニズム (timeout mechanism) によって破棄されます。
この機能構造は, ユーザーインターフェース (user interface), 障害回復 (failure recovery), および分散の問題をリゾルバーに分離し, データベースの更新と更新の問題をネームサーバーに分離します。
2.2. Common configurations (一般的な構成)
ホストは, ドメインシステムから情報を取得するプログラムを実行するか, 他のホストからのクエリに応答するネームサーバーを実行するか, またはこれら両方の機能のさまざまな組み合わせを実行するかに応じて, さまざまな方法でドメイン名システムに参加できます。最も単純で, おそらく最も典型的な構成を以下に示します:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |
ユーザープログラムは, リゾルバーを通じてドメイン名空間と対話します。ユーザークエリとユーザーレスポンスの形式は, ホストとそのオペレーティングシステムに固有です。ユーザークエリは通常オペレーティングシステムコール (operating system calls) であり, リゾルバーとそのキャッシュはホストオペレーティングシステムの一部となります。能力の低いホストは, リゾルバーをサブルーチン (subroutine) として実装し, そのサービスを必要とするすべてのプログラムとリンクすることを選択できます。リゾルバーは, 外部ネームサーバーへのクエリとローカルキャッシュを介して取得した情報を使用して, ユーザークエリに応答します。
特定のユーザークエリに応答するために, リゾルバーはいくつかの異なる外部ネームサーバーに複数のクエリを発行する必要がある場合があることに注意してください。したがって, ユーザークエリの解決には, 複数のネットワークアクセスと任意の時間が含まれる場合があります。外部ネームサーバーへのクエリと対応するレスポンスには, このメモで説明されている標準形式があり, データグラム (datagrams) である可能性があります。
その機能に応じて, ネームサーバーは専用マシン上のスタンドアロンプログラムであるか, 大規模なタイムシェアリングホスト上のプロセスまたは複数のプロセスである可能性があります。簡単な構成は次のようになります:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
ここで, プライマリネームサーバー (primary name server) は, ローカルファイルシステムからマスターファイルを読み取ることによって1つ以上のゾーンに関する情報を取得し, 外部リゾルバーから到着するそれらのゾーンに関するクエリに応答します。
DNSは, すべてのゾーンが複数のネームサーバーによって冗長にサポートされることを要求します。指定されたセカンダリサーバー (secondary servers) は, DNSのゾーン転送プロトコル (zone transfer protocol) を使用して, プライマリサーバーからゾーンを取得し, 更新を確認できます。この構成を以下に示します:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
この構成では, ネームサーバーは定期的に外部ネームサーバーへの仮想回線 (virtual circuit) を確立して, ゾーンのコピーを取得するか, 既存のコピーが変更されていないことを確認します。これらのメンテナンス活動のために送信されるメッセージは, クエリとレスポンスと同じ形式に従いますが, メッセージシーケンスは多少異なります。
ドメイン名システムのすべての側面をサポートするホストの情報フローを以下に示します:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
共有データベース (shared database) は, ローカルネームサーバーとリゾルバーのドメイン空間データを保持します。共有データベースの内容は通常, ネームサーバーの定期的な更新操作によって維持される権威データと, 以前のリゾルバー要求からのキャッシュデータの混合です。ドメインデータの構造とネームサーバーとリゾルバー間の同期の必要性は, このデータベースの一般的な特性を意味しますが, 実際の形式はローカル実装者に任されています。
情報フローは, ホストのグループが協力してアクティビティを最適化するように調整することもできます。これは, 能力の低いホストが完全なリゾルバーを実装する必要がないようにオフロードするために行われることがあります。これは, 必要な新しいネットワークコードの量を最小限に抑えたいPCまたはホストに適しています。このスキームでは, ホストのグループが多数の個別のキャッシュを維持するのではなく, 少数のキャッシュを共有することもできます。これは, 集中型キャッシュのヒット率 (hit ratio) が高くなるという前提に基づいています。いずれの場合も, リゾルバーはスタブリゾルバー (stub resolvers) に置き換えられます。スタブリゾルバーは, そのサービスを実行することが知られている1つ以上のネームサーバーの再帰サーバー (recursive server) にあるリゾルバーへのフロントエンドとして機能します:
Local Hosts | Foreign
|
+---------+ |
| | responses |
| Stub |<--------------------+ |
| Resolver| | |
| |----------------+ | |
+---------+ recursive | | |
queries | | |
V | |
+---------+ recursive +----------+ | +--------+
| | queries | |queries | | |
| Stub |-------------->| Recursive|---------|->|Foreign |
| Resolver| | Server | | | Name |
| |<--------------| |<--------|--| Server |
+---------+ responses | |responses| | |
+----------+ | +--------+
| Central | |
| cache | |
+----------+ |
いずれの場合も, 可能な限り, ドメインコンポーネントは信頼性のために常に複製されることに注意してください。
2.3. Conventions (規約)
ドメインシステムには, 低レベルではあるが基本的な問題を扱ういくつかの規約があります。実装者は自分のシステム内でこれらの規約に違反することは自由ですが, 他のホストから観察されるすべての動作でこれらの規約を遵守しなければなりません。
2.3.1. Preferred name syntax (推奨される名前構文)
DNS仕様は, ドメイン名を構築するためのルールにおいてできるだけ一般的であることを試みています。アイデアは, 既存のオブジェクトの名前を最小限の変更でドメイン名として表現できるということです。
ただし, オブジェクトにドメイン名を割り当てる場合, 慎重なユーザーは, ドメインシステムのルールとオブジェクトの既存のルールの両方を満たす名前を選択します。これらのルールは公開されているか, 既存のプログラムによって暗示されています。
たとえば, メールドメインに名前を付けるとき, ユーザーはこのメモのルールとRFC-822のルールの両方を満たす必要があります。新しいホスト名を作成するとき, HOSTS.TXTの古いルールに従う必要があります。これにより, 古いソフトウェアがドメイン名を使用するように変換されたときの問題を回避できます。
次の構文は, ドメイン名を使用する多くのアプリケーション (例: メール (mail), TELNET) で問題が少なくなります。
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
ドメイン名では大文字と小文字の両方が許可されていますが, 大文字と小文字は区別されないことに注意してください。つまり, スペルは同じで大文字と小文字が異なる2つの名前は同一として扱われます。
ラベルはARPANETホスト名のルールに従う必要があります。文字で始まり, 文字または数字で終わり, 内部文字は文字, 数字, およびハイフン (hyphen) のみです。長さにもいくつかの制限があります。ラベルは63文字以下でなければなりません。
たとえば, 次の文字列はInternet内のホストを識別します:
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.3.2. Data Transmission Order (データ送信順序)
このドキュメントで説明されているヘッダーとデータの送信順序は, オクテット (octet) レベルで解決されます。図がオクテットのグループを示す場合, それらのオクテットの送信順序は, 英語で読まれる通常の順序です。たとえば, 次の図では, オクテットは番号順に送信されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
オクテットが数値を表す場合, 図の最も左のビットは高次または最上位ビット (most significant bit) です。つまり, 0とラベル付けされたビットが最上位ビットです。たとえば, 次の図は値170 (10進数) を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
同様に, マルチオクテットフィールドが数値を表す場合, フィールド全体の最も左のビットが最上位ビットです。マルチオクテット量が送信される場合, 最上位オクテットが最初に送信されます。
2.3.3. Character Case (文字の大文字小文字)
公式プロトコルの一部であるDNSのすべての部分について, 文字列 (例: ラベル, ドメイン名など) 間のすべての比較は大文字と小文字を区別しない (case-insensitive) 方法で行われます。現在, このルールは例外なくドメインシステム全体で有効です。ただし, 現在の使用を超える将来の追加では, 名前で完全なバイナリオクテット機能を使用する必要がある場合があるため, ドメイン名を7ビットASCIIで保存したり, 特殊バイトを使用してラベルを終了したりする試みは避ける必要があります。
データがドメインシステムに入るとき, 可能な限り元の大文字小文字を保持する必要があります。特定の状況では, これを行うことはできません。たとえば, 2つのRRがデータベースに保存されている場合, 1つはx.yに, もう1つはX.Yにある場合, それらは実際にはデータベース内の同じ場所に保存されるため, 1つの大文字小文字のみが保持されます。基本的なルールは, 大文字小文字を破棄できるのは, データがデータベース内の構造を定義するために使用される場合のみであり, 大文字小文字を区別しない方法で比較したときに2つの名前が同一である場合のみです。
大文字小文字を区別するデータの損失は最小限に抑える必要があります。したがって, x.yとX.Yのデータは両方とも単一の場所x.yまたはX.Yに保存される可能性がありますが, a.xとB.Xのデータは決してA.x, A.X, b.x, またはb.Xに保存されません。一般に, これによりドメイン名の最初のラベルの大文字小文字が保持されますが, 内部ノードラベルの標準化が強制されます。
ドメインデータベースにデータを入力するシステム管理者は, システムが大文字小文字を区別する場合, ドメインシステムに提供するデータを大文字小文字が一貫した方法で表現するように注意する必要があります。ドメインシステムのデータ配布システムにより, 一貫した表現が保持されます。
2.3.4. Size limits (サイズ制限)
DNSのさまざまなオブジェクトとパラメーターにはサイズ制限があります。以下にリストします。一部は簡単に変更できますが, 他の一部はより基本的です。
| オブジェクト | 制限 |
|---|---|
| labels (ラベル) | 63オクテット以下 |
| names (名前) | 255オクテット以下 |
| TTL | 符号付き32ビット数の正の値 |
| UDP messages (UDPメッセージ) | 512オクテット以下 |