像 IPv6 一样，DNSSEC 也是一项伟大的前瞻性协议，但不幸的是，它尚未得到广泛采用。在我自己实施它之前，我能理解原因。虽然有些人认为 BIND 本身就很难设置，但 DNSSEC 增加了一个额外的密钥层、密钥管理和大量额外的 DNS 记录。有一天，我决定在一个个人区域设置 DNSSEC，以便熟悉概念和流程，结果发现，一旦掌握了一些概念，实现起来并没有那么糟糕。在本文中，我将介绍一些一般概念，在我的下一篇文章中，我将描述在您自己的区域上使用 DNSSEC 的步骤。

如果您不完全理解 DNS 本身是如何工作的，那么理解 DNSSEC 的工作原理可能会很困难。实际上，我可以花一整篇文章来谈论 DNS 的工作原理，但就本文而言，这里是一个典型未缓存 DNS 查询的高级跟踪，该查询解析了我的域名：www.greenfly.org。当您在 Web 浏览器中输入 URL 并按 Enter 键时，在幕后，操作系统会启动一个进程，将该主机名转换为 IP 地址。虽然有些人会在他们的个人计算机上运行 DNS 缓存服务，但在大多数情况下，您依赖于您手动配置或通过 DHCP 配置的外部 DNS 服务器。当您的操作系统需要将主机名转换为 IP 时，它会向 /etc/resolv.conf 中定义的名称服务器发送 DNS 查询（如今，如果此文件由 resolvconf 管理，则真正的名称服务器可能更难追踪）。这启动了所谓的递归查询，因为此远程 DNS 服务器代表您与它需要联系的任何其他 DNS 服务器通信，以将您的主机名解析为 IP。

在解析 www.greenfly.org 的情况下，递归 DNS 服务器首先向 Internet 上的 13 个根 DNS 服务器之一 (192.33.4.12) 发送查询，询问 www.greenfly.org 的 IP。根名称服务器回复说他们不知道该信息，但 .org 的名称服务器可能知道，并且这里是它们的名称和 IP 地址。接下来，递归 DNS 服务器向 .org 名称服务器之一 (199.19.54.1) 发送查询，询问相同的问题。.org 名称服务器回复说它也不知道答案，但 greenfly.org 的名称服务器可能知道，并且这里是它们的名称和 IP 地址。最后，递归 DNS 服务器询问 greenfly.org 名称服务器之一 (75.101.46.232)，并得到答案，即 www.greenfly.org 的 IP 地址是 64.142.56.172。

如果您好奇这对于您拥有的域名是如何工作的，只需使用带有 +trace 选项的 dig 命令即可。以下是 www.greenfly.org 的示例输出

$ dig www.greenfly.org +trace

; <<>> DiG 9.8.1-P1 <<>> www.greenfly.org +trace
;; global options: +cmd
.                    498369  IN   NS    j.root-servers.net.
.                    498369  IN   NS    k.root-servers.net.
.                    498369  IN   NS    e.root-servers.net.
.                    498369  IN   NS    m.root-servers.net.
.                    498369  IN   NS    c.root-servers.net.
.                    498369  IN   NS    d.root-servers.net.
.                    498369  IN   NS    l.root-servers.net.
.                    498369  IN   NS    a.root-servers.net.
.                    498369  IN   NS    h.root-servers.net.
.                    498369  IN   NS    i.root-servers.net.
.                    498369  IN   NS    g.root-servers.net.
.                    498369  IN   NS    b.root-servers.net.
.                    498369  IN   NS    f.root-servers.net.
;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 60 ms

org.                 172800  IN   NS    b2.org.afilias-nst.org.
org.                 172800  IN   NS    b0.org.afilias-nst.org.
org.                 172800  IN   NS    c0.org.afilias-nst.info.
org.                 172800  IN   NS    a0.org.afilias-nst.info.
org.                 172800  IN   NS    d0.org.afilias-nst.org.
org.                 172800  IN   NS    a2.org.afilias-nst.info.
;; Received 436 bytes from 192.33.4.12#53(192.33.4.12) in 129 ms

