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

5. Authenticating DNS Responses (DNS応答の認証)

認証にDNSSEC RRを使用するには、セキュリティ対応リゾルバは少なくとも1つの認証済みDNSKEY RRまたはDS RRの設定済み知識を必要とします。この初期トラストアンカーを取得して認証するプロセスは、何らかの外部メカニズムを介して達成されます。例えば、リゾルバは、ゾーンのDNSKEY RRを取得するため、またはゾーンのDNSKEY RRを識別して認証するDS RRを取得するために、オフラインの認証済み交換を使用できます。このセクションの残りは、リゾルバが何らかの方法で初期トラストアンカーのセットを取得したと仮定します。

初期DNSKEY RRは、ゾーンの頂点DNSKEY RRsetを認証するために使用できます。初期鍵を使用して頂点DNSKEY RRsetを認証するには、リゾルバは以下を実行しなければなりません (MUST)：

  1. 初期DNSKEY RRが頂点DNSKEY RRsetに現れ、DNSKEY RRにZone Key Flag (DNSKEY RDATAビット7) が設定されていることを確認する
  2. 頂点DNSKEY RRsetをカバーするRRSIG RRが存在し、RRSIG RRと初期DNSKEY RRの組み合わせがDNSKEY RRsetを認証することを確認する。RRSIG RRを使用してRRsetを認証するプロセスは、セクション5.3で説明されています

リゾルバが初期DNSKEY RRを使用して頂点DNSKEY RRsetを認証すると、そのゾーンからの委任をDS RRを使用して認証できます。これにより、リゾルバは初期鍵から開始し、DS RRsetを使用してDNSツリーを再帰的に下り、他の頂点DNSKEY RRsetを取得できます。リゾルバがルートDNSKEY RRで構成されており、すべての委任に関連付けられたDS RRがある場合、リゾルバは任意の頂点DNSKEY RRsetを取得して検証できます。DS RRを使用して参照を認証するプロセスは、セクション5.2で説明されています。

セクション5.3は、リゾルバがゾーンの頂点DNSKEY RRsetを認証した後、頂点DNSKEY RRsetのDNSKEY RRとゾーンのRRSIG RRを使用して、ゾーン内の他のRRsetを認証する方法を示しています。セクション5.4は、リゾルバがゾーンの認証済みNSEC RRsetを使用して、RRsetがゾーンに存在しないことを証明する方法を示しています。

リゾルバがDNSSECのサポートを示す場合 (DOビットを設定することによって)、セキュリティ対応ネームサーバーは、応答で必要なDNSKEY、RRSIG、NSEC、およびDS RRsetを提供しようと試みるべきです (セクション3を参照)。ただし、セキュリティ対応リゾルバは、適切なDNSSEC RRを欠く応答を受信する可能性があります。これは、DNSSEC RRに誤って干渉するアップストリームのセキュリティ非対応再帰的ネームサーバーなどの構成上の問題、または敵対者が応答を偽造したり、応答からDNSSEC RRを削除したり、DNSSEC RRが要求されていないように見えるようにクエリを変更したりする意図的な攻撃によるものである可能性があります。応答にDNSSECデータがないこと自体は、認証情報が存在しないことを示すものと見なされてはなりません (MUST NOT)。

リゾルバは署名済みゾーンからの認証情報を期待すべきです (SHOULD)。リゾルバは、ゾーンの公開鍵情報で構成されている場合、またはゾーンの親が署名されており、親からの委任にDS RRsetが含まれている場合、ゾーンが署名されていると信じるべきです (SHOULD)。

5.1. Special Considerations for Islands of Security (セキュリティの孤島に関する特別な考慮事項)​

セキュリティの孤島 ([RFC4033]を参照) は、親からゾーンへの認証チェーンを構築できない署名済みゾーンです。セキュリティの孤島内で署名を検証するには、バリデータが孤島の初期認証済みゾーン鍵を取得する他の手段を持っている必要があります。バリデータがそのような鍵を取得できない場合、セキュリティの孤島内のゾーンが未署名であるかのように動作するように切り替えるべきです (SHOULD)。

応答を検証するためのすべての通常のプロセスは、セキュリティの孤島に適用されます。通常の検証とセキュリティの孤島内での検証の唯一の違いは、バリデータが認証チェーンのトラストアンカーを取得する方法です。

5.2. Authenticating Referrals (参照の認証)​

