签名的可信，前提是拿到的那把公钥确实是这家机构的。域名系统逐级托管，子区的钥匙由父区指认。DS 记录就是父区里那一行指认，它装的不是钥匙本身，而是钥匙的摘要。

第 71 期讲过 DNSSEC 的信任链：根区签了名，下面各级区域再逐级衔接上去。衔接靠的就是 DS 记录，但那一期只用了一句话带过，没展开。

链条要解决的问题是：解析器拿到一份签名，怎么确定签名用的公钥属于它自称的那家机构。答案是把公钥的指认存放在上一级。com 区里存着 example.com 的 DS 记录，里面是 example.com 那把密钥的摘要，由 Key Tag、算法和 Digest 几个字段组成。摘要不可逆，解析器拿到子区公布的公钥后自己算一遍，对得上才继续往下验证。

这一行的位置不寻常。父区通常不在委派点上存放子区的数据，区与区之间的界线就画在那里。DS 和 NSEC 是标准里明确开出的例外——信任链必须有一处接口，而委派点正是唯一合适的落点。

运维上的麻烦也出在这里。子区想换密钥，得让父区同步换掉 DS 记录，换了之后两边还要对得上；推不动父区的时候，链条就断了，域名直接解析不了。为了这件事，后来加了一条自动通道：子区把 CDS 和 CDNSKEY 记录发在自己区里，父区来取、来更新，不必再走人工流程。

摘要算法由国际号码分配机构的注册表指定，旧的算法会随安全性评估调整推荐状态。RFC 4034 是最初的 DS 记录标准，当时只定义了 SHA-1 一种摘要类型并把它列为必须支持；SHA-1 后来不再用于新签发、SHA-256 成为推荐值，是由后续的标准更新做出去的。