计算安全基础设施的一个巨大问题是真实信息的分发。证书颁发机构的目的是评估身份。OpenPGP依赖于信任网络，个人可以在其中验证其他个人。Secure Shell（SSH）等协议要求用户手动验证每个服务器的公钥。部署VPN的组织必须安全地向用户分发配置和相互身份验证详细信息。DNSSEC为这类问题提供了一种解决方案。使用DNSSEC的组织对非机密信息（包括公钥）有一种经过加密验证的分发方法。
一些供应商已经将DNS用于他们的应用程序和设备。多个VPN客户端会查找VPN集中器的IPSECKEY记录，没有它就无法连接。没有DNSSEC，不良行为者可以更改该记录并以任何方式重定向客户端。此类设备的供应商为其产品提供了特定的信息，因此我将介绍两个更通用的、基于标准的基于DNSSEC的数据分发案例：分发SSH主机密钥和验证自签名X.509证书。
SSH协议使用公钥加密来验证您连接的服务器是否真的是您认为的服务器，并隐藏客户端和服务器之间交换的数据。不幸的是，正确使用SSH要求用户第一次登录SSH服务器时，必须检查提供的公钥，并将其与服务器公钥的带外副本进行比较。即使是那些进行此类检查的人，也往往敷衍了事，而不是一丝不苟。更糟糕的是，大多数SSH用户学会了忽略有关公钥问题的警告。我见过许多新系统管理员对未知密钥的消息变得如此麻木，以至于他们忽略了关于不匹配密钥的警告。教用户忽略安全问题是不好的。
您可以使用RFC 4255中定义的SSH指纹（SSH Fingerprint —— SSHFP）记录通过DNS分发SSH主机密钥。由于主机密钥对于识别服务器至关重要，SSHFP记录必须不受篡改。在您拥有功能齐全的DNSSEC之前，不要部署SSHFP记录。
使用SSHFP记录需要创建记录，将记录插入您的区域，并配置客户端以使用它们。
ssh-keygen(8) 程序有一个标志，用于读取现有的SSH公钥文件并创建格式化的SSHFP记录。当您使用 -r 标志并指定主机名时，它会扫描 /etc/ssh 以查找公钥文件并输出记录。
$ ssh-keygen -r mailmail IN SSHFP 1 1 357ea20d767893fc050b599984bbb8d29bf5090bmail IN SSHFP 1 2 da611f28ed4b9a443d88096541bccb86cd1dc6…mail IN SSHFP 3 1 a2525ff9a485be1c00d4258346a23c781ce0abd0mail IN SSHFP 3 2 7d7f6ec211a216dadb6f3bb88f66149eb696…mail IN SSHFP 4 1 13ede0ad31203f03fa2e9ef02b2924f3f997e4ddmail IN SSHFP 4 2 d938ece8beb04be200ce9171d7935669cf8ddbfec8…此命令显示本地计算机上所有主机密钥的SSHFP记录，并格式化名为 mail 的主机的记录。此记录将特定于特定区域和此特定主机名。如果您或您的用户使用几个名称之一通过SSH连接到此主机，也就是说，如果邮件也用作 www ，则每个变体名称都需要SSHFP。
将SSHFP记录插入区域，与任何其他资源记录完全相同。
最受欢迎的两个SSH客户端是PuTTY和OpenSSH。PuTTY不支持SSHFP记录。OpenSSH支持，并且包含在大多数Unix、Mac OS甚至Windows中。OpenSSH使用 VerifyHostKeyDNS 选项告诉 ssh(1) 检查主机上的SSHFP记录。默认情况下，它设置为 yes ，但一些供应商在捆绑OpenSSH时将其关闭。
当我第一次SSH到这个主机时，
$ ssh -p 822 mailLast login: Mon Oct 4 13:45:17 2021 from headdesk.mwl.ioFreeBSD 12.2-RELEASE-p7 GENERIC没有提示我比较主机密钥。如果我在连接时添加了 -v 选项，我会看到ssh在DNSSEC中找到主机密钥，执行比较，并接受主机的公钥。当OpenSSH找到SSHFP记录时，它不会更新 known_hosts 。这消除了众所周知的使用过时密钥来欺骗服务器的问题。
搜索顺序至关重要。 mail.mwl.io 和 mail.mwlucas.org 的条目指向同一台机器。假设我的客户端首先搜索 mwlucas.org ，但我将SSHFP记录放在 mwl.io 中。我的客户端将首先找到 mail.mwlucas.org 的条目，因此它不会看到SSHFP记录。系统将提示您接受主机密钥。您可以通过使用OpenSSH的 CanonicalDomains 指令或 ssh_config 别名条目仔细管理域搜索顺序来避免这种情况。
通过DNSSEC保护的DNS分发SSHFP记录可以消除像你我这样的弱用户对主机的身份验证。如果可以的话，实施它。如果你想了解更多关于SSH的知识，请允许我推荐我的书《SSH Mastery》（倾斜风车出版社，2018）。
传输层安全性（Transport Layer Security —— TLS），以前称为安全套接字层（ Secure Sockets Layer —— SSL），是识别互联网上实体并加密它们交换的数据的行业标准方法。TLS使用X.509证书来证明服务器和用户的身份，允许实体安全通信，而无需进行任何类似SSH的密钥验证。
X.509证书由证书颁发机构（Certificate Authorities —— CAs）颁发。浏览器和邮件服务器等应用程序使用有效CA列表，并自动识别由它们颁发的证书。虽然ACME支持的免费CA消除了常规证书的费用，但证书颁发机构仍然容易受到欺诈和欺骗。
通过使用基于DNS的命名实体身份验证（DNS-Based Authentication of Named Entities —— DANE），您的组织可以在TLSA记录中提供与TCP/IP端口关联的有效X.509证书的独立声明。TLSA不是首字母缩略词，它是DNS记录的类型。当支持DANE的客户端应用程序连接到受TLS保护的端口时，它会检查该主机和端口的DNSSEC安全TLSA记录。客户端将TLSA记录与证书进行比较。如果所有内容都匹配，则客户端接受证书。RFC 6698记录了DANE和TLSA。
应用程序甚至接受由TLSA认证的自签名证书。这与传统X.509预期的信任模型略有不同。DANE假设控制站点DNS的组织也控制服务器。CA模型假设CA在验证证书请求方面做得很可靠。两者都有弱点。DANE可以应用于CA颁发的证书，并可用于要求证书由特定的受信任CA签名，因此您可以将这两种模型结合起来，以实现两者的最佳和最差。（哪个最好，哪个最差，取决于你。）
虽然TLSA最初被视为绕过证书颁发机构并验证自签名X.509证书的一种方式，但Let's Encrypt的免费CA证书有效地满足了这一需求。如果你研究DANE，你会看到对检查TLSA记录的浏览器插件的引用，但这些插件是未维护和过时的。当今最常见的TLSA记录消费者是SMTP服务器，传统上接受自签名证书。
DANE的密钥是TLSA记录，它提供证书公钥的哈希值或实际公钥。TLSA记录看起来像这样：
_port._protocol.hostname TLSA (usage selector match key)
SubjectPublicKeyInfo 字段。usage 字段允许您定义此TLSA记录如何与证书颁发机构交互。
我建议使用NLnet实验室的 ldns-dane(1) 来创建和验证TLSA记录。这是他们ldns工具包的一部分。不过，如果你想冒险使用异国情调的OpenSSL命令，欢迎你参加这次冒险。
首先，决定要在记录中设置哪个CA使用策略、选择器和匹配。我建议大多数站点的CA使用策略为3，声明记录包含特定证书的公钥。每当更新证书时，您都必须更新TLSA记录，但对于ldns dane来说，这并不繁重。最常见的选择器是0，告诉客户端分析整个证书。最后，匹配声明了您提供的哈希类型。1就足够了。您将把这些TLSA字段设置为3 0 1。
ldns-dane程序可以使用 create 选项创建新的TLSA记录。您提供TLS服务所在的主机和端口，然后提供所选的策略、选择器和匹配。
$ ldns-dane create host port 3 1 0
我想为我的主机 mwl.io 创建一个TLSA记录。我在端口443上有一个web服务器。
$ ldns-dane create mwl.io 443 3 1 0_443._tcp.mwl.io. 3600 IN TLSA 3 0 1 fe3eb7ae334921291da3d969e1e0531ac6fab2344be48aafdf5411443faf880e这是我的TLSA记录。我把它复制到我的区域，它就准备好了。我还需要为 www.mwl.io 添加记录，即使它是同一个主机。邮件交换器是另一台主机，因此 mail.mwl.io 的SMTP需要不同的记录。
如果您使用ACME维护X.509证书，则可以将ldns-dane调用添加到续订过程中，并自动化TLSA记录维护。
在您的区域上运行dig会显示记录存在，但您如何仔细检查客户端是否可以使用此字符串来验证您的X.509证书？
ldns-dane程序可以使用（等它）verify 选项验证现有记录。提供主机名和端口。
$ ldns-dane verify mwl.io 44345.63.79.193 dane-validated successfully2001:19f0:5c01:fcf:5400:1ff:fe4b:e2df dane-validated successfully对要验证的每个主机名和端口运行此命令。
如果你想进行离线确认，有几个人提供了公共TLSA验证器。如果您使用TLSA进行HTTPS，则验证器位于 https://check.sidnlabs.nl/dane/ 快速方便。验证器位于 https://www.huque.com/bin/danecheck 更灵活。让网站消失的最好方法是我在书中提到它，但你找到其他验证器不会有任何困难。
您获得了一个新证书，但其他人的名称服务器缓存了旧证书的TLSA记录。如何正确滚动TLSA记录以支持新证书？
一旦你有了新证书，不要立即部署它。创建新的TLSA记录并将其添加到区域中，这样你就有了两个TLSA记录。等待新的TLSA记录变得无处不在。一旦发生这种情况，部署新证书并从区域中删除旧记录。
通过这些示例，您的DNS可以提供任何信息，并保证DNSSEC的完整性。
经过一生的滥用，DNS终于有了完整性验证基础设施。几十年来，人们一直在测试和磨练DNSSEC，现在它相当简单。虽然DNSSEC可能看起来很复杂，但当您第一次遇到DNS时，它可能会让您感到困惑。部署DNSSEC将增强您对自己网络资源的信任，即使它提高了您对其他人DNS的信任。你的用户可以放心，他们正在观看的愚蠢视频就是他们妈妈发送的愚蠢视频。
如果您有兴趣了解有关DNSSEC的更多信息，请查看《安全域名系统（DNS）部署指南》等资源以及https://www.dnssec.net.
我已经记不清有多少人告诉我，这本书的第一版不仅帮助他们部署了DNSSEC，而且帮助他们理解了DNSSEC。听到这个消息我很高兴。如果这本书对你有帮助，请告诉你的同行，并在你最喜欢的网上书店留下评论。