RFC1034

RFC1034 ドメイン名 - 概念と機能

1. このメモの状況

このRFCはドメインネームシステム（DNS）の紹介であり、付随するRFC “Domain Names - Implementation and Specification” [RFC-1035]に見られる多くの詳細を省略する。そのRFCは読者がこのメモで議論された概念に精通していると仮定します。

DNS機能とデータ型のサブセットは公式のプロトコルを構成します。公式のプロトコルは標準的な質問とそれらの応答とインターネットクラスデータフォーマット（例えばホストアドレス）のほとんどを含んでいます。

ただし、ドメインシステムは意図的に拡張可能です。研究者は新しいデータ型、問い合わせ型、クラス、関数などを継続的に提案、実装、実験しています。公式プロトコルの構成要素は基本的に変更されずにプロダクションサービスとして機能すると予想されます。公式プロトコルを超えた拡張実験的または時代遅れの機能は、これらのRFCで明確にマークされており、そのような情報は慎重に使用されるべきです。

読者は、その目的が主に教育的であるので、例に現われるか完全であるように見える値に依存しないように特に注意されます。このメモの配布は無制限です。

2. 前書き

このRFCはドメインスタイル名、インターネットメールとホストアドレスサポートのためのそれらの使用、そしてドメイン名機能を実装するのに使用されるプロトコルとサーバーを紹介します。

2.1.ドメイン名の歴史

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

アドレスマッピングへのホスト名は、ネットワークインフォメーションセンター（NIC）によって、すべてのホストによってFTPされた単一ファイル（HOSTS.TXT）で管理されていました[RFC-952、RFC-953]。総ネットワーク

この方式で新しいバージョンを配布する際に消費される帯域幅は、ネットワーク内のホスト数の2乗に比例し、複数レベルのFTPが使用されている場合でも、NICホストの発信FTP負荷はかなりのものです。ホスト数の爆発的な増加は、将来を見越した好材料ではありませんでした。

ネットワークの人口もまた変化していました。元のアルパネットを構成していたタイムシェアリングされたホストは、ワークステーションのローカルネットワークに置き換えられていました。地元の組織は自分の名前とアドレスを管理していましたが、NICがHOSTS.TXTを変更してインターネット全体に変更が反映されるのを待つ必要がありました。組織はまた、ネームスペース上のローカル構造を求めていました。

インターネット上のアプリケーションはより洗練されつつあり、汎用ネームサービスの必要性を生み出しています。

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

「ドメイン」または「ドメイン名」という用語は、ここで説明したDNS以外にも多くの文脈で使用されています。多くの場合、ドメイン名という用語は、ドットで示された構造を持つ名前を指すために使用されますが、DNSとは関係ありません。これは、メールアドレス指定に特に当てはまります[Quarterman 86]。

2.2. DNS設計の目標

DNSの設計目標はその構造に影響を与えます。彼らです：

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

データベースのサイズと更新の頻度が非常に大きいため、パフォーマンスを向上させるには、ローカルキャッシュを使用して分散管理する必要があります。それに近づく

データベース全体の一貫したコピーを収集しようとすると、ますます高価になり困難になるため、避けるべきです。同じ原則は、名前空間の構造、特に名前の作成と削除のメカニズムにも当てはまります。これらも配布する必要があります。

データ取得コスト、更新速度、およびキャッシュの正確性の間にトレードオフがある場合、データのソースがトレードオフを制御する必要があります。

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

私たちは名前空間が異なったネットワークとアプリケーションで役に立つのが欲しいので、私たちは異なったプロトコルファミリーか管理で同じ名前空間を使用する能力を提供します。たとえば、ホストアドレスの形式はプロトコルによって異なりますが、すべてのプロトコルにアドレスという概念があります。DNSはすべてのデータにタイプと同様にクラスでタグ付けするので、アドレスタイプのデータに異なるフォーマットを並行して使用することができます。

ネームサーバトランザクションは、それらを伝送する通信システムから独立している必要があります。いくつかのシステムが質問と応答のためにデータグラムを使いたくて、信頼性を必要とするトランザクション（例えば、データベース更新、長いトランザクション）のために仮想回路だけを確立することを望むかもしれません。他のシステムは仮想回線を排他的に使用します。

このシステムは、幅広いホスト機能に渡って役立つはずです。パーソナルコンピュータと大規模なタイムシェアリングされたホストの両方が、おそらく別の方法でもシステムを使用できるはずです。

2.3. 使用に関する前提

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

仮定は次のとおりです。

データベース全体のサイズは最初は比例します

ただし、メールボックスやその他の情報がドメインシステムに追加されると、それらのホスト上のユーザー数に比例するようになります。

システム内のデータの大部分は非常にゆっくりと変化しますが（例：メールボックスバインディング、ホストアドレス）、システムはより急速に変化するサブセットを処理できるはずです（数秒または数分程度）。

データベースに対する責任を分散するために使用される管理上の境界は、通常、1つ以上のホストを持つ組織に対応します。特定のドメインのセットに対して責任を持つ各組織は、その組織自身のホストまたはその組織が使用するように手配するその他のホストのいずれかに、冗長ネームサーバーを提供します。

ドメインシステムのクライアントは、この「信頼できる」セット以外のネームサーバへの紹介を受け入れる前に、使用したい信頼できるネームサーバを識別できなければなりません。

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

分散データベースを持つシステムでは、特定のネームサーバに他のサーバでしか答えられないクエリを提示することができます。この問題に対処するための2つの一般的なアプローチは、「再帰的」（最初のサーバーが別のサーバーでクライアントへのクエリを追求する）と、サーバーがクライアントを別のサーバーに照会してクライアントに任せることです。問い合わせます。どちらの方法にも長所と短所がありますが、データグラム形式のアクセスには反復的な方法が適しています。ドメインシステムは反復的なアプローチの実装を必要としますが、オプションとして再帰的なアプローチを可能にします。

ドメインシステムは、すべてのデータが、そのドメインシステムを使用するホストに分散しているマスターファイルから発生していると見なします。これらのマスターファイルは、ローカルシステム管理者によって更新されます。マスターファイルは、ローカルネームサーバーによって読み取られるテキストファイルで、ネームサーバーを介してドメインシステムのユーザーが利用できるようになります。ユーザプログラムはリゾルバと呼ばれる標準的なプログラムを通してネームサーバにアクセスします。

マスターファイルの標準フォーマットはそれらをホスト間で交換することを可能にします（FTP、メール、または他の何らかのメカニズムを通して）。この機能は、組織がドメインを必要としているがネームサーバーをサポートしたくない場合に役立ちます。組織は、テキストエディタを使用してマスターファイルをローカルに管理し、それらをネームサーバを実行する外部ホストに転送してから、ネームサーバのシステム管理者に依頼してファイルをロードさせることができます。

各ホストのネームサーバーとリゾルバはローカルシステム管理者[RFC-1033]によって設定されます。ネームサーバーの場合、この構成データには、ローカルマスターファイルのIDと、ローカルサーバー以外のマスターファイルを外部サーバーからロードする指示が含まれています。ネームサーバーは、マスターファイルまたはコピーを使用してそのゾーンを読み込みます。リゾルバの場合、設定データは、情報の主な情報源となるべきネームサーバを識別します。

ドメインシステムはデータにアクセスして他のネームサーバに紹介するための手順を定義します。ドメインシステムはまた、検索されたデータをキャッシュし、システム管理者によって定義されたデータを定期的にリフレッシュするための手順を定義する。

システム管理者は以下を提供します。

ゾーン境界の定義

データのマスターファイル

マスターファイルへの更新

希望するリフレッシュポリシーのステートメント。

ドメインシステムは以下を提供します。

リソースデータの標準形式

データベースを照会するための標準的な方法。

ネームサーバーが外部ネームサーバーからローカルデータを更新するための標準的な方法。

2.4. DNSの要素

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

DOMAIN NAME SPACEおよびRESOURCE RECORDS。これは、ツリー構造の名前空間および名前に関連付けられたデータの仕様です。概念的には、ドメインネームスペースツリーの各ノードおよびリーフは情報のセットに名前を付け、クエリ操作は特定のセットから特定の種類の情報を抽出することを試みます。照会は、関心のあるドメイン名を指定し、必要なリソース情報のタイプを記述します。たとえば、インターネットはホストを識別するためにそのドメイン名のいくつかを使用します。アドレスリソースに対する問い合わせはインターネットホストアドレスを返します。

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

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

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

ユーザーの観点からは、ドメインシステムには簡単な手順またはローカルリゾルバへのOS呼び出しを通じてアクセスします。ドメインスペースは単一のツリーで構成され、ユーザーはツリーの任意のセクションから情報を要求できます。

リゾルバの観点からは、ドメインシステムは未知数のネームサーバで構成されています。各ネームサーバーは、ドメインツリー全体のデータのうち1つ以上のデータを持っていますが、リゾルバーはこれらの各データベースを本質的に静的であると見なします。

ネームサーバーの観点からは、ドメインシステムはゾーンと呼ばれるローカル情報の個別のセットで構成されています。ネームサーバーには、一部のゾーンのローカルコピーがあります。ネームサーバーは、ローカルファイルまたは外部ネームサーバーのマスターコピーからゾーンを定期的に更新する必要があります。ネームサーバはリゾルバから到着する問い合わせを同時に処理しなければなりません。

性能のために、実装はこれらの機能を結び付けるかもしれません。たとえば、ネームサーバと同じマシン上のリゾルバは、ネームサーバによって管理されているゾーンとリゾルバによって管理されているキャッシュからなるデータベースを共有することができます。

ドメインネームスペースとリソースレコード

3.1.名前空間の仕様と用語

ドメインネームスペースはツリー構造です。ツリー上の各ノードとリーフは、リソースセット（空の場合もあります）に対応します。ドメインシステムは内部ノードと葉の用法を区別しません、そしてこのメ??モは両方を指すために用語 “ノード”を使います。

各ノードにはラベルがあります。ラベルの長さは0?63オクテットです。兄弟ノードは同じラベルを持つことはできませんが、兄弟ではないノードには同じラベルを使用できます。一つのラベルは予約されており、それはルートに使用されるヌル（すなわち長さゼロ）ラベルです。

ノードのドメイン名は、ノードからツリーのルートへのパス上のラベルのリストです。慣例により、ドメイン名を構成するラベルは、最も特定度の高いもの（最低、ルートから最も遠いもの）から最も特定の少ないもの（最高、ルートに最も近いもの）の順に印刷または左から右へと読みます。

内部的には、ドメイン名を操作するプログラムは、それらをラベルのシーケンスとして表現する必要があります。各ラベルは、長さオクテットとそれに続くオクテット文字列です。すべてのドメイン名は、ラベルのNULL文字列を持つルートで終わるため、これらの内部表現は、ドメイン名を終了するために長さゼロのバイトを使用できます。

慣例により、ドメイン名は任意の大文字と小文字を区別して格納できますが、現在のすべてのドメイン関数のドメイン名比較は、ASCII文字セットと上位ゼロビットを想定して、大文字と小文字を区別しない方法で行われます。つまり、ラベル「A」のノードまたはラベル「a」のノードは自由に作成できますが、両方とも兄弟としては作成できません。「a」または「A」を使用して参照することができます。ドメイン名を受け取ったとき

ラベルは、あなたはそのケースを保存する必要があります。この選択の理論的根拠は、いつか新しいサービスのために完全なバイナリドメイン名を追加する必要があるかもしれないということです。既存のサービスは変更されません。