署名済み親ゾーンの頂点DNSKEY RRsetが認証されると、DS RRsetを使用して署名済み子ゾーンへの委任を認証できます。DS RRは、子ゾーンの頂点DNSKEY RRset内のDNSKEY RRを識別し、子ゾーンのDNSKEY RRの暗号化ダイジェストを含みます。強力な暗号化ダイジェストアルゴリズムを使用することで、敵対者がダイジェストに一致するDNSKEY RRを生成することが計算上不可能であることが保証されます。したがって、ダイジェストを認証することで、リゾルバは一致するDNSKEY RRを認証できます。リゾルバは、この子DNSKEY RRを使用して、子頂点DNSKEY RRset全体を認証できます。

委任のDS RRが与えられた場合、次のすべてが当てはまる場合、子ゾーンの頂点DNSKEY RRsetを認証できます：

  • DS RRが、親の頂点DNSKEY RRset内の一部のDNSKEY RRを使用して認証されている (セクション5.3を参照)
  • DS RRのAlgorithmとKey Tagが、子ゾーンの頂点DNSKEY RRset内のDNSKEY RRのAlgorithmフィールドとキータグに一致し、DNSKEY RRの所有者名とRDATAがDS RRのDigest Typeフィールドで指定されたダイジェストアルゴリズムを使用してハッシュされると、結果のダイジェスト値がDS RRのDigestフィールドに一致する
  • 子ゾーン内の一致するDNSKEY RRにZone Flagビットが設定されており、対応する秘密鍵が子ゾーンの頂点DNSKEY RRsetに署名しており、結果のRRSIG RRが子ゾーンの頂点DNSKEY RRsetを認証する

親ゾーンからの参照にDS RRsetが含まれていない場合、応答には、委任された名前のDS RRsetが存在しないことを証明する署名済みNSEC RRsetが含まれているはずです (セクション3.1.4を参照)。セキュリティ対応リゾルバは、参照にDS RRsetもDS RRsetが存在しないことを証明するNSEC RRsetも含まれていない場合、親ゾーンのネームサーバーにDS RRsetをクエリしなければなりません (MUST) (セクション4を参照)。

バリデータが、このゾーンのDS RRsetが存在しないことを証明するNSEC RRsetを認証する場合、親から子への認証パスはありません。リゾルバが子ゾーンまたは子ゾーンの下の委任に属する初期DNSKEY RRまたはDS RRを持っている場合、この初期DNSKEY RRまたはDS RRを使用して認証パスを再確立してもかまいません (MAY)。そのような初期DNSKEY RRまたはDS RRが存在しない場合、バリデータは子ゾーン内またはその下のRRsetを認証できません。

バリデータが認証済みDS RRsetにリストされているアルゴリズムのいずれもサポートしていない場合、リゾルバは親から子への認証パスをサポートしていません。リゾルバは、上記のように、DS RRsetが存在しないことを証明する認証済みNSEC RRsetの場合と同様に、このケースを処理すべきです。

署名済み委任の場合、委任された名前に関連付けられた2つのNSEC RRがあることに注意してください。1つのNSEC RRは親ゾーンに存在し、委任された名前のDS RRsetが存在するかどうかを証明するために使用できます。2番目のNSEC RRは子ゾーンに存在し、子ゾーンの頂点にどのRRsetが存在するかを識別します。親NSEC RRと子NSEC RRは、SOAビットが子NSEC RRで設定され、親NSEC RRでクリアされるため、常に区別できます。セキュリティ対応リゾルバは、DS RRsetが存在しないことを証明しようとするときに、親NSEC RRを使用しなければなりません (MUST)。

リゾルバが認証済みDS RRsetにリストされているアルゴリズムのいずれもサポートしていない場合、リゾルバは子ゾーンへの認証パスを検証できません。この場合、リゾルバは子ゾーンを未署名であるかのように扱うべきです (SHOULD)。

5.3. Authenticating an RRset with an RRSIG RR (RRSIG RRを使用したRRsetの認証)​

バリデータは、RRSIG RRとそれに対応するDNSKEY RRを使用して、RRsetを認証しようと試みることができます。バリデータは最初にRRSIG RRをチェックして、RRsetをカバーし、有効な時間間隔を持ち、有効なDNSKEY RRを識別することを確認します。次に、バリデータは、RRSIG RDATA (Signatureフィールドを除く) をカバーされたRRsetの正規形式に追加することにより、署名されたデータの正規形式を構築します。最後に、バリデータは公開鍵と署名を使用して、署名されたデータを認証します。セクション5.3.1、5.3.2、および5.3.3は、各ステップを詳細に説明します。

5.3.1. Checking the RRSIG RR Validity (RRSIG RRの妥当性チェック)​

