メインコンテンツまでスキップ

5. リソースレコードセット

各 DNS リソースレコード (Resource Record, RR) は、ラベル、クラス、タイプ、およびデータを持つ。2 つのレコードがラベル、クラス、タイプ、データのすべてにおいて等しくなることは無意味であり、サーバーはそのような重複に遭遇した場合には抑制すべきである。しかし、ほとんどのレコードタイプでは、同じラベル、クラス、タイプでありながら異なるデータを持つことが可能である。このようなレコードのグループを、ここでリソースレコードセット (Resource Record Set, RRSet) と定義する。

5.1. RRSet からの RR の送信​

特定の (または特定でない) ラベル、クラス、タイプに対するクエリは、関連する RRSet 内のすべてのレコードを常に返す (それが 1 つの RR であっても複数であっても)。RRSet 全体が応答に収まらない場合、その応答は「切り詰められた」とマークされなければならない。

5.2. RRSet 内の RR の TTL​

リソースレコードは生存時間 (TTL) も持つ。RRSet 内の RR が異なる TTL を持つことが可能である。これに対する用途で、他の方法ではよりよく達成できないものは見つかっていない。しかしこれは、RRSet 内の一部の RR の TTL は満了しているがすべてではない場合に、キャッシュサーバーからの部分的な応答 (「切り詰められた」とマークされていない) を引き起こす可能性がある。

したがって、RRSet 内で異なる TTL を使用することはここに非推奨とされ、RRSet 内のすべての RR の TTL は同じでなければならない。

クライアントが、異なる TTL を持つ RRSet からの RR を含む応答を受け取った場合、これをエラーとして扱うべきである。該当する RRSet がこのデータにとって非権威的な情報源からのものである場合、クライアントはその RRSet を単に無視すべきであり、その値が必要であったならば、権威的な情報源からそれらを取得しようと努めるべきである。すべてのクエリを 1 つ以上の特定のサーバーに送信するように構成されたクライアントは、この目的においてそれらのサーバーを権威的として扱うべきである。権威的な情報源がそのような不正な RRSet を送信した場合、クライアントは、あらゆる目的において、RRSet 内のすべての TTL がその RRSet 内で最小の TTL の値に設定されていたかのように RR を扱うべきである。いかなる場合も、サーバーは TTL がすべて等しくない RRSet を送信してはならない。

5.3. DNSSEC の特殊なケース​

DNS セキュリティ (DNSSEC) [RFC2065] によって追加されたレコードタイプのうち 2 つは、リソースレコードセットの形成を考える際に特別な注意を要する。それは SIG レコードと NXT レコードである。DNS セキュリティはまだ非常に新しく、現時点ではこれに関する経験がほとんどないことに注意すべきである。読者は、DNS セキュリティ仕様が成熟するにつれて、この文書に含まれる DNSSEC に関連する情報が古くなる可能性があることを覚悟しておくべきである。

5.3.1. SIG レコードと RRSet​

SIG レコードは、DNS 内の別の RRSet に対する署名 (検証) データを提供する。ゾーンが署名されている場合、そのゾーン内のすべての RRSet には、対応する SIG レコードが関連付けられている。RRSet のデータタイプは SIG RR のデータに含まれており、この SIG レコードがどの特定の RRSet に関連付けられているかを示す。上記の規則が適用されると、応答を検証するために SIG レコードが応答に含められるたびに、適切なノードに関連付けられた他のすべての RRSet の SIG レコードも含める必要があることになる。場合によっては、これは非常に多数のレコードになり得て、それらがかなり大きな RR であることも事態を助けない。

したがって、権威セクションに、「type covered」フィールドが返される回答の type フィールドと等しい SIG RR のみを含めることが特別に許可されている。しかし、SIG レコードが回答セクションで返される場合、つまり SIG レコードに対するクエリ、または名前に関連付けられたすべてのレコードに対するクエリ (type=ANY) への応答として返される場合は、他のあらゆる RR タイプと同様に、SIG RRSet 全体を含めなければならない。