ユーザーがドメイン名を入力する必要があるときは、各ラベルの長さは省略され、ラベルはドット（ “。”）で区切られます。完全なドメイン名はルートラベルで終わるので、これはドットで終わる印刷されたフォームにつながります。このプロパティを使って次のものを区別します。

完全なドメイン名を表す文字列（「絶対」と呼ばれることが多い）。たとえば、 “poneria.ISI.EDU”です。

不完全なドメイン名の開始ラベルを表す文字列。ローカルドメインの知識を使用してローカルソフトウェアによって完成される必要がある（「相対」と呼ばれることが多い）。たとえば、 “poneria”はISI.EDUドメインで使用されています。

相対名は、よく知られている起源、または検索リストとして使用されているドメインのリストを基準にしています。相対名は、主にユーザーインターフェイスに表示されます。ユーザーインターフェイスでは、その解釈は実装ごとに異なります。マスターファイルでは、単一のオリジンドメイン名に対して相対的です。最も一般的な解釈ではルート “。”が使用されます。単一起点として、または検索リストのメンバーの1つとして、マルチラベル相対名は、入力を節約するために末尾のドットが省略されたものです。

実装を簡単にするために、ドメイン名を表す八重奏の総数（すなわち、すべてのラベル八重奏とラベル長の合計）は255に制限されます。

ドメインはドメイン名によって識別され、ドメインを指定するドメイン名以下のドメインネームスペースの部分から構成されます。ドメインがそのドメイン内に含まれている場合、そのドメインは別のドメインのサブドメインです。この関係は、サブドメインの名前がそれを含むドメインの名前で終わっているかどうかを確認することによってテストできます。たとえば、ABCDはBCD、CD、D、および ““のサブドメインです。

3.2. 使用に関する管理上のガイドライン

方針の問題として、DNS技術仕様はラベルを選択するための特定の木構造や規則を強制しません。その目的は、できるだけ一般的なものにすることであり、それによって任意のアプリケーションの構築に使用することができます。特に、名前空間がネットワーク境界、ネームサーバなどの線に沿って編成される必要がないようにシステムが設計されました。これの根拠は、名前空間が暗黙の意味論を持たないべきではないということです。暗黙のセマンティクスの選択は問題のために使用されるために開いたままにされるべきです

そしてツリーの異なる部分は異なる暗黙の意味を持つことができます。たとえば、IN-ADDR.ARPAドメインは、ネットワークまたはホスト番号から名前に変換することがその役割であるため、ネットワークおよびホストアドレスによって編成および配布されています。NetBIOSドメイン[RFC-1001、RFC-1002]は、そのアプリケーションに適しているのでフラットです。

ただし、ホスト、メールボックスなどに使用されるネームスペースの「通常の」部分に適用されるガイドラインがいくつかあります。これにより、ネームスペースをより均一にし、成長に備え、ソフトウェアを古いものから変換するときの問題を最小限に抑えます。ホストテーブルツリーのトップレベルに関する政治的決定は、RFC-920に由来します。最上位レベルの現在の方針は[RFC-1032]で議論されています。MILNET変換の問題は[RFC-1031]でカバーされています。

最終的に複数のゾーンに分割される下位ドメインは、最終的な分解が名前変更なしで行われることができるようにドメインの上部で分岐を提供するべきです。特殊文字、先行数字などを使用するノードラベルは、より厳格な選択に依存する古いソフトウェアを壊す可能性があります。

3.3. 使用に関する技術的ガイドライン

DNSを使用してある種のオブジェクトの命名情報を保持できるようにするには、2つのニーズを満たす必要があります。

オブジェクト名とドメイン名の間のマッピングのための規約。これは、オブジェクトに関する情報へのアクセス方法を説明しています。

オブジェクトを説明するためのRRタイプとデータフォーマット。

これらの規則は、非常に単純な場合もあれば、かなり複雑な場合もあります。多くの場合、設計者は既存のフォーマットを考慮に入れ、既存の使用法に対する上位互換性を計画する必要があります。複数のマッピングまたはマッピングのレベルが必要になる場合があります。

ホストの場合、マッピングはドメイン名の通常のテキスト表現のサブセットであるホスト名の既存の構文、およびホストアドレスなどを記述するためのRR形式に依存します。アドレスからホスト名への信頼できる逆マッピングが必要です。 IN-ADDR.ARPAドメインへのアドレスの特別なマッピングも定義されています。

メールボックスの場合、マッピングは少し複雑です。通常のメールアドレス@は、単一のラベル（ドットを含む）に変換し、ドメイン名に通常のテキスト形式を使用してドメイン名に変換し（ドットはラベルの区切りを表す）、2つを連結してドメイン名にマッピングされます。単一のドメイン名を形成します。したがって、メールボックス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

この例では、ルートドメインに3つの直接サブドメインがあります。MIL、EDU、およびARPAです。LCS.MIT.EDUドメインには、XX.LCS.MIT.EDUという名前の直接サブドメインが1つあります。すべての葉もドメインです。

3.5. 優先名の構文

DNSの仕様は、規則の範囲内でできるだけ一般的になるようにしています

ドメイン名を構築するためのものです。アイデアは、既存のオブジェクトの名前を最小限の変更でドメイン名として表現できるということです。ただし、オブジェクトにドメイン名を割り当てる場合、慎重なユーザーは、ドメインシステムの規則とそのオブジェクトの既存の規則の両方を満たす名前を選択します。これらの規則が公開されているか既存のプログラムによって暗示されているかは関係ありません。

例えば、メールドメインを命名するとき、ユーザはこのメモの規則とRFC-822の規則の両方を満たすべきです。新しいホスト名を作成するときは、HOSTS.TXTの古い規則に従う必要があります。これにより、古いソフトウェアをドメイン名を使用するように変換したときの問題を回避できます。

以下の構文はドメイン名（例えばメール、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ホスト名の規則に従う必要があります。それらは文字で始まり、文字または数字で終わり、内部文字としては文字、数字、およびハイフンだけを持つ必要があります。長さにもいくつかの制限があります。ラベルは63文字以下にする必要があります。

たとえば、次の文字列はインターネット内のホストを識別します。

A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA

3.6. リソースレコード

ドメイン名はノードを識別します。各ノードにはリソースのセットがあります

空の場合があります。特定の名前に関連付けられた一連のリソース情報は、別々のリソースレコード（RR）で構成されています。セット内のRRの順序は重要ではなく、ネームサーバ、リゾルバ、またはDNSの他の部分によって保持される必要はありません。

私たちが特定のRRについて話すとき、私たちはそれが以下を持っていると思います：

オーナー

これはRRが見つかったドメイン名です。

タイプ

これは、このリソースレコード内のリソースのタイプを指定するエンコードされた16ビット値です。型は抽象リソースを参照します。

このメモは以下の型を使用します。

記録

ホストアドレス

CNAME

別名の正規名を識別します

HINFO

ホストによって使用されるCPUとOSを識別します。

ドメインのメール交換を識別します。詳細は[RFC-974]を参照してください。

ドメインの権威ネームサーバ

PTR

ドメインネームスペースの別の部分へのポインタ

SOA

権限のゾーンの始まりを識別する

クラス

これは、プロトコルファミリまたはプロトコルのインスタンスを識別するエンコードされた16ビット値です。

このメモは以下のクラスを使用します。

に

インターネットシステム

カオスシステム

TTL

これがRRの住むべき時です。この分野は秒の単位で32ビット整数です、それらがRRをキャッシュするとき、主にリゾルバによって使用されます。TTLは、RRが破棄されるまでにキャッシュに保存できる期間を示します。

RDATA

これは、リソースを記述する型と、場合によってはクラス依存のデータです。

INクラスの場合、32ビットIPアドレス

CHクラスの場合は、ドメイン名の後に16ビットの8進カオスアドレスが続きます。

CNAME

ドメイン名

16ビットの優先値（低いほど良い）の後に、所有者ドメインのメール交換として機能するホスト名が続きます。

ホスト名

PTR

ドメイン名

SOA

いくつかの分野。

所有者名は、RRの不可欠な部分を形成するのではなく、多くの場合暗黙的です。例えば、多くのネームサーバは内部的にネームスペースのためのツリーまたはハッシュ構造を形成し、ノードからRRをチェインします。残りのRR部分は、すべてのRRに一致する固定ヘッダー（タイプ、クラス、TTL）、および記述されているリソースのニーズに合う可変部分（RDATA）です。

TTLフィールドの意味は、RRをキャッシュに保持できる期間の制限です。この制限は、ゾーン内の信頼できるデータには適用されません。それはまたタイムアウトしました、しかしゾーンのためのさわやかな方針によって。TTLは、データが発信されたゾーンに対して管理者によって割り当てられます。短いTTLを使用してキャッシュを最小限に抑えることができ、ゼロのTTLはキャッシュを禁止しますが、インターネットパフォーマンスの現実から、これらの時間は通常のホストでは数日程度であることが推奨されます。変更が予想される場合は、変更前のTTLを変更前の矛盾を最小限に抑えるために減らしてから、変更後のTTLを以前の値に戻すことができます。

RRのRDATAセクションのデータは、バイナリ文字列とドメイン名の組み合わせとして運ばれます。ドメイン名は、DNS内の他のデータへの「ポインタ」として頻繁に使用されます。

3.6.1.RRのテキスト表現

RRはDNSプロトコルのパケットではバイナリ形式で表され、ネームサーバやリゾルバに格納されている場合は通常、高度にエンコードされた形式で表されます。このメモでは、使用されているのと似たスタイルを採用しています。

RRの内容を表示するためのマスターファイルこの形式では、括弧を使用して継続行が可能ですが、ほとんどのRRは1行に表示されます。

行の先頭がRRの所有者になります。行が空白で始まる場合、所有者は前のRRの所有者と同じであると見なされます。読みやすくするために、空白行が含まれることがよくあります。

所有者に続いて、RRのTTL、タイプ、およびクラスをリストします。クラスとタイプは上で定義されたニーモニックを使用します、そして、TTLはタイプフィールドの前の整数です。解析のあいまいさを避けるために、型とクラスのニーモニックは互いに素で、TTLは整数で、型のニーモニックは常に最後です。明確にするために、INクラスとTTL値は例から省略されることがよくあります。

資源データまたは資源レコードのRDATAセクションはデータの典型的な表現の知識を使って与えられます。

例えば、メッセージの中で搬送されるRRを次のように示すことができます。

    ISI.EDU.        MX      10 VENERA.ISI.EDU.
                    MX      10 VAXA.ISI.EDU.
    VENERA.ISI.EDU. A       128.9.0.32
                    A       10.1.0.52
    VAXA.ISI.EDU.   A       10.2.0.27
                    A       128.9.0.33


    XX.LCS.MIT.EDU. IN      A       10.0.0.44
                    CH      A       MIT.EDU. 2420

MX RRには、16ビットの数字とそれに続くドメイン名で構成されるRDATAセクションがあります。アドレスRRは、32ビットのインターネットアドレスを含めるために標準のIPアドレスフォーマットを使用します。

この例は6つのRRを示し、3つのドメイン名のそれぞれに2つのRRがあります。

同様に私達は見るかもしれません：

    XX.LCS.MIT.EDU. IN      A       10.0.0.44
                    CH      A       MIT.EDU. 2420

この例では、XX.LCS.MIT.EDUの2つのアドレス（それぞれ異なるクラス）を示しています。

3.6.2. エイリアスと正規名

