web-dev-qa-db-ja.com

複数のDSレコード

検証リゾルバーが複数のDSレコードをどのように処理するのか疑問に思いました。 1つのKSKと1つのZSKを持つゾーンがあるとしますが、いくつかの主要なロールオーバーシェナニガンの後、親ゾーンに2つのDSレコードがあり、1つは現在のKSKを指し、もう1つは古い未公開を指します。もうKSK。

DNSKEY RRsetが、親のDSレコードの少なくとも1つが指すキーによって署名されている限り、リゾルバーは古いDSレコードを無視し、ゾーンを検証しますか？

domain-name-systemdnssec
4
user997904

ほとんどのオペレーターは、孤立したDSレコードが無視されることを期待します。複数のDSRRが発生する可能性があり、そのうちの1つ以上が対応するDNSKEY RRsetと一致しない可能性があり、これは十分に文書化されています。

https://tools.ietf.org/html/rfc4035#section-2.4

2.4.  Including DS RRs in a Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be present at a delegation point when the
   child zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a public key in the child zone used to verify the
   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
   RRsets MUST NOT appear at a zone's apex.

   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
   by the corresponding private key.  DS RRs that fail to meet these
   conditions are not useful for validation, but because the DS RR and
   its corresponding DNSKEY RR are in different zones, and because the
   DNS is only loosely consistent, temporary mismatches can occur.

これにより、複数のDS RRが許可され、それらのRRのそれぞれがSHOULDに対応するDNSKEYRRによって署名されることが確立されます。 Orphan DS RRに遭遇したときの正確な動作は明示されていませんが、不一致が発生する可能性があり、発生する可能性があり、予想されることが確立されています。

最後に、謝辞からDNS is only loosely consistentそれとは反対の期待は誤りです。そのため、ゾーンを偽物として削除するバリデーターの実装を作成することはできますが、そうすることはそれほど有用ではありません。結局のところ、考慮すべき主な要因は、ゾーンが署名されているかどうか、およびDSRRsetと署名されたRRの間に有効な暗号化パスがあるかどうかです。

https://tools.ietf.org/html/rfc6840#section-5.11

5.11.  Mandatory Algorithm Rules

   The last paragraph of Section 2.2 of [RFC4035] includes rules
   describing which algorithms must be used to sign a zone.  Since these
   rules have been confusing, they are restated using different language
   here:

      The DS RRset and DNSKEY RRset are used to signal which algorithms
      are used to sign a zone.  The presence of an algorithm in either a
      zone's DS or DNSKEY RRset signals that that algorithm is used to
      sign the entire zone.

      A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  It is possible to add algorithms at
      the DNSKEY that aren't in the DS record, but not vice versa.  If
      more than one key of the same algorithm is in the DNSKEY RRset, it
      is sufficient to sign each RRset with any subset of these DNSKEYs.
      It is acceptable to sign some RRsets with one subset of keys (or
      key) and other RRsets with a different subset, so long as at least
      one DNSKEY of each algorithm is used to sign each RRset.
      Likewise, if there are DS records for multiple keys of the same
      algorithm, any subset of those may appear in the DNSKEY RRset.

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.  A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.

ここで全体像がより明確になります。バリデーターは、DSとDNSKEYのすべての可能な順列をポリシングするビジネスに従事してはなりません。最も重要な詳細は、有効なパスが存在するかどうかです。

2
Andrew B