権威セクションに SIG レコードを含む応答、または (おそらく誤って) 追加データとして含む応答を受け取ったサーバーは、RRSet 全体がほぼ確実に含まれていないことを理解しなければならない。したがって、そのサーバーで SIG レコードに対するクエリを受信した場合にそれを返すことを許すような方法で、その SIG レコードをキャッシュしてはならない。RFC2065 は実際、ここで引き起こされる可能性のある問題を避けるために、SIG クエリを権威サーバーにのみ送信することを要求しており、SIG レコードの特別な性質を理解しないサーバーが存在する限り、これは必要であり続ける。しかし、新しい実装における SIG レコード処理を慎重に設計すれば、将来この制限を緩和できるようになるはずであり、その結果リゾルバは SIG レコードのクエリを特別に扱う必要がなくなる。

受信した SIG レコードの要求は、キャッシュ内のデータから応答するのではなく、権威サーバーに転送すべきであると時折述べられてきた。これは必要ではない。このように処理するための特別なケースとして SIG の知識を持つサーバーは、SIG レコードの特性を考慮して正しくキャッシュする方がよい。そうすればサーバーは、キャッシュから応答しても安全なのはいつか、また回答が利用できずクエリを転送しなければならないのはいつかを判断できる。

5.3.2. NXT RR​

次リソースレコード (NXT) はさらに独特である。ゾーン内の特定のラベルに対して存在する NXT レコードは常に 1 つだけなので、表面的には RRSet の問題は些細である。しかしゾーンカットでは、親ゾーンと子ゾーン (RFC2065 の用語ではスーパーゾーンとサブゾーン) の両方が同じ名前の NXT レコードを持つ。これら 2 つの NXT レコードは、両方のゾーンが同じサーバーに置かれている場合でも、RRSet を形成しない。NXT RRSet は常に単一の RR だけを含む。両方の NXT レコードが見える場合、2 つの RRSet が存在する。しかしサーバーは、応答内で NXT レコードを受信する際にこれを特別なケースとして扱うことを要求されない。2 つの異なる NXT RRSet の存在に気付き、それを他のタイプの 2 つの異なる RRSet と同様に扱うことを選んでもよい。つまり、一方をキャッシュし、他方を無視するのである。ただしセキュリティを意識したサーバーは、受信した応答内の NXT レコードを正しく処理する必要がある。

5.4. RRSet の受信​

サーバーは、RRSet を形成するために応答からの RR をキャッシュ内の RR と決してマージしてはならない。応答に含まれるデータがサーバーのキャッシュ内のデータと RRSet を形成することになる場合、サーバーは応答内の RR を無視するか、現在キャッシュにある RRSet 全体を破棄するかのいずれかを、適切に応じて行わなければならない。したがって、キャッシュと応答の間で TTL が異なるという問題は懸念を引き起こさず、一方は無視される。つまり、回答からのデータがキャッシュ内のデータと異なる場合、データセットの一方は常に不正確である。サーバーにとっての課題は、どちらのデータセットが (もし正しいものがあるなら) 正しいかを判断し、それを保持しつつ他方を無視することである。サーバーが、TTL 値を除いてキャッシュ内のものと同一の RRSet を含む回答を受信した場合、任意で、キャッシュ内の TTL を受信した回答の TTL で更新してもよいことに注意されたい。受信した回答が以前にキャッシュされた回答よりも権威的であると見なされる場合 (次の節で論じる)、そうすべきである。

5.4.1. データのランク付け​

応答内の RRSet を受け入れるか、それともすでにキャッシュにある RRSet を保持するかを検討する際、サーバーは各種データの相対的な信頼性の見込みを考慮すべきである。応答からの権威的な回答は、以前の応答の追加情報から得られたキャッシュデータを置き換えるべきである。ただし、キャッシュに権威的な回答またはゾーンファイルからのデータが含まれている場合、応答からの追加情報は無視される。