greenfly.org.        86400   IN   NS    ns2.greenfly.org.
greenfly.org.        86400   IN   NS    ns1.greenfly.org.
;; Received 102 bytes from 199.19.54.1#53(199.19.54.1) in 195 ms

www.greenfly.org.    900     IN   A     64.142.56.172
greenfly.org.        900     IN   NS    ns1.greenfly.org.
greenfly.org.        900     IN   NS    ns2.greenfly.org.
;; Received 118 bytes from 75.101.46.232#53(75.101.46.232) in 2 ms
]]>

虽然这看起来像很多步骤，但在实践中，名称服务器会缓存答案一段时间，这段时间称为 TTL 或生存时间，它被分配给每个记录。这样，DNS 解析器只需查找任何已过期的记录。

DNS 已经存在很长时间了，并且随着时间的推移，它也出现了一些安全问题。DNS 被设计为一种开放、友好的服务。虽然一些管理员可能会将 DNS 记录视为秘密，但一般来说，DNS 记录的目的是被任何请求它的人查找，因此 DNS 记录未加密，并且 DNS 查询通常通过纯文本进行。以下是当今我们面临的一些 DNS 安全问题

• 域名有时看起来很相似 (google.com vs. googIe.com)，攻击者可以利用这一点来诱使您点击看似合法的链接。

• 公司并非总能在所有 TLD (.com vs. .biz vs. .net) 上注册他们的名称，因此攻击者可能会注册 mybank.biz，受害者可能会认为它是合法的。

• 许多 DNS 服务器（称为开放解析器）将为任何请求者执行递归查询。

• 开放解析器通常用于现代 DNS 放大 DDOS 攻击（一种攻击，其中相对较小的 DNS 查询导致数量级更大的响应，由于 DNS 查询通过 UDP 发生，因此可以重定向到与发起请求的主机不同的目标）。通过 DNS 放大攻击，攻击机器只需更少的带宽即可为目标生成大量流量。

• DNS 容易受到 MitM（中间人）攻击，在这种攻击中，DNS 记录可以在返回受害者之前被重写。例如，这允许攻击者更改 DNS 请求中 yourbank.com 的 IP 地址，使其指向攻击者控制的网站。

• DNS 欺骗/缓存中毒攻击（此类攻击已在 2011 年的 Paranoid Penguin 系列专栏中介绍）本质上允许攻击者将伪造的 DNS 记录注入 DNS 解析器的缓存中，以再次将受害者指向攻击者的站点而不是他们打算访问的站点。

在所有这些不同的 DNS 安全问题中，DNSSEC 试图通过为每个 DNS 回复添加签名来解决最后两个问题，即 MitM 攻击和 DNS 缓存中毒，这很像电子邮件中的 PGP 签名。DNSSEC 签名验证您看到的 DNS 结果来自该域的权威 DNS 服务器，并且在传输过程中没有被以任何方式篡改。

如果您对 CA（证书颁发机构）系统或公钥密码术如何与 PGP 签名的电子邮件一起工作有些熟悉，那么理解 DNSSEC 会更容易一些，因为它有一些相似之处。使用 DNSSEC，域创建一组公钥和私钥，用于对其区域中的每个记录集进行签名。然后，域将公钥作为其自身的记录以及签名发布在区域中。通过这些公钥和签名，任何对该域执行 DNS 查询的人都可以使用公钥来验证特定记录的签名。因为只有拥有私钥的人才能对记录进行签名，所以您可以确信结果是由控制该域的人签名的。如果有人在途中篡改了记录，则签名将不再匹配。