セキュリティ対応リゾルバは、次のすべての条件が満たされる場合、RRSIG RRを使用してRRsetを認証できます：

  • RRSIG RRとRRsetは同じ所有者名と同じクラスを持たなければなりません (MUST)
  • RRSIG RRのSigner's Nameフィールドは、RRsetを含むゾーンの名前でなければなりません (MUST)
  • RRSIG RRのType Coveredフィールドは、RRsetのタイプと等しくなければなりません (MUST)
  • RRset所有者名のラベル数は、RRSIG RRのLabelsフィールドの値以上でなければなりません (MUST)
  • バリデータの現在時刻の概念は、RRSIG RRのExpirationフィールドにリストされている時刻以下でなければなりません (MUST)
  • バリデータの現在時刻の概念は、RRSIG RRのInceptionフィールドにリストされている時刻以上でなければなりません (MUST)
  • RRSIG RRのSigner's Name、Algorithm、およびKey Tagフィールドは、ゾーンの頂点DNSKEY RRset内の一部のDNSKEY RRの所有者名、アルゴリズム、およびキータグと一致しなければなりません (MUST)
  • 一致するDNSKEY RRは、ゾーンの頂点DNSKEY RRsetに存在しなければならず (MUST)、Zone Flagビット (DNSKEY RDATA Flagビット7) が設定されていなければなりません (MUST)

上記の条件に一致する複数のDNSKEY RRが存在する可能性があります。この場合、バリデータは署名を認証するためにどのDNSKEY RRを使用するかを事前に決定できず、署名が検証されるか、バリデータが試行する一致する公開鍵を使い果たすまで、各一致するDNSKEY RRを試行しなければなりません (MUST)。

この認証プロセスは、バリデータが署名を検証するために使用する前にDNSKEY RRを認証する場合にのみ意味があることに注意してください。一致するDNSKEY RRは、次の場合に認証済みと見なされます：

  • DNSKEY RRを含む頂点DNSKEY RRsetが認証済みと見なされる場合、または
  • RRSIG RRでカバーされるRRsetが頂点DNSKEY RRset自体であり、DNSKEY RRが親ゾーンの認証済みDS RRに一致するか、トラストアンカーに一致する場合

5.3.2. Reconstructing the Signed Data (署名されたデータの再構築)​

RRSIG RRがセクション5.3.1で説明されている妥当性要件を満たすと、バリデータは元の署名されたデータを再構築する必要があります。元の署名されたデータには、RRSIG RDATA (Signatureフィールドを除く) とRRsetの正規形式が含まれます。順序付けられていることに加えて、RRsetの正規形式は、DNS名圧縮、減少したTTL、またはワイルドカード展開により、受信したRRsetとも異なる場合があります。バリデータは、元の署名されたデータを再構築するために次を使用する必要があります：

signed_data = RRSIG_RDATA | RR(1) | RR(2)...  ここで

   "|" は連結を示す

   RRSIG_RDATAは、Signatureフィールドが除外され、Signer's Nameが
   正規形式であるRRSIG RDATAフィールドのワイヤ形式です。

   RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

      nameは以下の関数に従って計算されます

      classはRRsetのクラスです

      typeはRRsetタイプであり、クラス内のすべてのRRです

      OrigTTLはRRSIG Original TTLフィールドの値です

      RDATAフィールド内のすべての名前は正規形式です

      すべてのRR(i)のセットは正規順序にソートされます。

   名前を計算するには：
      rrsig_labels = RRSIG Labelsフィールドの値

      fqdn = RRsetの正規形式の完全修飾ドメイン名

      fqdn_labels = 上記のfqdnのラベル数

      rrsig_labels = fqdn_labelsの場合、
          name = fqdn

      rrsig_labels < fqdn_labelsの場合、
         name = "*." | fqdnの右端のrrsig_labelラベル

      rrsig_labels > fqdn_labelsの場合
         RRSIG RRは必要な検証チェックに合格せず、
         このRRsetを認証するために使用してはなりません (MUST NOT)。

名前とRRsetの正規形式は、[RFC4034]で定義されています。

委任境界のNSEC RRsetには特別な処理が必要です。署名済み委任名に関連付けられた2つの異なるNSEC RRsetがあります。1つのNSEC RRsetは親ゾーンに存在し、親ゾーンにどのRRsetが存在するかを指定します。2番目のNSEC RRsetは子ゾーンに存在し、子ゾーンの頂点にどのRRsetが存在するかを識別します。親NSEC RRsetと子NSEC RRsetは、子NSEC RRのみがSOA RRsetが名前に存在することを示すため、常に区別できます。親ゾーンからの委任の元のNSEC RRsetを再構築する場合、NSEC RRを子ゾーンのNSEC RRと組み合わせてはなりません (MUST NOT)。子ゾーンの頂点の元のNSEC RRsetを再構築する場合、NSEC RRを親ゾーンのNSEC RRと組み合わせてはなりません (MUST NOT)。