既存のシステムでは、ホストと他のリソースは同じリソースを識別する複数の名前を持つことがよくあります。たとえば、C.ISI.EDUとUSC-ISIC.ARPAという名前はどちらも同じホストを識別します。同様に、メールボックスの場合、多くの組織が実際に同じメールボックスに行く名前を多数提供しています。例えばMockapetris@C.ISI.EDU、Mockapetris@B.ISI.EDU、

とPVM@ISI.EDUはすべて同じメールボックスに行きます（ただし、このメカニズムはやや複雑ですが）。

これらのシステムのほとんどは、同等の名前のセットの1つが標準名または基本名であり、他のすべてのものが別名であるという概念を持っています。

ドメインシステムは、正規名（CNAME）RRを使用してそのような機能を提供します。CNAME RRは、その所有者名を別名として識別し、RRのRDATAセクション内の対応する正規名を指定します。CNAME RRがノードに存在するなら、他のデータは存在するべきではありません。これにより、正規名とその別名のデータが異なることはありません。この規則はまた、キャッシュされたCNAMEが他のRRタイプについて権威のあるサーバーに問い合わせることなく使用されることを保証します。

CNAME RRはDNSソフトウェアで特別な動作を引き起こします。ネームサーバーは、ドメイン名に関連付けられたリソースセット内で目的のRRを見つけられなかった場合、リソースセットが一致するクラスを持つCNAMEレコードで構成されているかどうかを確認します。そうであるなら、ネームサーバは応答にCNAMEレコードを含めて、CNAMEレコードのデータフィールドで指定されたドメイン名で質問を再開します。この規則の1つの例外は、CNAMEタイプと一致する照会が再開されないことです。

たとえば、ネームサーバがタイプA情報を要求してUSC-ISIC.ARPAに対するクエリを処理していて、次のリソースレコードがあるとします。

    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

    C.ISI.EDU       IN      A       10.0.0.52

タイプCNAMEまたは*クエリはCNAMEだけを返すべきですが、これら両方のRRはタイプAクエリへの応答で返されます。

別の名前を指すRR内のドメイン名は、エイリアスではなく常にプライマリ名を指す必要があります。これにより、情報へのアクセスにおける余分な間接的な操作が回避されます。たとえば、上記のホストのRRという名前のアドレスは次のようになります。

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

USC-ISIC.ARPAを指すのではなく。もちろん、堅牢性の原則により、ドメインソフトウェアは、CNAMEチェーンまたはループと一緒に提示されても失敗しないはずです。CNAMEチェーンをたどる必要があり、CNAMEループはエラーとして通知されます。

3.7. 問い合わせ

問い合わせはネームサーバに送られるかもしれないメッセージです。

応答。インターネットでは、問い合わせはUDPデータグラムまたはTCP接続で行われます。ネームサーバによる応答は、問い合わせで提起された質問に答えるか、リクエスタを別のネームサーバのセットに照会するか、または何らかのエラー状態を通知するかのいずれかです。

一般に、ユーザは直接質問を生成しませんが、代わりにネームサーバに1つ以上の質問を順番に送って、生じるかもしれない誤り状態と紹介を扱うリゾルバに要求をします。もちろん、問い合わせで尋ねられる可能性のある質問は、リゾルバが提供できる種類のサービスを形作ります。

DNSの問い合わせと応答は標準のメッセージフォーマットで運ばれます。メッセージフォーマットは、常に存在するいくつかの固定フィールドを含むヘッダと、クエリパラメータとRRを運ぶ4つのセクションを持ちます。

ヘッダー内の最も重要なフィールドは、さまざまな照会を分離するオペコードと呼ばれる4ビットのフィールドです。可能な16個の値のうち、1つ（標準照会）は公式プロトコルの一部、2つ（逆照会および状況照会）はオプション、1つ（完了）は廃止され、残りは未割り当てです。

4つのセクションは以下のとおりです。

質問

クエリ名と他のクエリパラメータを持ちます。

回答

直接質問に答えるRRsを運びます。

権限

他の信頼できるサーバを記述するRRを運びます。答えセクションの信頼できるデータのために任意にSOA RRを運ぶかもしれません。

追加の

他のセクションでRRを使用するのに役立つかもしれないRRを運びます。

これらのセクションの内容はフォーマットではなく、ヘッダーのオペコードによって異なります。

3.7.1.標準クエリ

標準クエリは、ターゲットドメイン名（QNAME）、クエリタイプ（QTYPE）、およびクエリクラス（QCLASS）を指定し、一致するRRを要求します。この種のクエリは、特に指定しない限り標準クエリを意味するために “クエリ”という用語を使用するように、DNSクエリの大部分を構成しています。QTYPEとQCLASSフィールドはそれぞれ16ビット長で、定義されたタイプとクラスのスーパーセットです。

QTYPEフィールドは次のものを含みます。

任意の種類

そのタイプだけにマッチします。（例：A、PTR）

AXFR

特殊ゾーン転送QTYPE

メール

メールボックスに関連するすべてのRRに一致します（例：MBおよびMG）。

すべてのRRタイプに一致します。

QCLASSフィールドは次のものを含むことができます。

任意のクラス

そのクラスだけに一致します（例：IN、CH）。

aLL RRクラスにマッチします。

ネームドメインは、クエリドメイン名、QTYPE、およびQCLASSを使用して、一致するRRを探します。適切な記録に加えて、ネームサーバは望ましい情報を持っているネームサーバか適切なRRを解釈するのに役立つと予想されるRRを指すRRを返すかもしれません。例えば、要求された情報を持っていないネームサーバは、持っているネームサーバを知っているかもしれません。関連RRでドメイン名を返すネームサーバは、そのドメイン名をアドレスに結び付けるRRも返すかもしれません。

たとえば、Mockapetris @ISI.EDUにメールを送信するように結び付けているメーラがISI.EDUに関するメール情報をリゾルバに要求し、QNAME = ISI.EDU、QTYPE = MX、QCLASS = INのクエリになる可能性があります。回答の回答セクションは次のようになります。

    ISI.EDU.        MX      10 VENERA.ISI.EDU.
                    MX      10 VAXA.ISI.EDU.

追加セクションは以下のようになります。

    VAXA.ISI.EDU.   A       10.2.0.27
                    A       128.9.0.33
    VENERA.ISI.EDU. A       10.1.0.52
                    A       128.9.0.32

サーバは、リクエスタがメール交換情報を望んでいるならば、その直後にメール交換のアドレスが欲しいと思うだろうと仮定するので。

QCLASS = *構文は権限に関して特別な解釈を必要とすることに注意してください。特定のネームサーバはドメインシステムで利用可能なすべてのクラスを知らないかもしれないので、それがすべてのクラスに対して権威があるかどうかを知ることはできません。したがって、QCLASS = *クエリに対する応答は

権威あることはありません。

3.7.2. 逆クエリ（オプション）

ネームサーバはまた、特定のリソースをそのリソースを持つ1つまたは複数のドメイン名にマッピングする逆クエリーもサポートします。たとえば、標準クエリでドメイン名をSOA RRにマッピングする一方で、対応する逆クエリでSOA RRをドメイン名にマッピングすることができます。

このサービスの実装はネームサーバではオプションですが、すべてのネームサーバは少なくとも逆の問い合わせメッセージを理解し、未実装のエラー応答を返すことができなければなりません。

ドメインシステムはホストアドレスやその他のリソースタイプではなくドメイン名で編成されているため、ドメインシステムは逆クエリの完全性または一意性を保証できません。逆照会は、主にデバッグおよびデータベース保守作業に役立ちます。

逆の質問は適切なTTLを返さないかもしれなくて、特定されたRRが1セット（例えば、複数のアドレスを持っているホストのための1つのアドレス）の1つであるケースを示さないでください。したがって、逆の問い合わせで返されたRRは決してキャッシュされるべきではありません。

逆引き照会は、ホストアドレスをホスト名にマッピングするための適切な方法ではありません。代わりにIN-ADDR.ARPAドメインを使用してください。

逆問い合わせの詳細な議論は[RFC-1035]に含まれています。

3.8. ステータスクエリ（試験的）

定義します。

3.9. 完了クエリ（廃止）

RFC 882および883に記載されているオプションの完了サービスは削除されました。再設計されたサービスは将来利用可能になるかもしれないし、オペコードは他の用途のために回収されるかもしれません。

ネームサーバー

4.1.前書き

ネームサーバーは、ドメインデータベースを構成する情報のリポジトリです。データベースはゾーンと呼ばれるセクションに分割され、それらはネームサーバーに分散されます。ネームサーバはいくつかのオプションの機能とデータのソースを持つことができますが、ネームサーバの本質的な仕事はゾーンのデータを使って問い合わせに答えることです。意図的に、

ネームサーバは簡単な方法で質問に答えることができます。応答は常にローカルデータのみを使用して生成することができ、質問への回答、または目的の情報に「近い」他のネームサーバへの参照を含みます。

与えられたゾーンは、ホストや通信リンクの障害にもかかわらず、その可用性を保証するためにいくつかのネームサーバーから利用可能になります。管理上の理由から、すべてのゾーンが少なくとも2台のサーバーで使用可能であることが必要です。また、多くのゾーンにはそれ以上の冗長性があります。

特定のネームサーバーは通常1つ以上のゾーンをサポートしますが、これによりドメインツリーのごく一部に関する信頼できる情報が得られます。また、ツリーの他の部分に関する、権限のないデータがキャッシュされていることもあります。ネームサーバは、応答が信頼できるデータから来たものかどうかを要求者が判断できるように、その応答をクエリにマークします。

4.2. データベースをゾーンに分割する方法

ドメインデータベースは2つの方法で区分されます：クラスによるものと、ノード間の名前空間に作られた「カット」によるものです。

クラスパーティションは単純です。どのクラスのデータベースも、他のすべてのクラスとは別に編成、委任、および保守されています。慣例により、名前空間はすべてのクラスで同じなので、別々のクラスは並列名前空間ツリーの配列と見なすことができます。ノードに添付されたデータは、これらの異なる並列クラスでは異なることに注意してください。新しいクラスを作成する最も一般的な理由は、既存の型のための新しいデータフォーマットの必要性、または既存の名前空間の個別に管理されたバージョンに対する要望です。

クラス内では、ネームスペースの「カット」は任意の隣接する2つのノード間で行うことができます。すべてのカットが行われた後、接続された名前空間の各グループは別々のゾーンになります。ゾーンは、接続領域内のすべての名前に対して権限があると言われています。名前空間の「切り取り」はクラスごとに異なる場所にある場合があり、ネームサーバーが異なる場合などがあります。

これらの規則は、すべてのゾーンに少なくとも1つのノード、つまりドメイン名があり、それに対して権限があり、特定のゾーン内のすべてのノードが接続されていることを意味します。ツリー構造では、すべてのゾーンに、ゾーン内の他のどのノードよりもルートに近い最上位ノードがあります。このノードの名前は、ゾーンを識別するためによく使用されます。

各ドメイン名が別々のゾーンに存在するように、またはすべてのノードが単一のゾーンに存在するように名前空間を分割することは、特に便利ではありませんが、可能です。その代わりに、データベースは特定の組織が管理を引き継ぎたいと思う点で分割されます。

サブツリー組織が独自のゾーンを制御すると、そのゾーン内のデータを一方的に変更したり、そのゾーンに接続された新しいツリーセクションを拡張したり、既存のノードを削除したり、そのゾーンの下に新しいサブゾーンを委任したりできます。

組織に下位構造がある場合は、名前空間制御のネストされた委任を達成するために、さらに内部パーティションを作成することをお勧めします。場合によっては、このような分割は純粋にデータベース保守をより便利にするために行われます。

