1 2 3 4 | |
https://www.dazhuanlan.com/xwuxin/topics/1848106
DNSSEC 验证流程
第一步：RRSIG
前述提到，DNSSEC 的状况下，每一个纪录都应该要经过数字签章做签署的动作。所以 DNSSEC 里面有提到一种 DNS 纪录，这个纪录叫做 RRSIG，会附在 DNS 请求的回复当中。
内容大概像这样：
1 2 3 4 5 6 7 8 9 | |
第一行是 ai.example 这个网域的 MX 纪录。
第二行是给第一笔记录使用的 RRSIG 纪录。
RRSIG 的格式是这样的：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
DNSKEY
随着 RRSIG 的出现，我们拿到凭证的内容了。不过我们需要验证这个签章是不是伪造的，然后是谁签的。这个信息，会在 DNSKEY 纪录当中。
1 2 3 4 5 6 7 | |
DNSKEY 里面会包含拿去签署 RRSIG 的公钥。
不过，即使我们能够确认「这个 RRSIG 和 DNSKEY 对得起来」，也还不能够确认「这个 DNSKEY 真的属于这个网域」。
所以我们会需要一个能够信任方式，来验证这个 DNSKEY。
就像前面提到的 HTTPS 凭证信任链的状况，我们可能有几种做法，可以验证这个东西：
用其他的方式去获得「这个网域真正的公钥」，例如 PGP、中华邮政寄 U 盘、用纸抄、用 scp 先下载一份
叫别人证明你是合法的（参考 HTTPS 中介凭证机制）
信任链机制
前述提到，只拿到 DNSKEY 没什么用。然后若要将上述第一种取得真正公钥的方式，放到 DNS 这种许多人用的协定之上，是不可行的。想像一下，你要联网之前，必须要插 U 盘。这是一个多荒诞的事情？
所以，我们可以依赖上一级网域的 DNS 纪录，把上一级凭证的公钥放在那边。在 DNSSEC 中，这个叫做 DS (Delegation Signer) 纪录。由于你可以指定非常多的子网域，所以 DS 纪录中，只会记载「这个凭证的指纹 (hash)」。
真的很短，他长得像这样：
1 2 | |
然后假设一笔 DNSKEY 是被上一级签署过的话，他会看起来像这样：
1 2 3 4 5 6 7 8 9 | |
其中，我们会发现 key id 和上面的 DS 纪录是一样的。另外，是可以通过 DNSKEY 去计算出 DS 的数值，所以我们可以通过证明这两个之间的关系，来保证 DNSKEY 纪录的可靠性。 特殊状况: 找不到纪录怎么办？ (NSEC)
在 DNS 的状况下，基本上，若找不到东西，只要回复 NXDOMAIN 就好了。不过在 DNSSEC 的状况下，由于回复的数据内容内也要证明这消息不是伪造的，但这东西根本查不到，所以我们要想办法告诉对方「我真的找不到」。
DNSSEC 想到了这个问题，所以又有一种纪录叫做 NSEC (Next Secure)。这个纪录里面会记载说「下一笔纪录是什么」。
所以，假设今天有 A、B、D。有人问了 C，你找不到，但是你可以用 NSEC 和他说：「下一笔真的是 D，我知道他还有 A、RRSIG 和 NSEC，你可以看看 D 是不是真的有这些东西」来确保你没有说谎。
由于 DNS 纪录是以字母来做排序的，所以你可以确定「真的没有那笔东西」。
另外，若某一个网域的纪录是存在的，只是问错类别（例如你有 A 但对方问 MX）的话，这时候的回复里面会告诉对方这个网域所有的纪录。
不过，不管是不是这个状况，NSEC 都有可能引起安全疑虑，之后会提到。