服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 多个DSlogging
Intereting Posts
McAfee Security Scan无处不在 AutoSys R4 JobProfiles有一个命令行工具吗？ 在使用“eb start”命令行实用程序创buildElastic Beanstalk环境时如何标记Elastic Beanstalk环境？ 无法通过SSHlogin到Synology NAS上的任何使用/ bin / bash shell的帐户 如何检查两台服务器是否安装了相同的function和更新？ Linux系统上的后门和zmeu进程 Exchange 2013 – 在iSCSI下降后的0kb EDB文件 Windows更新客户端从WSUS服务器 – 手动 RabbitMQ启动失败 多个开发人员只有一个Git帐户？ gitlab apacheredirect循环 MySQL：慢查询日志中的怪异日志消息 在ESXI 6.0上丢失内存 如何旋转PHP错误日志？ Powershell脚本从多个文件夹复制名为'dat'的文件

多个DSlogging

我想知道如何validationparsing器处理多个DSlogging。 假设我们有一个带有一个KSK和一个ZSK的区域，但是在一些关键的翻转恶意软件之后，在父区域中有两个DSlogging，一个指向当前的KSK，一个指向一个更老的KSK。

parsing器是否会忽略旧的DSlogging并validation该区域，只要DNSKEY RRset由至less一个父logging中的DSlogging指向的密钥签名？

大多数操作员会认为孤儿DSlogging会被忽略。 可能遇到多个DS RR，其中的一个或多个可能与相应的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.

这build立了允许多个DS RR，并且每个RR SHOULD由对应的DNSKEY RR签名。 虽然遇到孤儿DS RR时的确切行为并不明确，但确定错配可以发生，并且是可以预料的。

最后，人们可以从这个认识中得出结论： DNS is only loosely consistent ，相反的预期是错误的。 因此，我们当然可以编写一个validation器实现，将该区域视为虚假，但这样做并不是非常有用。 在一天结束时，需要考虑的主要因素是区域是否被签名以及DS RRset和签名RR之间是否存在有效的encryptionpath。

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.

整体情况在这里变得更加清晰。 validation者不应该在DS和DNSKEY所有可能排列中进行pipe理。 最重要的细节是否存在有效的path。