4.2.1.技術的な考慮事項

ゾーンを記述するデータには、4つの主要部分があります。

ゾーン内のすべてのノードに関する正式なデータ。

ゾーンの最上位ノードを定義するデータ（正式なデータの一部と見なすことができます）。

委任されたサブゾーンを記述するデータ。つまり、ゾーンの下部をカットします。

サブゾーンのネームサーバへのアクセスを許可するデータ（「グルー」データとも呼ばれる）。

このデータはすべてRRの形式で表現されるため、ゾーンはRRのセットによって完全に記述できます。一連のメッセージで運ばれるか、またはテキスト表現であるマスターファイルをFTPすることによって、RRを転送することによって、ゾーン全体をネームサーバー間で転送することができます。

ゾーンの信頼できるデータは、ゾーンの最上位ノードから最下位ノードまたはその下のノードまでのすべてのノードに接続されている、ゾーンの最下端付近のすべてのRRです。

論理的には信頼できるデータの一部ですが、ゾーンの最上位ノードを記述するRRは、ゾーンの管理にとって特に重要です。これらのRRには2つのタイプがあります。リストするネームサーバRR、RRごとに1つ、ゾーンのすべてのサーバ、およびゾーン管理パラメータを記述する単一のSOA RRです。

ゾーンの下部をカットすることを記述するRRは、サブゾーンのサーバを指定するNS RRです。カットはノード間にあるため、これらのRRはゾーンの信頼できるデータの一部ではなく、サブゾーンの最上位ノードにある対応するRRとまったく同じである必要があります。ネームサーバは常にゾーン境界に関連付けられているため、NS RRは一部のゾーンの最上位ノードであるノードでのみ検出されます。ゾーンを構成しているデータでは、NS RRはネットワークの最上位ノードにあります。

ゾーン（そして権威がある）とゾーンの底のまわりのカット（それらが権威がない）が、その間に決してありません。

ゾーン構造の目的の1つは、どのゾーンにも、サブゾーン用のネームサーバーとの通信を設定するために必要なすべてのデータがあることです。つまり、親ゾーンには、子ゾーンのサーバーにアクセスするために必要なすべての情報があります。サブゾーンのためにサーバを命名するNS RRは、それらがサーバを命名するが、それらのアドレスを与えないので、このタスクにはしばしば不十分です。特に、ネームサーバの名前がそれ自身のサブゾーンにある場合、NS RRがネームサーバのアドレスを知るためには、希望するアドレスを使用してサーバに連絡しなければならないという状況に直面する可能性があります。学ぶこの問題を解決するために、ゾーンには信頼できるデータの一部ではない「グルー」RRが含まれており、これらはサーバーのアドレスRRです。これらのRRはネームサーバの名前が “

4.2.2. 管理上の考慮事項

ある組織が自身のドメインを制御したい場合、最初のステップは適切な親ゾーンを識別し、そして親ゾーンの所有者に制御の委任に同意させることです。ツリーのどこでこれを行うことができるかを扱う特別な技術的制約はありませんが、トップレベルの組織を扱ういくつかの管理上の分類が[RFC-1032]で議論されています。たとえば、ある大学では単一のゾーンを使用することを選択し、別の大学では個々の部門または学校専用のサブゾーンで編成することを選択する場合があります。[RFC-1033]は利用可能なDNSソフトウェアをカタログ化し、管理手順を論じています。

新しいサブゾーンの正しい名前が選択されたら、新しい所有者は冗長なネームサーバーのサポートを実演することを要求されるべきです。ゾーンのサーバーがそのドメインに名前を持つホストに存在するという要件はありません。多くの場合、ゾーンを管理する同じ組織によって制御される物理的な施設内にあるのではなく、そのサーバーが広く分散されていると、ゾーンはインターネット全体にアクセスしやすくなります。たとえば、現在のDNSでは、イギリスのネームサーバーの1つ、またはイギリスのドメインがアメリカにあります。これにより、米国のホストは、限られた大西洋横断の帯域幅を使用せずに英国のデータを取得できます。

最後のインストール手順として、委任を有効にするために必要な委任NS RRとグルーRRを親ゾーンに追加する必要があります。両方のゾーンの管理者は、カットの両側をマークするNSと接着剤のRRが一貫していて、それが維持されることを保証する必要があります。

4.3. ネームサーバの内部構造

4.3.1.問い合わせと回答

ネームサーバの主な活動は標準的な質問に答えることです。問い合わせとその応答はどちらも[RFC-1035]に記述されている標準のメッセージフォーマットで運ばれます。この照会には、必要な情報のタイプとクラス、および関心のある名前を記述するQTYPE、QCLASS、およびQNAMEが含まれています。

ネームサーバがクエリに答える方法は、それが再帰モードで動作しているかどうかによって異なります。

サーバーの最も単純なモードは、ローカル情報のみを使用してクエリに回答できるため、再帰的ではありません。応答にはエラー、回答、または回答に「近い」他のサーバーへの参照が含まれます。すべてのネームサーバは非再帰的な問い合わせを実装しなければなりません。

このモードではネームサーバはリゾルバの役割を果たし、エラーか答えのどちらかを返しますが、紹介はしないので、クライアントにとって最も単純なモードは再帰的です。このサービスはネームサーバではオプションであり、ネームサーバは再帰モードを使用できるクライアントを制限することも選択できます。

再帰的サービスはいくつかの状況で役に立ちます。

質問への直接の回答以外のものを使用する能力を欠いている比較的単純な要求者。

プロトコルまたは他の境界を越える必要があり、仲介として機能できるサーバーに送信できる要求。

クライアントごとに別々のキャッシュを用意するのではなく、キャッシュを集中させたいネットワーク。

要求者が紹介を追求することができ、将来の要求に役立つ情報に興味がある場合は、非再帰的サービスが適切です。

再帰モードの使用は、クライアントとネームサーバの両方がその使用に同意する場合に限られます。合意は質問と応答メッセージで2ビットの使用を通して交渉されます：

使用可能な再帰（RA）ビットは、すべての応答でネームサーバーによって設定または消去されます。クライアントが再帰的サービスを要求したかどうかにかかわらず、ネームサーバがクライアントに再帰的サービスを提供する意思がある場合、このビットは真です。つまり、RAは使用ではなく可用性を示します。

クエリには、recursion desiredまたはRDと呼ばれるビットが含まれています。このビットは、リクエスタがこのクエリに対して再帰的サービスを望むかどうかを指定します。クライアントは、以前にRAを送信したサーバー、またはプライベートな合意やDNSプロトコル以外の方法でサービスを提供することに同意したサーバーからのみ受信することに依存するはずですが、任意のネームサーバーから再帰サービスを要求できます。

再帰的モードは、RDが設定されたクエリが再帰的サービスを提供することを厭わないサーバーに到着したときに発生します。クライアントは、RAとRDの両方が応答に設定されていることを確認することによって、再帰モードが使用されたことを確認できます。RD経由で要求されない限り、ネームサーバーは再帰的なサービスを実行するべきではないことに注意してください。これはネームサーバーとそのデータベースのトラブルシューティングを妨げるからです。

再帰サービスが要求されて利用可能な場合、クエリに対する再帰応答は次のいずれかになります。

質問への回答。おそらく回答の途中で遭遇した別名を指定する1つ以上のCNAME RRが前置きされる。

名前が存在しないことを示す名前エラー。これには、元のクエリ名が存在しない名前のエイリアスであることを示すCNAME RRが含まれることがあります。

一時的なエラー表示

再帰的サービスが要求されていないか利用できない場合、非再帰的応答は次のいずれかになります。

名前が存在しないことを示す正式な名前エラー。

一時的なエラー表示

いくつかの組み合わせ：

データにゾーンから来ているのかキャッシュされているのかの表示とともに、質問に答えるRR。

応答を送信するサーバーよりも名前に近い先祖であるゾーンを持つネームサーバーへの紹介。

ネームサーバが考えるRRは、要求者にとって有用であることが証明されます。

4.3.2. アルゴリズム

ネームサーバによって使用される実際のアルゴリズムは、RRを格納するために使用されるローカルOSとデータ構造によって異なります。次のアルゴリズムは、RRがゾーンごとに1つとキャッシュ用に1つずつ、いくつかのツリー構造で編成されていることを前提としています。

ネームサーバが再帰的サービスを提供する意思があるかどうかに応じて、応答で使用可能な再帰の値を設定または消去します。再帰サービスが利用可能であり、クエリのRDビットを介して要求されている場合は、手順5に進みます。それ以外の場合は手順2に進みます。

QNAMEに最も近い先祖であるゾーンの利用可能なゾーンを検索します。そのようなゾーンが見つかった場合は手順3に進み、それ以外の場合は手順4に進みます。

ゾーン内でラベルごとにマッチングを開始します。マッチングプロセスはいくつかの方法で終了します。

QNAME全体が一致すれば、そのノードが見つかりました。

ノードのデータがCNAMEで、QTYPEがCNAMEと一致しない場合は、CNAME RRを応答の回答セクションにコピーし、QNAMEをCNAME RRの正規名に変更して、手順1に戻ります。

それ以外の場合は、QTYPEと一致するすべてのRRを回答セクションにコピーして、ステップ6に進みます。

一致によって信頼できるデータが除外される場合は、紹介があります。これは、NS RRがマーキングされたノードにゾーンの下部に沿って切れ目が入ったときに発生します。

サブゾーンのためのNS RRsを応答の権威部にコピーしてください。信頼できるデータやキャッシュからアドレスが利用できない場合は、グルーRRを使用して、利用可能なアドレスをすべて追加セクションに入れます。手順4に進みます。

あるラベルで一致が不可能な場合（つまり、対応するラベルが存在しない場合）、 “*“ラベルが存在するかどうかを確認します。

“*“ラベルが存在しない場合は、探している名前がクエリ内の元のQNAMEであるかどうかを確認してください。

CNAMEのために使用した名前です。名前が元のものである場合は、応答に正式な名前エラーを設定して終了します。それ以外の場合はそのまま終了してください。

「場合」のラベルが存在しない、QTYPEに対するそのノードでのRRと一致します。一致するものがあれば、それらをanswerセクションにコピーしてください。ただし、ラベルのあるノードではなく、RRの所有者をQNAMEに設定してください。手順6に進みます。

キャッシュ内でマッチングを開始します。QNAMEがキャッシュ内で見つかった場合は、QTYPEと一致する、それに添付されているすべてのRRを回答セクションにコピーします。信頼できるデータからの委任がなかった場合は、キャッシュから最適なものを探し、それをauthorityセクションに入れます。手順6に進みます。

問い合わせに答えるためにローカルリゾルバまたはそのアルゴリズムのコピー（このメモのリゾルバの節を見よ）を使う。中間のCNAMEも含めて、結果を回答の回答セクションに保存します。

ローカルデータのみを使用して、クエリの追加セクションに役立つ可能性がある他のRRを追加しようとします。出口。

4.3.3. ワイルドカード

以前のアルゴリズムでは、ラベル “*“で始まる所有者名のRRに特別な処理が施されていました。このようなRRはワイルドカードと呼ばれます。ワイルドカードRRはRRを合成するための指示と考えることができます。適切な条件が満たされると、ネームサーバは、クエリ名およびワイルドカードRRから取得した内容と等しい所有者名でRRを作成します。

