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

5. Resource Record Sets (リソースレコードセット)

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

5.1. Sending RRs from an RRSet (RRSetからのRR送信)​

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

5.2. TTLs of RRs in an RRSet (RRSet内のRRのTTL)​

リソースレコードには生存時間 (Time to Live, TTL) もあります。RRSet内のRRは異なるTTLを持つ可能性があります。他の方法でより良く達成できない用途は見つかっていません。しかし、これはキャッシングサーバーからの部分的な応答（「切り詰められた」とマークされていない）を引き起こす可能性があり、RRSet内の一部のRRのTTLが期限切れになっています。

したがって、RRSet内で異なるTTLを使用することは非推奨とされ、RRSet内のすべてのRRのTTLは同じでなければなりません (must)。

クライアントが異なるTTLを持つRRSetからのRRを含む応答を受信した場合、これをエラーとして扱うべきです (should)。関係するRRSetがこのデータの非権威ソースからのものである場合、クライアントは単にそのRRSetを無視し、値が必要な場合は権威ソースから取得することを求めるべきです (should)。すべてのクエリを1つまたは複数の特定のサーバーに送信するように構成されたクライアントは、この目的のためにそれらのサーバーを権威として扱うべきです (should)。権威ソースがこのような不正な形式のRRSetを送信した場合、クライアントはすべての目的において、RRSet内のすべてのTTLがRRSet内の最小TTLの値に設定されているかのように、RRのすべてのRRを扱うべきです (should)。いかなる場合も、サーバーはTTLがすべて等しくないRRSetを送信してはなりません (may not)。

5.3. DNSSEC Special Cases (DNSSEC特殊ケース)​

DNSセキュリティ (DNS Security, DNSSEC) [RFC2065] によって追加された2つのレコードタイプは、リソースレコードセットの形成を考慮する際に特別な注意が必要です。これらはSIGレコードとNXTレコードです。DNSセキュリティはまだ非常に新しく、これまでのところ経験がほとんどないことに注意すべきです。読者は、本文書に含まれるDNSSEC関連の情報が、DNSセキュリティ仕様の成熟に伴って古くなることに備えるべきです。

5.3.1. SIG records and RRSets (SIGレコードとRRSet)​

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

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

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

受信したSIGレコードの要求を、キャッシュ内のデータから応答するのではなく、権威サーバーに転送すべきであるとたまに述べられてきました。これは不要です——このようにSIGの知識を特殊ケースとして処理するサーバーは、その特性を考慮してSIGレコードを正しくキャッシュする方が良いでしょう。その後、サーバーはキャッシュから安全に応答できるタイミングと、応答が利用できずクエリを転送する必要があるタイミングを判断できます。

5.3.2. NXT RRs (NXTリソースレコード)​

次のリソースレコード (Next Resource Record, NXT) はさらに特殊です。特定のラベルに対して、ゾーン内には1つのNXTレコードしか存在しないため、表面的にはRRSetの問題は些細なことです。ただし、ゾーンカットでは、親ゾーンと子ゾーン（RFC2065の用語では上位ゾーンと下位ゾーン）が同じ名前のNXTレコードを持ちます。これら2つのNXTレコードは、両方のゾーンが同じサーバーに格納されている場合でも、RRSetを形成しません。NXT RRSetには常に単一のRRのみが含まれます。両方のNXTレコードが表示される場合、2つのRRSetが存在します。ただし、サーバーは応答でNXTレコードを受信するときに、これを特殊ケースとして扱う必要はありません。2つの異なるNXT RRSetの存在に気づき、他のタイプの2つの異なるRRSetと同じように扱うことを選択できます。つまり、一方をキャッシュし、他方を無視します。セキュリティ対応サーバーは、受信した応答内のNXTレコードを正しく処理する必要があります。

5.4. Receiving RRSets (RRSetの受信)​

サーバーは、RRSetを形成するために、応答からのRRをキャッシュ内のRRとマージしてはなりません (must never)。応答にサーバーのキャッシュ内のデータとRRSetを形成するデータが含まれている場合、サーバーは応答内のRRを無視するか、現在キャッシュにあるRRSet全体を破棄する必要があります (must)。したがって、キャッシュと応答の間のTTLの変動の問題は懸念を引き起こしません。一方が無視されます。つまり、応答からのデータがキャッシュ内のデータと異なる場合、データセットの1つは常に誤っています。サーバーにとっての課題は、どちらのデータセットが正しいか（もしあれば）を判断し、そのデータセットを保持しながら他方を無視することです。サーバーがキャッシュ内のRRSetと同一のRRSetを含む応答を受信した場合（TTL値を除く可能性がある）、受信した応答のTTLでキャッシュ内のTTLを更新することができます (may)。受信した応答が以前にキャッシュされた応答よりも権威的であると考えられる場合（次のセクションで説明）、これを行うべきです (should)。

5.4.1. Ranking data (データのランク付け)​

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

利用可能なデータの正確性は、その情報源から推定されます。信頼性は、最も高いものから最も低いものへの順序で次のようになります：

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

権威応答の応答セクションには通常、権威データのみが含まれることに注意してください。ただし、検索される名前がエイリアスである場合（セクション10.1.1を参照）、そのエイリアスを説明するレコードのみが必然的に権威的です。クライアントは、他のレコードがサーバーのキャッシュから来た可能性があると想定すべきです (should)。権威応答が必要な場合、クライアントはエイリアスに関連付けられた正規名を使用して再度クエリを実行すべきです (should)。

最も信頼性の低いグループ、つまり追加データセクションからのデータと非権威応答の権限セクションからのデータから受信およびキャッシュされた認証されていないRRは、受信したクエリへの応答として返されることを許可する方法でキャッシュされるべきではありません (should not)。適切な場合、追加情報として返すことができます (may)。これを無視すると、比較的信頼性の低いデータの信頼性が理由や言い訳なしに増加することになります。

DNSセキュリティ [RFC2065] が使用され、認証された応答が受信および検証された場合、そのように認証されたデータは、同じタイプの認証されていないデータよりも信頼できるものとして扱われるべきです (shall)。本文書全体で、「権威的」(authoritative) はAAビットが設定された応答を意味することに注意してください。DNSSECは、信頼されたSIGおよびKEYレコードのチェーンを使用してデータの真正性を判断し、AAビットはほとんど無関係です。ただし、DNSSEC対応サーバーは、セキュリティ対応でないサーバー（現在ほとんどすべて）との正しい動作を可能にするために、応答内でAAビットを正しく設定する必要があります (must)。

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

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

5.5. Sending RRSets (reprise) (RRSetの送信（再説）)​

リソースレコードセットは、任意のDNS応答に1回のみ含まれるべきです (should)。必要に応じて、応答、権限、または追加情報セクションのいずれかに表示される可能性があります (may)。ただし、仕様で明示的に要求されている場合を除き、同じまたは他のセクションで繰り返されるべきではありません (should not)。たとえば、AXFR応答では、SOAレコード（常に単一のRRを含むRRSet）が応答の最初のレコードと最後のレコードの両方である必要があります。このように重複が必要な場合、各ケースで送信されるTTLは同じでなければなりません (must)。

に最終更新