利用可能なデータの正確さはその情報源から推定される。信頼性は、高い方から低い方へ次の順序とする。

  • プライマリゾーンファイルからのデータ (グルーデータを除く)、
  • ゾーン転送からのデータ (グルーを除く)、
  • 権威的な応答の回答セクションに含まれる権威的データ。
  • 権威的な回答の権威セクションからのデータ、
  • プライマリゾーンからのグルー、またはゾーン転送からのグルー、
  • 非権威的な回答の回答セクションからのデータ、および権威的な回答の回答セクションからの非権威的データ、
  • 権威的な回答からの追加情報、非権威的な回答の権威セクションからのデータ、非権威的な回答からの追加情報。

権威的な回答の回答セクションは通常、権威的データのみを含むことに注意されたい。しかし、求められている名前が別名 (alias) である場合 (10.1.1 節を参照)、その別名を記述するレコードのみが必然的に権威的である。クライアントは、他のレコードがサーバーのキャッシュから来た可能性があると想定すべきである。権威的な回答が必要な場合、クライアントは別名に関連付けられた正規名を使用して再度クエリすべきである。

それらのグループの中で最も信頼性の低いもの、つまり追加データセクションからのデータ、および非権威的な回答の権威セクションからのデータから受信されキャッシュされた未認証の RR は、受信したクエリへの回答として返されることが決してないような方法でキャッシュされるべきではない。それらは適切な場合には追加情報として返されてもよい。これを無視すると、比較的信頼性の低いデータの信頼性が、理由も根拠もなく引き上げられることになる。

DNS セキュリティ [RFC2065] が使用されており、認証された応答が受信され検証された場合、そのように認証されたデータは、同じタイプの未認証データよりも信頼できると見なされる。この文書全体を通じて、「権威的」とは AA ビットが設定された応答を意味することに注意されたい。DNSSEC は SIG レコードと KEY レコードの信頼の連鎖を使用してデータの真正性を判断し、AA ビットはほとんど無関係である。しかし DNSSEC を認識するサーバーは、セキュリティを認識しないサーバー (現在はほとんどすべて) との正しい動作を可能にするために、応答内の AA ビットを依然として正しく設定しなければならない。

グルーを除き、2 つの正しく構成されたプライマリゾーンファイルからのデータ、2 つの正しく構成されたセカンダリゾーン (ゾーン転送からのデータ)、または正しく構成されたプライマリゾーンとセカンダリゾーンからのデータが互いに競合することは不可能であることに注意されたい。同じ名前のグルーが複数のゾーンに存在し、その値が異なる場合、ネームサーバーはプライマリゾーンファイルからのデータをセカンダリよりも優先して選択すべきであるが、それ以外の場合はそのようなデータの任意の 1 つのセットを選択してよい。権威的データソースに近いと思われる情報源から来ているように見えるものを選択することは、それが判断できる場合には理にかなっているかもしれない。プライマリデータをセカンダリよりも選択することにより、そのようなデータに問題が存在する場合に、不正確なグルーデータの情報源をより容易に発見できるようになる。サーバーが 2 つのゾーンファイルから、1 つ以上が競合を生み出すように誤って構成されていることを検出できる場合、誤りであると判断されたゾーンの読み込みを拒否し、適切な診断を発行すべきである。

上記の「グルー」には、そのゾーンの適切な一部ではないゾーンファイル内のあらゆるレコードが含まれ、委任されたサブゾーンのネームサーバーレコード (NS レコード)、それらの NS レコードに付随するアドレスレコード (A、AAAA など)、および現れる可能性のあるその他のあらゆる余分なデータを含む。

5.5. RRSet の送信 (再説)​

リソースレコードセットは、いかなる DNS 応答においても 1 回だけ含められるべきである。必要に応じて、回答、権威、または追加情報のいずれかのセクションに現れてよい。しかし、仕様によって明示的に要求される場合を除き、同じセクションまたは他のいかなるセクションでも繰り返されるべきではない。例えば、AXFR 応答では、SOA レコード (常に単一の RR を含む RRSet) が応答の最初と最後の両方のレコードであることが要求される。このように重複が必要な場合、それぞれの場合に送信される TTL は同じでなければならない。