この機能は、インターネットから他のメールシステムにメールを転送するために使用されるゾーンを作成するために最もよく使用されます。一般的な考え方は、明示的な証拠が反対に存在しない限り、クエリでサーバーに提示されるそのゾーン内の名前はすべて、特定の特性を持って存在すると想定されることです。ドメインではなく、ここでゾーンという用語を使用するのは意図的なものです。そのようなデフォルトはゾーン境界を越えて伝播しません、サブゾーンは同様のデフォルトを設定することによってその外観を達成することを選択するかもしれません。

ワイルドカードRRの内容は、RRの通常の規則と形式に従います。ゾーン内のワイルドカードには、一致するクエリ名を制御する所有者名があります。ワイルドカードRRの所有者名は “ 。”という形式です。ここで、は任意のドメイン名です。他の*ラベルを含んではいけません、そしてゾーンの信頼できるデータにあるべきです。ワイルドカードは潜在的にその子孫に適用されますが、それ自体には適用されません。別の見方をすると “ “ラベルは常に少なくとも1つのラベル全体、時にはそれ以上のラベルにマッチしますが、常にラベル全体にマッチします。

ワイルドカードRRは適用されません。

クエリが別のゾーンにある場合つまり、委任はワイルドカードのデフォルトを取り消します。

クエリ名、またはワイルドカードドメインとクエリ名の間の名前が存在することがわかっている場合。たとえば、ワイルドカードRRの所有者名が「* .X」で、ゾーンにBXに添付されたRRも含まれている場合、ワイルドカードはZXという名前のクエリに適用されますが、ZXに関する明示的な情報はありません。 BX、ABX、またはXに。

クエリ名に表示されるラベルは特別な効果はありませんが、信頼できるゾーンでワイルドカードをテストするために使用できます。そのような問い合わせは、所有者名にが含まれるRRを含む応答を取得する唯一の方法です。そのような問い合わせの結果はキャッシュされるべきではありません。

ワイルドカードRRの内容は、RRの合成に使用されても変更されません。

ワイルドカードRRの使用方法を説明するために、大規模な非IP / TCPネットワークを持つ大企業がメールゲートウェイを作成しようとしていたとします。会社がX.COMと呼ばれ、IP / TCP対応ゲートウェイマシンがAXCOMと呼ばれた場合、次のRRがCOMゾーンに入力される可能性があります。

    X.COM           MX      10      A.X.COM

    *.X.COM         MX      10      A.X.COM

    A.X.COM         A       1.2.3.4
    A.X.COM         MX      10      A.X.COM

    *.A.X.COM       MX      10      A.X.COM

これにより、X.COMで終わるドメイン名に対するMXクエリは、AXCOMを指すMX RRを返します。* .X.COMでのワイルドカードの影響は、AXCOMの明示的なデータによってAXCOMサブツリーで抑制されるため、2つのワイルドカードRRが必要です。また、X.COMとAXCOMの明示的なMXデータが必要であり、上記のRRのどれもXX.COMのクエリ名と一致しないことにも注意してください。

4.3.4. 否定応答キャッシング（オプション）

DNSはオプションのサービスを提供し、ネームサーバがTTLを使用して否定的な結果を配信し、リゾルバがキャッシュすることを可能にします。例えば、ネームサーバは名前誤り指示と共にTTLを分配できます、そして、そのような情報を受け取るリゾルバは正式なデータに相談することなくTTL期間の間に名前が存在しないと仮定するのを許容されます。同様に、リゾルバは複数の型に一致するQTYPEを使って問い合わせをし、いくつかの型が存在しないという事実をキャッシュすることができます。

この機能は、検索リストを使用する命名の短縮形を実装するシステムでは特に重要になる可能性があるため、検索リストの末尾に接尾辞を付ける必要があるため、使用するたびに複数の名前エラーが発生します。

その方法は、応答が信頼できる場合、ネームサーバが応答の追加セクションにSOA RRを追加できることです。SOAは回答セクションの信頼できるデータの出所であったゾーンのものでなければならない、あるいは該当する場合は名前の誤り。SOAのMINIMUMフィールドは、否定的な結果がキャッシュされる可能性がある期間を制御します。

状況によっては、回答セクションに複数の所有者名が含まれることがあります。この場合、SOAメカニズムはQNAMEと一致するデータに対してのみ使用されるべきです。これは、このセクションで唯一の信頼できるデータです。

ネームサーバとリゾルバは、権限のない応答の追加セクションにSOAを追加しようとしたり、権限のある応答に直接記載されていない結果を推論しようとしたりしてはいけません。これにはいくつかの理由があります。キャッシュされた情報は通常RRとそのゾーン名を一致させるのに十分ではない、SOA RRは直接のSOAクエリによりキャッシュされ、ネームサーバーはSOAセクションをauthorityセクションに出力する必要がない。

この機能はオプションですが、将来的には洗練されたバージョンが標準プロトコルの一部になる予定です。ネームサーバーは、すべての信頼できる応答にSOA RRを追加する必要はなく、否定的な結果をキャッシュする必要もありません。どちらもお勧めです。すべてのリゾルバと再帰ネームサーバは、応答に存在するときに少なくともSOA RRを無視できることが要求されます。

この特徴を利用するいくつかの実験も提案されている。その考えは、キャッシュされたデータが特定のゾーンから来ていることがわかっていて、そのゾーンのSOAの正式なコピーが取得され、そのデータがキャッシュされてからゾーンのSERIALが変更されていなければ、キャッシュされたデータのTTLは小さい場合はゾーンのMINIMUM値にリセットします。この使用法は計画目的でのみ記載されており、まだ推奨されていません。

4.3.5. ゾーンのメンテナンスと移動

ゾーン管理者の仕事の一部は、ゾーンに対して権限のあるすべてのネームサーバーにゾーンを維持することです。避けられない変更が行われたときは、それらをすべてのネームサーバーに配布する必要があります。この配布はFTPまたは他のアドホック手順を使用して実行できますが、推奨される方法はDNSプロトコルのゾーン転送部分です。

自動ゾーン転送または自動更新の一般的なモデルは、ネームサーバーの1つがゾーンのマスターまたはプライマリであるということです。主にゾーンのマスターファイルを編集することで、変更はプライマリで調整されます。編集後、管理者はマスターサーバーに新しいゾーンを読み込むように通知します。ゾーンの他の非マスターサーバーまたはセカンダリサーバーは定期的に（選択可能な間隔で）変更を確認し、変更が行われたときに新しいゾーンコピーを取得します。

変更を検出するために、セカンダリはゾーンのSOAのSERIALフィールドをチェックするだけです。他の変更が加えられたことに加えて、そのゾーンのSOAのSERIALフィールドは、そのゾーンに変更が加えられたときはいつでも常に進んでいます。この進行は、単純な増分でもよいし、あるいはマスターファイルの書き込み日時などに基づいてもよい。目的は、シリアル番号を比較することによって、ゾーンの2つのコピーのどちらが最新かを判断できるようにすることです。シリアル番号の進歩と比較にはシーケンス空間の算術演算が使用されるため、ゾーンの更新速度には理論的な限界があります。基本的にシリアル番号が32ビット範囲の半分をカバーする前に古いコピーは消滅します。実際には、

セカンダリサーバの定期的なポーリングは、ゾーンのSOA RRのパラメータによって制御されます。このパラメータは、許容可能な最小ポーリング間隔を設定します。パラメータはREFRESH、RETRY、およびEXPIREと呼ばれます。新しいゾーンがセカンダリにロードされるたびに、セカンダリはプライマリに新しいシリアルをチェックする前にREFRESH秒待ちます。このチェックが完了できない場合は、新しいチェックがRE??TRY秒ごとに開始されます。チェックは、ゾーンのSOA RRに対するプライマリへの単純なクエリです。セカンダリのゾーンコピーのシリアルフィールドがプライマリから返されたシリアルと等しい場合、変更は行われず、REFRESHインターバル待機が再開されます。セカンダリがEXPIREインターバルのシリアルチェックを実行することが不可能であると判断した場合、ゾーンのコピーは廃止されたものと見なさなければなりません。

ポーリングによってゾーンが変更されたことが示された場合、セカンダリサーバはそのゾーンに対するAXFR要求を介してゾーン転送を要求する必要があります。AXFRは拒否などのエラーを引き起こす可能性がありますが、通常は一連の応答メッセージで応答されます。最初と最後のメッセージは含まれていなければなりません

ゾーンの最高権威ノードのデータ。中間メッセージは、権限のあるRRと権限のないRRの両方を含む、ゾーンからの他のすべてのRRを伝送します。メッセージの流れはセカンダリがゾーンのコピーを作成することを可能にします。精度が不可欠であるため、AXFR要求にはTCPまたはその他の信頼性の高いプロトコルを使用する必要があります。

各セカンダリサーバーは、マスターに対して次の操作を実行する必要がありますが、オプションで他のセカンダリサーバーに対してこれらの操作を実行することもできます。この方法では、ホストのダウンタイムやネットワークの問題によりプライマリが利用できない場合、またはセカンダリサーバーがプライマリよりも「中間」のセカンダリに対してネットワークアクセスが良好な場合に、転送プロセスを改善できます。

リゾルバー

5.1.前書き

リゾルバーは、ユーザープログラムをドメインネームサーバーにインターフェースするプログラムです。最も単純な場合では、リゾルバはユーザプログラム（例えばメールプログラム、TELNET、FTP）からサブルーチンコール、システムコールなどの形式で要求を受け取り、そして所望の情報をローカルホストのものと互換性のある形式で返す。データフォーマット

リゾルバはリゾルバのサービスを要求するプログラムと同じマシン上にありますが、他のホスト上のネームサーバに問い合わせる必要があるかもしれません。リゾルバがいくつかのネームサーバに相談する必要があるかもしれないか、またはローカルキャッシュで要求された情報を持っているかもしれないので、リゾルバが完了するのにかかるであろう時間はミリセカンドから数秒までかなり変わるかもしれません。

リゾルバの非常に重要な目標は、以前の結果のキャッシュからそれらに答えることによって、ほとんどの要求からネットワーク遅延とネームサーバ負荷を排除することです。つまり、複数のプロセス、ユーザー、マシンなどで共有されているキャッシュは、非共有キャッシュよりも効率的です。

5.2. クライアントリゾルバインタフェース

5.2.1.代表的な機能

リゾルバへのクライアントインタフェースはローカルホストの規約の影響を受けますが、典型的なリゾルバ - クライアントインタフェースは3つの機能を持ちます。

ホスト名からホストアドレスへの変換

この関数は、以前のHOSTS.TXTベースの関数を模倣するように定義されていることがよくあります。文字列が与えられると、呼び出し元は1つ以上の32ビットIPアドレスを求めます。DNSの下では、それはタイプA RRの要求に変換されます。DNSはRRの順序を保存しないので、この機能は返されたアドレスをソートするか、サービスがクライアントに1つの選択肢しか返さない場合は「最良の」アドレスを選択することを選択します。複数のアドレスを返すことをお勧めしますが、単一のアドレスが以前のHOSTS.TXTサービスをエミュレートする唯一の方法である可能性があります。

ホストアドレスからホスト名への変換

この関数はしばしば以前の関数の形式に従います。32ビットのIPアドレスを考えると、呼び出し元は文字列を望んでいます。IPアドレスのオクテットは逆にされ、名前の構成要素として使用され、接尾辞 “IN-ADDR.ARPA”が付きます。タイプPTRクエリは、ホストのプライマリ名を持つRRを取得するために使用されます。たとえば、IPアドレス1.2.3.4に対応するホスト名の要求は、ドメイン名「4.3.2.1.IN-ADDR.ARPA」のPTR RRを探します。

一般的な検索機能