就像 PGP 签名的电子邮件一样，将加密签名附加到文档并不是信任该文档的充分理由。毕竟，攻击者可以简单地生成不同的密钥对，更改记录并附加他们的公钥和更新的签名。使用 DNSSEC，您需要一种外部机制来知道您可以信任您获得的公钥确实来自该域。使用 PGP 签名的电子邮件，您可以使用外部机制（例如密钥签名聚会）来验证公钥，并希望如果您收到来自您没有立即获得公钥签名的人的电子邮件，那么您已经信任的某人拥有公钥签名，并且您可以使用该信任链来验证签名。我不知道任何 DNSSEC 密钥签名聚会；相反，信任链的构建方式与 CA 系统类似。

当您访问受 HTTPS 保护的站点时，该站点将向您提供其公钥的副本（此处称为证书），以便您可以与该站点建立安全、加密的通信通道，但同样重要的是，您还可以验证您实际上是在与 mail.google.com 通信，而不是与某些攻击者通信。因为您可能也没有参加 Google 密钥签名聚会，所以您如何信任该证书？事实证明，每个证书都由 Verisign、Thawte 或其他大量 CA 签名。此签名附加到您收到的证书上，并且您的浏览器本身内置了每个 CA 的公钥。浏览器隐式信任这些 CA 证书，因此如果您收到来自已由这些 CA 中的任何一个签名的站点的证书，您将信任它是有效的。顺便说一句，这种信任就是为什么当 CA 被黑客入侵时会成为如此严重的问题。然后，攻击者可以使用来自该 CA 的私钥为其想要冒充的任何站点生成新证书，并且浏览器将自动信任它们。

DNSSEC 签名遵循与 PGP 密钥和 CA 类似的信任链。在这种情况下，根 DNS 服务器充当信任锚点，DNSSEC 解析器隐式信任根 DNS 服务器签名的内容，就像浏览器信任 CA 一样。当 TLD（顶级域）想要实现 DNSSEC 时，它会向根 DNS 服务器提交一个特殊的 DS 记录进行签名。这些 DS 记录包含由私钥生成的子域的签名。根 DNS 服务器托管该 DS 记录并使用其私钥对其进行签名。这样，因为您信任根，所以您可以信任 org 的签名没有被修改；因此，您可以像信任由 CA 签名的证书一样信任它。然后，如果您想为例如 .org 域启用 DNSSEC，您将通过您的注册商提交每个密钥的 DS 记录（如果它支持 DNSSEC）。每个 DS 记录都包含您域名的密钥签名，org 名称服务器随后将对其进行签名和托管。

在此模型中，信任链基本上遵循与我上面概述的递归 DNS 查询相同的顺序。DNSSEC 查询为流程的每个部分添加了额外的验证步骤。例如，对 www.isc.org 的查询从根开始，使用 org 的 DS 记录来验证 com 签名，然后使用 isc.org 的 DS 记录来验证附加到 www.isc.org 的 isc.org 签名。您可以将 +dnssec 选项添加到 dig +trace 以查看完整事务

$ dig +trace +dnssec www.isc.org

; <<>> DiG 9.8.1-P1 <<>> +trace +dnssec www.isc.org
;; global options: +cmd
.                 492727  IN      NS      g.root-servers.net.
.                 492727  IN      NS      m.root-servers.net.
.                 492727  IN      NS      i.root-servers.net.
.                 492727  IN      NS      b.root-servers.net.
.                 492727  IN      NS      f.root-servers.net.
.                 492727  IN      NS      a.root-servers.net.
.                 492727  IN      NS      k.root-servers.net.
.                 492727  IN      NS      h.root-servers.net.
.                 492727  IN      NS      l.root-servers.net.
.                 492727  IN      NS      e.root-servers.net.
.                 492727  IN      NS      c.root-servers.net.
.                 492727  IN      NS      d.root-servers.net.
.                 492727  IN      NS      j.root-servers.net.
.                 518346  IN      RRSIG   NS 8 0 518400 20130517000000
20130509230000 20580 . M8pQTohc9iGqDHWfnACnBGDwPhFs7G/nqqOcZ4OobVxW8l
KIWa1Z3vho56IwomeVgYdj+LNX4Znp1hpb3up9Hif1bCASk+z3pUC4xMt7No179Ied
DsNz5iKfdNLJsMbG2PsKxv/C2fQTC5lRn6QwO4Ml09PAvktQ9F9z7IqS kUs=
;; Received 589 bytes from 127.0.0.1#53(127.0.0.1) in 31 ms

