1. はじめにと背景 (Introduction and Background)

DNS プロトコル [RFC1035] は、応答コード 3 を「名前エラー (Name Error)」、または「NXDOMAIN」 [RFC2308] と定義しており、これはクエリされたドメイン名が DNS に存在しないことを意味します。ドメイン名はラベルのツリー ([RFC1034]、セクション 3.1) として表されるため、ノードが存在しないことは、このノードをルートとするサブツリー全体が存在しないことを意味します。

DNS 反復解決アルゴリズムは、NXDOMAIN 信号をまさにこの方法で解釈します。権威サーバーからの NXDOMAIN 応答コードに遭遇すると、すぐに反復を停止し、NXDOMAIN 応答をクエリ送信者に返します。

ただし、今日存在するほとんどの既知のリゾルバでは、ドメインのキャッシュされた非存在は、その下に子ドメインが存在できないことの「証明」とは見なされません。これは、[RFC1034] の曖昧さが原因で、空の非端末 (Empty Non-Terminal, ENT) 名 ([RFC7719]) と存在しない名前 (セクション 3.1) を区別できなかったためです。この区別は、非存在の証明を提供する DNSSEC の開発にとって特に重要になりました。[RFC4035] のセクション 3.1.3.2 では、セキュリティを意識した権威ネームサーバーがどのように区別を行うかについて説明していますが、再帰ネームサーバーの動作について説明している既存の RFC はありません。

このドキュメントは、ドメイン名の NXDOMAIN 応答は、クエリされた名前の下に子ドメインも存在しないことを意味することを規定しています。さらに、DNS リゾルバはキャッシュされた非存在をこの方法で解釈すべきであることを意味します。ドメイン名はツリーで構成されているため、これはツリー構造の単純な帰結です。ノードが存在しないことは、このノードをルートとするサブツリー全体が存在しないことを意味します。

1.1. 用語 (Terminology)

本書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、[RFC2119] で説明されているように解釈されます。

"QNAME": [RFC1034] および [RFC1035] のセクション 4.1.2 で定義されていますが、[RFC2308] が異なる定義を提供しているため、ここで元の定義を繰り返します。QNAME は質問セクションのドメイン名です。

「拒否された名前 (Denied name)」: 応答 RCODE が NXDOMAIN によってその存在が拒否されたドメイン名。ほとんどの場合、それは QNAME ですが、[RFC6604] のため、常にそうであるとは限りません。

その他の用語は [RFC1034]、[RFC1035]、および (NXDOMAIN 自体のように) より最近の [RFC7719] で定義されています。

ドメイン名空間は、概念的にはツリー構造の観点から定義されています。DNS リゾルバ/キャッシュの実装は、ツリーまたは他のデータ構造を使用してもよい (MAY)。キャッシュはドメイン名空間内のデータのサブセットであるため、そのツリー構造の観点から推論し、それらの用語（下の/上の名前、子孫の名前、サブツリーなど）で物事を説明する方がはるかに簡単です。実際、[RFC1034] の DNS アルゴリズムの説明では、キャッシュがツリー構造であるという仮定さえ述べているため、前例はすでに十分に確立されています。そのセクション 4.3.2 を参照してください。そこには、「次のアルゴリズムは、RR がいくつかのツリー構造（各ゾーンに 1 つ、キャッシュに 1 つ...）で構成されていることを前提としています」とあります。したがって、このドキュメントでは、ツリーまたはツリー操作について話すたびに、実際の実装ではなくモデルを参照しています。