この関数はDNSから任意の情報を取得します。以前のシステムには対応するものがありません。呼び出し元はQNAME、QTYPE、およびQCLASSを提供し、一致するすべてのRRを要求します。この関数は、ローカルホストの代わりにすべてのRRデータにDNSフォーマットを使用することが多く、ローカル引用符付きの処理された形式ではなくすべてのRRコンテンツ（TTLなど）を返します。

リゾルバーが指示された機能を実行すると、通常、クライアントに渡すために以下のいずれかの結果が得られます。

要求されたデータを提供する1つ以上のRR。

この場合、リゾルバは適切なフォーマットで答えを返します。

名前エラー（NE）

これは、参照名が存在しない場合に起こります。たとえば、ユーザーがホスト名を誤って入力した可能性があります。

データが見つかりませんエラー。

参照された名前が存在するが、適切な種類のデータが存在しない場合、これが発生します。たとえば、ホストアドレス

メールボックス名に適用された関数は名前が存在するのでこのエラーを返しますが、アドレスRRは存在しません。

ホスト名とアドレスの間の変換のための関数は “name error”と “data not found”エラー条件を単一のタイプのエラーリターンに結合するかもしれないが、一般的な関数はそうではないことに注意することは重要です。この理由の1つは、アプリケーションが最初に名前に関する1つのタイプの情報を要求した後、他のタイプの情報について同じ名前を2回要求することです。2つのエラーが組み合わされると、無駄なクエリがアプリケーションを遅くする可能性があります。

5.2.2. エイリアス

特定の要求を解決しようとしている間に、リゾルバは問題の名前がエイリアスであることを見つけるかもしれません。例えば、リゾルバーは、CNAME RRを見つけたときに、ホスト名からアドレスへの変換に与えられた名前が別名であることを見つけるかもしれません。可能であれば、エイリアス条件はリゾルバからクライアントに返されるべきです。

ほとんどの場合、リゾルバはCNAMEに遭遇すると新しい名前でクエリを再開します。しかしながら、一般的な機能を実行するとき、CNAME RRが質問タイプと合っているとき、リゾルバは別名を追求するべきではありません。これにより、エイリアスが存在するかどうかを問い合わせるクエリが可能になります。例えば、質問タイプがCNAMEであるなら、ユーザはそれが指す名前でRRsではなくCNAME RR自体に興味があります。

エイリアスでは、いくつかの特別な条件が発生する可能性があります。複数レベルのエイリアスは効率が低いため避けるべきですが、エラーとして通知するべきではありません。存在しない名前を指すエイリアスループとエイリアスは捕捉され、エラー状態がクライアントに返されます。

5.2.3. 一時的な失敗

完璧ではない世界では、すべてのリゾルバが特定の要求を解決できないことがあります。この状態は、リンクの障害やゲートウェイの問題により、ネットワークの他の部分から分離されたリゾルバ、または特定のドメインの同時障害またはすべてのサーバーの使用不可が原因で発生することがあります。

この種の状態が名前やデータとして通知されてアプリケーションにエラーが発生しないようにする必要があります。このような振る舞いは人間にとって厄介なものであり、メールシステムがDNSを使用するときには混乱を招くことがあります。

場合によっては、リクエストを無期限にブロックすることでこのような一時的な問題に対処することは可能ですが、これは通常、特にクライアントが次へ進む可能性があるサーバプロセスである場合には適切な選択ではありません。

他のタスク推奨される解決策は、既存のHOSTS.TXT関数のエミュレーションをより困難にするかもしれませんが、リゾルバー関数の考えられる結果の1つとして常に一時的な失敗を起こすことです。

5.3. リゾルバ内部

すべてのリゾルバの実装は、わずかに異なるアルゴリズムを使用しており、通常、一般的なオカレンスよりもさまざまな種類のエラーを処理するためにはるかに多くのロジックを費やしています。このセクションはリゾルバ操作のための推薦された基本的な戦略を概説します、しかし[RFC-1035]に詳細を残します。

5.3.1.スタブリゾルバ

リゾルバを実装するための1つのオプションは、解決機能をローカルマシンから再帰クエリをサポートするネームサーバに移動することです。これにより、リゾルバ機能を実行するためのリソースが不足しているPCでドメインサービスを提供する簡単な方法を提供できます。または、ローカルネットワークまたは組織全体のキャッシュを集中管理できます。

残りのスタブに必要なのは、再帰的要求を実行するネームサーバーアドレスのリストだけです。このタイプのリゾルバは、おそらくドメインデータベース内でそれを見つけるのに洗練されていないため、構成ファイル内の情報を必要とします。ユーザーはまた、リストされたサーバーが再帰的サービスを実行することを確認する必要があります。ネームサーバは、一部またはすべてのクライアントに対して再帰的サービスの実行を拒否することは自由です。ユーザーは、ローカルシステム管理者に相談して、サービスを実行したいネームサーバーを見つけてください。

このタイプのサービスにはいくつかの欠点があります。再帰的要求は実行するのに任意の時間を要するかもしれないので、スタブは失われたＵＤＰパケットと死んだサーバの両方を扱うために再送間隔を最適化することが困難であるかもしれない。ネームサーバは、再送信を新しい要求として解釈すると、あまりに熱心なスタブによって簡単に過負荷になる可能性があります。TCPの使用は答えかもしれませんが、TCPは実際のリゾルバのそれらに類似しているホストの機能にかなりの負担をかけるかもしれません。

5.3.2. リソース

それ自身のリソースに加えて、リゾルバはローカルネームサーバによって維持されているゾーンへの共有アクセスを持っているかもしれません。これはリゾルバにもっと速いアクセスの利点を与えるが、リゾルバはキャッシュされた情報がゾーンデータを上書きしないように注意しなければならない。この説明では、「ローカル情報」という用語は、次のことを理解した上で、キャッシュとそのような共有ゾーンの結合を意味します。

両方が存在する場合、信頼できるデータは常にキャッシュデータよりも優先して使用されます。

次のリゾルバアルゴリズムは、すべての関数が一般的なルックアップ関数に変換されていることを前提としており、リゾルバで進行中の要求の状態を表すために次のデータ構造を使用します。

SNAME

探しているドメイン名

STYPE

検索要求のQTYPE

SCLASS

検索要求のQCLASS

SLIST

ネームサーバとリゾルバが現在問い合わせようとしているゾーンを記述する構造体。この構造は、どのネームサーバが望ましい情報を保持しているかについてのリゾルバの現在の最善の推測を追跡します。到着情報が推測を変更するときそれは更新されます。この構造には、ゾーン名に相当するもの、そのゾーン用の既知のネームサーバー、そのネームサーバー用の既知のアドレス、およびどのサーバーが次に試すのが最適かを示唆するために使用できる履歴情報が含まれます。同等のゾーン名は、SNAMEが照会されているゾーンと共通しているルートから下のラベルの数の一致数です。これは、リゾルバがSNAMEにどれだけ「近い」かを示す尺度として使用されます。

SBELT

SLISTと同じ形式の「??安全ベルト」構造。設定ファイルから初期化され、リゾルバがネームサーバの選択を導くためのローカル情報を持っていないときに使用されるべきサーバをリストします。一致数は-1になり、一致するラベルがないことを示します。

キャッシュ

以前の応答からの結果を格納する構造。リゾルバはTTLが期限切れになった古いRRを破棄する責任があるため、ほとんどの実装では、到着したRRで指定された間隔を、RRがキャッシュに格納されるときのある種の絶対時間に変換します。TTLを個別にカウントダウンするのではなく、リゾルバは、検索中に古いRRを無視したり破棄したりするか、または定期的なスイープ中にそれらを破棄して古いRRで消費されたメモリを回収します。

5.3.3. アルゴリズム

トップレベルのアルゴリズムには4つのステップがあります。

答えがローカル情報にあるかどうかを確認し、そうである場合はクライアントに返します。

尋ねるのに最も良いサーバーを見つけてください。

1つが応答を返すまでそれらに問い合わせを送ってください。

応答を分析してください。

応答が質問に答えるか名前エラーを含む場合は、データをキャッシュし、それをクライアントに返します。

応答に他のサーバーへのより適切な委任が含まれている場合は、委任情報をキャッシュに入れてステップ2に進みます。

応答がCNAMEを示し、それ自体が答えではない場合は、CNAMEをキャッシュし、SNAMEをCNAME RRの正規名に変更してステップ1に進みます。

応答にサーバー障害または他の奇妙な内容が示されている場合は、SLISTからサーバーを削除してステップ3に戻ります。

ステップ1では、キャッシュから目的のデータを検索します。データがキャッシュにある場合は、通常の使用に十分なものと見なされます。一部のリゾルバは、リゾルバにキャッシュされたデータを無視させ、権威のあるサーバーと相談することをユーザーに強制するオプションを持っています。これはデフォルトとしてはお勧めできません。リゾルバがネームサーバのゾーンに直接アクセスできる場合は、目的のデータが正式な形式で存在するかどうかを確認し、存在する場合は、キャッシュされたデータよりも正式なデータを使用します。

ステップ2では、ネームサーバを探して必要なデータを要求します。一般的な戦略は、SNAMEから始まり、次にSNAMEの親ドメイン名、祖父母などのルートに向かってローカルに利用可能なネームサーバーRRを探すことです。したがって、SNAMEがMockapetris.ISI.EDUの場合、このステップではMockapetris.ISI.EDU、次にISI.EDU、次にEDUの順にNS RRを探します。（根っ子）。これらのNS RRは、SNAME以上のゾーンのホスト名をリストします。名前をSLISTにコピーします。ローカルデータを使ってアドレスを設定します。アドレスが利用できない場合があります。リゾルバにはたくさんの選択肢があります。最善の方法は、利用可能なアドレスから先に進みながら、アドレスを探す並行リゾルバプロセスを開始することです。明らかに、デザインの選択とオプションは複雑で、ローカルホストの機能です。の機能リゾルバ設計者に推奨される優先順位は次のとおりです。

他の実装でリクエストが無限ループに陥ったり、リクエストやクエリの連鎖反応を開始したりできないように、作業量（送信パケット、並列プロセスの開始）を制限します。EVEN IF SOMEONE CONFIGURED CONFIGURED SOME DATA

可能であれば回答を返してください。

不要な送信を避けます。

できるだけ早く答えを入手してください。

NS RRの検索に失敗した場合、リゾルバは安全ベルトSBELTからSLISTを初期化します。基本的な考え方は、リゾルバがどのサーバに問い合わせるべきかわからないときは、役に立つと期待されるいくつかのサーバをリストした設定ファイルからの情報を使うべきです。特別な状況がありますが、通常の選択はホストのドメイン用に2つのルートサーバーと2つのサーバーです。それぞれ2つの理由は冗長性のためです。ルートサーバーは、すべてのドメインスペースへの最終的なアクセスを提供します。2つのローカルサーバーは、ローカルネットワークがゲートウェイまたはリンクの障害のためにインターネットから分離された場合、リゾルバーがローカル名を解決し続けることを可能にします。

サーバーの名前とアドレスに加えて、SLISTデータ構造をソートして、最善のサーバーを最初に使用し、すべてのサーバーのすべてのアドレスがラウンドロビン方式で使用されるようにすることができます。並べ替えは、他のものよりもローカルネットワーク上のアドレスを優先するという単純な機能である場合もあれば、以前の応答時間や打率の平均など、過去のイベントの統計情報が含まれる場合もあります。