org.              172800  IN      NS      d0.org.afilias-nst.org.
org.              172800  IN      NS      b0.org.afilias-nst.org.
org.              172800  IN      NS      a2.org.afilias-nst.info.
org.              172800  IN      NS      b2.org.afilias-nst.org.
org.              172800  IN      NS      c0.org.afilias-nst.info.
org.              172800  IN      NS      a0.org.afilias-nst.info.
org.              86400   IN      DS      21366 7 1
E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2
org.              86400   IN      DS      21366 7 2
96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA
org.              86400   IN      RRSIG   DS 8 1 86400 20130517000000
20130509230000 20580 . kirNDFgQeTmi0o5mxG4bduPm0y8LNo0YG9NgNgZIbYdz8
gdMK8tvSneJUGtJca5bIJyVGcOKxV3aqg/r5VThvz8its50tiF4l5lt+22n/AGnNRxv
onMl/NA5rt0K2vXtdskMbIRBLVUBoa5MprPDwEzwGg2xRSvJryxQEYcT 80Y=
;; Received 685 bytes from 192.203.230.10#53(192.203.230.10) in 362 ms
isc.org.          86400   IN      NS      ns.isc.afilias-nst.info.
isc.org.          86400   IN      NS      ams.sns-pb.isc.org.
isc.org.          86400   IN      NS      sfba.sns-pb.isc.org.
isc.org.          86400   IN      NS      ord.sns-pb.isc.org.
isc.org.          86400   IN      DS      12892 5 2
F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
isc.org.          86400   IN      DS      12892 5 1
982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
isc.org.          86400   IN      RRSIG   DS 7 2 86400 20130530155458
20130509145458 42353 org.
Qp7TVCt8qH74RyddE21a+OIBUhd6zyzAgSB1Qykl2NSkkebtJ1QeE5C5
R8eblh8XvmQXjqN7zwcj7sDaaHXBFXGZ2EeVT5nwJ1Iu4EGH2WK3L7To
BDjR+8wNofZqbd7kX/LOSvNu9jdikb4Brw9/qjkLk1XaOPgl/23WkIfp zn8=
;; Received 518 bytes from 199.19.56.1#53(199.19.56.1) in 400 ms

www.isc.org.      600     IN      A       149.20.64.42
www.isc.org.      600     IN      RRSIG   A 5 3 600 20130609211557
20130510211557 50012 isc.org.
tNE0KPAh/PUDWYumJ353BV6KmHl1nDdTEEDS7KuW8MVVMxJ6ZB+UTnUn
bzWC+kNZ/IbhYSD1mDhPeWvy5OGC5TNGpiaaKZ0/+OhFCSABmA3+Od3S
fTLSGt3p7HpdUZaC9qlwkTlKckDZ7OQPw5s0G7nFInfT0S+nKFUkZyuB OYA=
isc.org.          7200    IN      NS      ord.sns-pb.isc.org.
isc.org.          7200    IN      NS      sfba.sns-pb.isc.org.
isc.org.          7200    IN      NS      ns.isc.afilias-nst.info.
isc.org.          7200    IN      NS      ams.sns-pb.isc.org.
isc.org.          7200    IN      RRSIG   NS 5 2 7200 20130609211557
20130510211557 50012 isc.org.
SdMCLPfLXiyl8zrfbFpFDz22OiYQSPNXK18gsGRzTT2JgZkLZYZW9gyB
vPTzm8L+aunkMDInQwFmRPqvHcbO+5yS98IlW6FbQXZF0/D3Y9J2i0Hp
ylHzm306QNtquxM9vop1GOWvgLcc239Y2G5SaH6ojvx5ajKmr7QYHLrA 8l8=
;; Received 1623 bytes from 199.6.0.30#53(199.6.0.30) in 60 ms
]]>