委任ポイントの2つのNSEC RRsetのそれぞれには、委任された名前に一致する所有者名を持つ対応するRRSIG RRがあり、これらのRRSIG RRのそれぞれは、対応するNSEC RRsetを含む同じゾーンに関連付けられた権威データです。必要に応じて、リゾルバはSigner's Nameフィールドをチェックすることにより、これらのRRSIG RRを区別できます。

5.3.3. Checking the Signature (署名のチェック)​

リゾルバがセクション5.3.1で説明されているようにRRSIG RRを検証し、セクション5.3.2で説明されているように元の署名されたデータを再構築すると、バリデータは暗号化署名を使用して署名されたデータを認証し、したがって (ついに!) RRsetを認証しようと試みることができます。

RRSIG RRのAlgorithmフィールドは、署名を生成するために使用される暗号化アルゴリズムを識別します。署名自体はRRSIG RDATAのSignatureフィールドに含まれ、署名を検証するために使用される公開鍵は、一致するDNSKEY RR(s) (セクション5.3.1で見つかった) のPublic Keyフィールドに含まれます。[RFC4034]は、アルゴリズムタイプのリストを提供し、各アルゴリズムの使用を定義するドキュメントへのポインタを提供します。

5.4. Authenticated Denial of Existence (認証された存在の否定)​

リゾルバは、認証済みNSEC RRを使用して、RRsetが署名済みゾーンに存在しないことを証明できます。セキュリティ対応ネームサーバーは、署名済みゾーンに必要なNSEC RRをセキュリティ対応リゾルバへの応答に自動的に含めるべきです。

存在の否定は、次のルールによって決定されます：

  • 要求されたRR名が認証済みNSEC RRの所有者名と一致する場合、NSEC RRのタイプビットマップフィールドは、その所有者名に存在するすべてのRRタイプをリストし、リゾルバはビットマップでRRタイプをチェックすることにより、要求されたRRタイプが存在しないことを証明できます。認証済みNSEC RRの所有者名のラベル数がカバーするRRSIG RRのLabelsフィールドと等しい場合、NSEC RRの存在は、要求に一致するためにワイルドカード展開が使用できなかったことを証明します。

  • 要求されたRR名が、[RFC4034]で定義された正規DNS名順序に従って、認証済みNSEC RRの所有者名の後、そのNSEC RRのNext Domain Nameフィールドにリストされている名前の前に表示される場合、要求された名前のRRsetはゾーンに存在しません。ただし、要求されたRR所有者名とタイプに一致するためにワイルドカードが使用される可能性があるため、要求されたRRsetが存在しないことを証明するには、肯定的な応答を生成するために使用された可能性のあるワイルドカードRRsetが存在しないことも証明する必要があります。

さらに、セキュリティ対応リゾルバは、セクション5.3で説明されているように、非存在証明を構成するNSEC RRsetを認証しなければなりません (MUST)。

RRsetの非存在を証明するには、リゾルバは、クエリされたRRsetが存在しないこと、および関連するワイルドカードRRsetが存在しないことの両方を検証できなければなりません。これを証明するには、ゾーンから複数のNSEC RRsetが必要になる場合があります。必要なNSEC RRsetの完全なセットが応答に存在しない場合 (おそらくメッセージの切り捨てによる)、セキュリティ対応リゾルバは、要求されたRRsetの非存在を検証するために必要なNSEC RRの完全なコレクションを取得しようとするためにクエリを再送信しなければなりません (MUST)。ただし、すべてのDNS操作と同様に、リゾルバは特定のクエリに答えるために行う作業を制限しなければなりません (MUST)。

検証済みNSEC RRは、それ自体とその対応するRRSIG RRの両方の存在を証明するため、バリデータはNSEC RR内のNSECおよびRRSIGビットの設定を無視しなければなりません (MUST)。

5.5. Resolver Behavior When Signatures Do Not Validate (署名が検証されない場合のリゾルバの動作)​

何らかの理由でRRSIGのいずれも検証できない場合、応答はBADと見なされるべきです (SHOULD)。検証が再帰的クエリにサービスを提供するために行われていた場合、ネームサーバーは元のクライアントにRCODE 2を返さなければなりません (MUST)。ただし、元のクエリにCDビットが設定されていた場合に限り、完全な応答を返さなければなりません (MUST)。検証されない応答のキャッシングについては、セクション4.7も参照してください。

5.6. Authentication Example (認証の例)​

付録Cは、認証プロセスの例を示しています。

に最終更新