ステップ3は、応答が受信されるまでクエリを送信します。戦略は、各送信の間にタイムアウトを設定して、すべてのサーバーのすべてのアドレスを巡回することです。実際には、マルチホームホストのすべてのアドレスを使用することが重要です。また、同じネームサーバーを競合する複数のリゾルバによって使用され、場合によっては単一のリゾルバを使用すると、再送信ポリシーが実際に応答を遅くします。SLISTには通常、タイムアウトを制御し、以前の送信を追跡するためのデータ値が含まれています。

ステップ4では、回答を分析します。リゾルバは応答の解析において非常に妄想的であるべきです。また、レスポンスがレスポンス内のIDフィールドを使用して送信したクエリと一致することも確認する必要があります。

理想的な答えは、要求されたデータまたは名前の誤りのいずれかを与える、問い合わせに対して権限のあるサーバーからのものです。TTLがゼロより大きい場合、データはユーザーに戻され、将来の使用に備えてキャッシュに入れられます。

応答が委任を示すなら、リゾルバはSLISTのサーバがそうであるより委任が答えに “近い”ことを確かめるためにチェックするべきです。これは、SLISTの一致数と、SNAMEから計算された一致数、および委任のNS RRを比較することによって実行できます。そうでなければ、返信は偽物であり、無視する必要があります。委任が有効であるなら、NS委任RRsとサーバのためのどんなアドレスRRsもキャッシュされるべきです。ネームサーバがSLISTに入力され、検索が再開されます。

応答にCNAMEが含まれている場合、応答に正規名のデータが含まれていない限り、またはCNAMEが回答そのものである場合を除き、検索はCNAMEで再開されます。

詳細と実装のヒントは[RFC-1035]にあります。

シナリオ

サンプルドメインスペースで、ルートゾーン、MILゾーン、EDUゾーン、MIT.EDUゾーン、およびISI.EDUゾーンに別々の管理制御を適用するとします。次のようにネームサーバーを割り当てるかもしれません。

                                   |(C.ISI.EDU,SRI-NIC.ARPA
                                   | A.ISI.EDU)
             +---------------------+------------------+
             |                     |                  |
            MIL                   EDU                ARPA
             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
             | A.ISI.EDU           | C.ISI.EDU)       |
       +-----+-----+               |     +------+-----+-----+
       |     |     |               |     |      |           |
      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                                   |
       +--------+------------------+---------------+--------+
       |        |                  |               |        |
      UCI      MIT                 |              UDEL     YALE
                |(XX.LCS.MIT.EDU, ISI
                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
            +---+---+              | A.ISI.EDU)
            |       |              |
           LCS   ACHILLES +--+-----+-----+--------+
            |             |  |     |     |        |
            XX            A  C   VAXA  VENERA Mockapetris

この例では、権限のあるネームサーバーが、制御を引き受けるドメインツリー内のポイントにかっこ内に表示されています。

したがって、ルートネームサーバはC.ISI.EDU、SRI-NIC.ARPA、およびA.ISI.EDUにあります。MILドメインはSRI-NIC.ARPAとA.ISI.EDUによって提供されます。EDUドメインはSRI-NIC.ARPAによって提供されます。とＣ.サーバーには、隣接したゾーンまたは離れたゾーンがある場合があります。このシナリオでは、C.ISI.EDUにはルートドメインとEDUドメインに隣接するゾーンがあります。A.ISI.EDUには、ルートドメインとMILドメインに隣接ゾーンがありますが、ISI.EDUには非隣接ゾーンもあります。

6.1. C.ISI.EDUネームサーバ

C.ISI.EDUは、INクラスのルートドメイン、MILドメイン、およびEDUドメインのネームサーバーであり、これらのドメイン用のゾーンがあります。ルートドメインのゾーンデータは次のようになります。

    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870611          ;serial
                            1800            ;refresh every 30 min
                            300             ;retry every 5 min
                            604800          ;expire after a week
                            86400)          ;minimum of a day
                    NS      A.ISI.EDU.
                    NS      C.ISI.EDU.
                    NS      SRI-NIC.ARPA.

    MIL.    86400   NS      SRI-NIC.ARPA.
            86400   NS      A.ISI.EDU.

    EDU.    86400   NS      SRI-NIC.ARPA.
            86400   NS      C.ISI.EDU.

    SRI-NIC.ARPA.   A       26.0.0.73
                    A       10.0.0.51
                    MX      0 SRI-NIC.ARPA.
                    HINFO   DEC-2060 TOPS20

    ACC.ARPA.       A       26.6.0.65
                    HINFO   PDP-11/70 UNIX
                    MX      10 ACC.ARPA.

    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.

    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.

    A.ISI.EDU. 86400 A      26.3.0.103
    C.ISI.EDU. 86400 A      10.0.0.52

このデータは、マスターファイルの場合と同じように表されます。ほとんどのRRは単一行エントリです。ここでの唯一の例外はSOA RRで、これは “（”で複数行のRRを開始し、 “）”で複数行のRRの終わりを示します。ゾーン内のすべてのRRのクラスは同じである必要があるので、ゾーン内の最初のRRだけがクラスを指定する必要があります。ネームサーバがゾーンをロードするとき、それはすべての権威あるRRのTTLが少なくともSOAのMINIMUMフィールド、ここでは86400秒、または1日であることを強制します。MILドメインとEDUドメインの委任をマークするNS RRは、サーバホストアドレスのグルーRRとともに、ゾーン内の信頼できるデータの一部ではないため、明示的なTTLがあります。

4つのRRがルートノードに接続されています：ルートゾーンを記述するSOAとルートのネームサーバーをリストする3つのNS RR。SOA RRのデータはゾーンの管理を記述します。ゾーンデータはホストSRI-NIC.ARPAで管理され、ゾーンの責任者はHOSTMASTER@SRI-NIC.ARPAです。SOAの重要な項目は、最小86400秒のTTLです。これは、ゾーン内のすべての信頼できるデータに少なくともそのTTLがあることを意味します。ただし、より高い値を明示的に指定することもできます。

MILドメインとEDUドメインのNS RRは、ルートゾーンとMILゾーンおよびEDUゾーンの間の境界を示します。この例では、ルートゾーンもサポートしているネームサーバーが下位ゾーンをサポートしていることに注意してください。

EDUゾーンのマスターファイルは、起点のEDUを基準にして記述することができます。EDUドメインのゾーンデータは次のようになります。

    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870729 ;serial
                            1800 ;refresh every 30 minutes
                            300 ;retry every 5 minutes
                            604800 ;expire after a week
                            86400 ;minimum of a day
                            )
                    NS SRI-NIC.ARPA.
                    NS C.ISI.EDU.

    UCI 172800 NS ICS.UCI
                    172800 NS ROME.UCI
    ICS.UCI 172800 A 192.5.19.1
    ROME.UCI 172800 A 192.5.19.31

    ISI 172800 NS VAXA.ISI
                    172800 NS A.ISI
                    172800 NS VENERA.ISI.EDU.
    VAXA.ISI 172800 A 10.2.0.27
                    172800 A 128.9.0.33
    VENERA.ISI.EDU. 172800 A 10.1.0.52
                    172800 A 128.9.0.32
    A.ISI 172800 A 26.3.0.103

    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
                    172800 NS UMN-REI-UC.ARPA.
    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
                    172800 A 192.5.39.3

    YALE.EDU.  172800 NS YALE.ARPA.
    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.

    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
                      43200 NS ACHILLES.MIT.EDU.
    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
    ACHILLES.MIT.EDU. 43200 A 18.72.0.8

ここでは相対名の使用に注意してください。ISI.EDUの所有者名ネームサーバRRの内容のうちの2つがそうであるように、相対的な名前を使用して述べられる。相対ドメイン名と絶対ドメイン名は、マスター内で自由に混在させることができます。

6.2. 標準クエリの例

以下の質問と回答はネームサーバの振舞いを例示します。特に断りのない限り、クエリのヘッダーには再帰要求（RD）はありません。非再帰的なクエリに対する回答は、要求されているサーバーには依存しますが、リクエスタのIDには依存しません。

6.2.1.QNAME = SRI-NIC.ARPA、QTYPE = A

クエリは次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

C.ISI.EDUからの返信は次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
               |               86400 IN A 10.0.0.51                |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

レスポンスのヘッダはクエリのヘッダと似ていますが、RESPONSEビットが設定され、このメッセージがクエリではなくレスポンスであることを示し、Authoritative Answer（AA）ビットが設定されていることを示します。回答セクションは信頼できるデータからのものです。応答の質問セクションは、クエリの質問セクションと一致します。

SRI-NIC.ARPAに対して権限のない他のサーバーに同じ照会が送信された場合、応答は次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY,RESPONSE                            |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
               |               1777 IN A 26.0.0.73                 |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

この応答は、2つの点で前の応答と異なります。ヘッダーにAAが設定されていないことと、TTLが異なっていることです。推論は、データはゾーンからではなくキャッシュから来たということです。信頼できるTTLとここでのTTLの違いは、キャッシュ内のデータのエージングによるものです。回答セクションのRRの順序の違いは重要ではありません。

6.2.2. QNAME = SRI-NIC.ARPA、QTYPE = *

前のものと似ていますが、*のQTYPEを使用しているクエリは、C.ISI.EDUから次の応答を受け取ります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
               |                         A     10.0.0.51           |
               |                         MX    0 SRI-NIC.ARPA.     |
               |                         HINFO DEC-2060 TOPS20     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

SRI-NIC.ARPAに対して権限のない2つのネームサーバに同様のクエリが送信された場合、応答は次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

と

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

どちらの回答にもAAは設定されていないので、どちらの回答も信頼できるデータから得られるものではありません。異なるコンテンツと異なるTTLは、2つのサーバーが異なる時間にデータをキャッシュしたこと、および最初のサーバーがQTYPE = Aクエリに対する応答をキャッシュし、2番目のサーバーがHINFOクエリに対する応答をキャッシュしたことを示しています。

6.2.3. QNAME = SRI-NIC.ARPA、QTYPE = MX

この種の問い合わせは、メール送信先HOSTMASTER@SRI-NIC.ARPAのルーティング情報を調べようとしているメーラの結果であるかもしれません。C.ISI.EDUからの返信は次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+

この応答には、応答の回答セクションにMX RRが含まれています。C.ISI.EDUのネームサーバがMXによって運ばれた情報を適切に使用するために要求者がアドレスを必要とするであろうと推測するので、追加セクションはアドレスRRsを含みます。

6.2.4. QNAME = SRI-NIC.ARPA、QTYPE = NS

C.ISI.EDUはこの問い合わせに返答します。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

応答と問い合わせの唯一の違いは、ヘッダのAAビットとRESPONSEビットです。この応答の解釈は、サーバがその名前に対する権限を持ち、名前は存在するが、タイプNSのRRが存在しないことです。

6.2.5. QNAME = SIR-NIC.ARPA、QTYPE = A

ユーザーがホスト名を誤って入力した場合、この種のクエリが表示されることがあります。C.ISI.EDUはそれに答えます：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
               +---------------------------------------------------+
    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
               |       870611 1800 300 604800 86400                |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

この応答は、名前が存在しないことを示しています。この状態は、ヘッダーの応答コード（RCODE）セクションで通知されます。

権限セクションのSOA RRは、この応答を使用するリゾルバがSOA MINIMUM（86400）秒間その名前が存在しないと仮定することを可能にするオプションのネガティブキャッシング情報です。

6.2.6. QNAME = BRL.MIL、QTYPE = A