您将在此响应中看到许多新的记录类型，但请不要担心，接下来我将介绍所有新的 DNSSEC 记录类型。

当您阅读 DNSSEC 文档时，会出现许多不同的首字母缩写词和新术语，因此这里有一些您在使用 DNSSEC 时需要熟悉的常用术语

• RR（资源记录）：这是区域中最小的数据单元，例如单个 A 记录、NS 记录或 MX 记录。

• RRSET：一组完整的资源记录。例如，RRSET 可能是特定名称的所有 NS 记录或 A 记录。

• KSK（密钥签名密钥）：对区域中的 DNSKEY 记录进行签名。

• ZSK（区域签名密钥）：对区域中的所有其他记录进行签名。

• SEP（安全入口点）：在密钥中设置的标志，表示它是一个 KSK。

虽然最佳实践建议使用单独的 KSK 和 ZSK，但这并不是实际要求。在我下一篇关于 DNSSEC 实现的文章中，我将讨论两种密钥类型之间的主要区别以及为什么单独的密钥被认为是最佳实践。

DNSSEC 还向组合中引入了许多新的 DNS 记录类型。这些记录与区域一起以及您的其余 DNS 记录一起发布，并由任何启用 DNSSEC 的查询根据需要拉取

• DNSKEY：这是区域的公钥，可以是 KSK 或 ZSK。

• RRSIG（资源记录签名）：此记录包含使用特定 ZSK 创建的 RRSET 的签名。

• NSEC（下一个安全记录）：这些记录用于“否定答案”以证明名称是否存在。

• NSEC3（下一个安全版本 3）：这些记录类似于 NSEC，但可以防止“区域漫步”，即外部用户可以使用 NSEC 记录来漫步区域并发现区域中的所有记录（很像能够执行区域传输）。

• DS（委托签名者）：此记录包含 KSK 签名，并提交给区域的父级，在父级中对其进行签名并用作信任链的一部分。

• DLV（DNSSEC 后备验证）：很像 DS 记录，但当区域不支持 DS 记录时使用，或者在您的注册商不支持 DNSSEC 时用作备用信任锚点。

DNSSEC 有点像先有鸡还是先有蛋的问题。如果您的 TLD 不支持 DNSSEC，则任何外部解析器都不会拥有从根到 TLD 再到您的区域的完整信任链。也可能存在这样一种情况，即您的 TLD 支持 DNSSEC，但您的注册商不提供将 DS 记录上传到 TLD 的机制（可悲的是，大多数注册商都不提供）。在任何一种情况下，都创建了 DNSSEC 后备验证 (DLV) 以提供备用信任锚点。

您可以在 http://dlv.isc.org（主要的 DLV 提供商之一）找到有关 DLV 的更多详细信息，但基本上，您不是生成要提交给 TLD 的 DS 记录，而是生成特殊的 DLV 记录并将其提交给 DLV 服务器。只要 DNS 解析器配置为信任例如 dlv.isc.org，它就可以使用它来锚定信任链，然后信任您的签名记录。

事实证明，DNSSEC 在您开始实施之前有很多新概念需要理解；但是，一旦您看到列出的步骤，实现起来并没有那么糟糕，因此请务必关注我下个月的文章，届时我将讨论如何使用 BIND 为区域实施 DNSSEC。我甚至会介绍如何为区域设置 DLV。

DNSSEC 信息链接集合：http://dnssec.net

ISC 的 DLV 文档：https://dlv.isc.org

DNSSEC 信任链可视化工具：http://dnsviz.net