この問い合わせがC.ISI.EDUに送信された場合、返信は以下のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
               |                  86400    NS       A.ISI.EDU.     |
               +---------------------------------------------------+
    Additional | A.ISI.EDU.                A        26.3.0.103     |
               | SRI-NIC.ARPA.             A        26.0.0.73      |
               |                           A        10.0.0.51      |
               +---------------------------------------------------+

この回答には空の回答セクションがありますが、正式なものではないため、紹介です。C.ISI.EDU上のネームサーバーは、それがMILドメインに対して権限がないことを認識して、要求者をA.ISI.EDUおよびSRI-NIC.ARPA上のサーバーに照会しました。これらはMILドメインに対して権限があることがわかっています。

6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A

A.ISI.EDUからのこのクエリに対する応答は次のようになります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

ヘッダーのAAビットはQNAMEと一致するデータが信頼できることを保証しますが、C.ISI.EDUのデータが信頼できるかどうかについては何も言いません。A.ISI.EDUはUSC-ISIC.ARPAが見つかったARPAドメインとC.ISI.EDUデータが見つかったISI.EDUドメインの両方に対して権限があるため、この完全な応答は可能です。

同じ照会がC.ISI.EDUに送信された場合、その応答は、キャッシュ内に独自のアドレスがある場合は上記のものと同じになる可能性がありますが、以下のようになる可能性もあります。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
               |                           NS      A.ISI.EDU.      |
               |                           NS      VENERA.ISI.EDU. |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
               |                 172800    A       128.9.0.33      |
               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
               |                 172800    A       128.9.0.32      |
               | A.ISI.EDU.      172800    A       26.3.0.103      |
               +---------------------------------------------------+

この回答は別名USC-ISIC.ARPAに対する正式な回答とISI.EDUに対するネームサーバへの紹介を含んでいます。この種の応答は、問い合わせが要求されているネームサーバのホスト名に対するものであることを考えれば、あまりありそうもありませんが、他のエイリアスにはよくあることです。

6.2.8. QNAME = USC-ISIC.ARPA、QTYPE = CNAME

この質問がA.ISI.EDUかC.ISI.EDUのどちらかに送られるなら、答えは以下のようになるでしょう：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

QTYPE = CNAMEなので、CNAME RR自体が問い合わせに答え、ネームサーバーはC.ISI.EDUを探すことはしません。（追加のセクションを除いて）

6.3. 解像度の例

次の例は、リゾルバがそのクライアントに対して実行しなければならない操作を示しています。システムのブート後のように、リゾルバはキャッシュなしで起動していると仮定します。さらに、システムはデータ内のホストの1つではなく、ホストはネット26のどこかにあり、その安全ベルト（SBELT）データ構造には以下の情報が含まれていると想定します。

    Match count = -1
    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
    A.ISI.EDU.      26.3.0.103

この情報は、試行するサーバー、そのアドレス、および一致数-1を指定します。これは、サーバーがターゲットにあまり近くないことを示しています。-1は正確な近さの尺度ではなく、アルゴリズムの後の段階で機能するようにするための値にすぎません。

以下の例はキャッシュの使用法を示しているので、各例は前の要求が完了したと仮定しています。

6.3.1.ISI.EDUのMXを解決します。

リゾルバへの最初のリクエストがPVM@ISI.EDU宛のメールを持っているローカルメーラから来ると仮定してください。そして、メーラはドメイン名ISI.EDUのためにタイプMX RRを要求するかもしれません。

リゾルバはISI.EDUでMX RRのキャッシュを調べますが、空のキャッシュは役に立ちません。リゾルバは、外部サーバに問い合わせる必要があることを認識し、問い合わせに最適なサーバを決定しようとします。この検索は、ドメインISI.EDU、EDU、およびルートのNS RRを探します。これらのキャッシュの検索も失敗します。最後の手段として、リゾルバはSBELTからの情報を使用して、それをSLIST構造にコピーします。

この時点で、リゾルバは利用可能な3つのアドレスのうちの1つを試す必要があります。リゾルバがネット26上にあることを考えると、最初の選択肢として26.0.0.73または26.3.0.103のいずれかを選択する必要があります。それはそれからフォームの質問を送り出すでしょう：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

リゾルバは、その問い合わせに対する応答またはタイムアウトを待ちます。タイムアウトが発生した場合、別のサーバーを試してから同じサーバーの別のアドレスを試し、最後に既に試したアドレスを再試行します。それは最終的にSRI-NIC.ARPAから返事を受け取るかもしれません：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
               |                           NS       A.ISI.EDU.     |
               |                           NS       VENERA.ISI.EDU.|
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
               |                 172800    A        128.9.0.33     |
               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
               |                 172800    A        128.9.0.32     |
               | A.ISI.EDU.      172800    A        26.3.0.103     |
               +---------------------------------------------------+

リゾルバは、応答内の情報が既存のSLISTよりもISI.EDUに近い委任を与えたことに気付くでしょう（3つのラベルにマッチするので）。リゾルバはそれからこの応答の情報をキャッシュし、新しいSLISTを設定するためにそれを使用します。

    Match count = 3
    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32

A.ISI.EDUは、前のリストと同様にこのリストにも表示されますが、それは純粋に偶然の一致です。リゾルバは再び送信を開始し、応答を待ちます。最終的にそれは答えを得るでしょう：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
               |                         MX 20 VAXA.ISI.EDU.       |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
               |                 172800  A  128.9.0.33             |
               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
               |                 172800  A  128.9.0.32             |
               +---------------------------------------------------+

リゾルバはこの情報をキャッシュに追加し、MX RRをクライアントに返します。

6.3.2. アドレス26.6.0.65のホスト名を取得します

リゾルバはこれを65.0.6.26.IN-ADDR.ARPAのPTR RRの要求に変換します。この情報はキャッシュにはないため、リゾルバは外部サーバーに問い合わせるよう求めます。どのサーバーも一致しないため、再度SBELTを使用します。（ISI.EDUドメインのサーバーはキャッシュ内にありますが、ISI.EDUは65.0.6.26.IN-ADDR.ARPAの先祖ではないため、SBELTが使用されます。）

この要求はSBELT内の両方のサーバーの信頼できるデータ内にあるため、最終的には次のように返されます。

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
               +---------------------------------------------------+
    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

6.3.3. poneria.ISI.EDUのホストアドレスを取得

この要求はponeria.ISI.EDUに対するタイプAの要求に変換されます。リゾルバはこの名前のためにキャッシュされたデータを見つけることはないでしょうが、それが問い合わせをする外国のサーバを探すときISI.EDUのためにキャッシュの中にNS RRを見つけるでしょう。このデータを使用して、次の形式のSLISTを作成します。

    Match count = 3

    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52

A.ISI.EDUは、リゾルバがその選択を優先順に並べるという前提で最初にリストされており、A.ISI.EDUは同じネットワーク上にあります。

これらのサーバーの1つがクエリに答えます。

参考文献および書誌

[Dyer 87] Dyer, S., and F. Hsu, “Hesiod”, Project Athena Technical Plan - Name Service, April 1987, version 1.9. Describes the fundamentals of the Hesiod name service.
[IEN-116] J. Postel, “Internet Name Server”, IEN-116, USC/Information Sciences Institute, August 1979. A name service obsoleted by the Domain Name System, but still in use.
[Quarterman 86] Quarterman, J., and J. Hoskins, “Notable Computer Networks”,Communications of the ACM, October 1986, volume 29, number 10.
[RFC-742] K. Harrenstien, “NAME/FINGER”, RFC-742, Network Information Center, SRI International, December 1977.
[RFC-768] J. Postel, “User Datagram Protocol”, RFC-768, USC/Information Sciences Institute, August 1980.
[RFC-793] J. Postel, “Transmission Control Protocol”, RFC-793, USC/Information Sciences Institute, September 1981.
[RFC-799] D. Mills, “Internet Name Domains”, RFC-799, COMSAT, September 1981. Suggests introduction of a hierarchy in place of a flat name space for the Internet.
[RFC-805] J. Postel, “Computer Mail Meeting Notes”, RFC-805, USC/Information Sciences Institute, February 1982.
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, “DOD Internet Host Table Specification”, RFC-810, Network Information Center, SRI International, March 1982. Obsolete. See RFC-952.
[RFC-811] K. Harrenstien, V. White, and E. Feinler, “Hostnames Server”, RFC-811, Network Information Center, SRI International, March 1982. Obsolete. See RFC-953.
[RFC-812] K. Harrenstien, and V. White, “NICNAME/WHOIS”, RFC-812, Network Information Center, SRI International, March 1982.
[RFC-819] Z. Su, and J. Postel, “The Domain Naming Convention for Internet User Applications”, RFC-819, Network Information Center, SRI International, August 1982. Early thoughts on the design of the domain system. Current implementation is completely different.
[RFC-821] J. Postel, “Simple Mail Transfer Protocol”, RFC-821, USC/Information Sciences Institute, August 1980.
[RFC-830] Z. Su, “A Distributed System for Internet Name Service”, RFC-830, Network Information Center, SRI International, October 1982. Early thoughts on the design of the domain system. Current implementation is completely different.
[RFC-882] P. Mockapetris, “Domain names - Concepts and Facilities,” RFC-882, USC/Information Sciences Institute, November 1983. Superceeded by this memo.
[RFC-883] P. Mockapetris, “Domain names - Implementation and Specification,” RFC-883, USC/Information Sciences Institute, November 1983. Superceeded by this memo.
[RFC-920] J. Postel and J. Reynolds, “Domain Requirements”, RFC-920, USC/Information Sciences Institute October 1984. Explains the naming scheme for top level domains.
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, “DoD Internet Host Table Specification”, RFC-952, SRI, October 1985. Specifies the format of HOSTS.TXT, the host/address table replaced by the DNS.
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, “HOSTNAME Server”, RFC-953, SRI, October 1985. This RFC contains the official specification of the hostname server protocol, which is obsoleted by the DNS. This TCP based protocol accesses information stored in the RFC-952 format, and is used to obtain copies of the host table.
[RFC-973] P. Mockapetris, “Domain System Changes and Observations”, RFC-973, USC/Information Sciences Institute, January 1986. Describes changes to RFC-882 and RFC-883 and reasons for them. Now obsolete. [RFC-974] C. Partridge, “Mail routing and the domain system”, RFC-974, CSNET CIC BBN Labs, January 1986. Describes the transition from HOSTS.TXT based mail addressing to the more powerful MX system used with the domain system.
[RFC-1001] NetBIOS Working Group, “Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and Methods”, RFC-1001, March 1987. This RFC and RFC-1002 are a preliminary design for NETBIOS on top of TCP/IP which proposes to base NetBIOS name service on top of the DNS.
[RFC-1002] NetBIOS Working Group, “Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed Specifications”, RFC-1002, March 1987.
[RFC-1010] J. Reynolds and J. Postel, “Assigned Numbers”, RFC-1010, USC/Information Sciences Institute, May 1987 Contains socket numbers and mnemonics for host names, operating systems, etc.
[RFC-1031] W. Lazear, “MILNET Name Domain Transition”, RFC-1031, November 1987. Describes a plan for converting the MILNET to the DNS.
[RFC-1032] M. K. Stahl, “Establishing a Domain - Guidelines for Administrators”, RFC-1032, November 1987. Describes the registration policies used by the NIC to administer the top level domains and delegate subzones.
[RFC-1033] M. K. Lottor, “Domain Administrators Operations Guide”, RFC-1033, November 1987. A cookbook for domain administrators.
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, “The CSNET Name Server”, Computer Networks, vol 6, nr 3, July 1982. Describes a name service for CSNET which is independent from the DNS and DNS use in the CSNET.