域名系统（Domain Name System —— DNS）是世界上最成功的分布式数据库，同时对互联网的成功和许多失败负责。DNS将像 mwl.io 这样的主机名映射到IP地址，这样我们就可以使用互联网，而不必记住 192.0.2.87 或 2001:db8:：bad:c0de:cafe 等数字。它还告诉设备在哪里可以找到它们的配置、证书颁发机构是否可以为域颁发X.509证书、SSH客户端服务器主机密钥等等。DNS自1983年以来一直在使用，虽然它已经发展和扩展，但其核心设计保持不变。只有一个小问题。
DNS容易上当受骗。（DNS is gullible.）
这不是它的错。想想1983年的互联网。事实上，互联网的运作是一个技术奇迹。没有人试图破坏网络。即使是那些戳到尘土飞扬的角落并“入侵”系统的年轻学生，也更感兴趣的是学习这项技术并展示他们的智慧，而不是造成任何损害。DNS比之前的集中管理主机文件有了巨大的改进。
但后来互联网成为主流、国际化和廉价的。计算机业余爱好者(hobbyists)和热心爱好者(enthusiasts)加入了进来，然后是他们的家人，然后是每个上班族、孩子、银行、发电厂和医院。我们连接了ICU呼吸机和单个灯泡。现在每个人都在互联网上进行银行业务，犯罪分子在破坏互联网方面有很大的经济利益。DNS是攻击载体（vector）。在网络中植入无效的DNS信息并不像以前那么容易，但当入侵者将其拔出（pulls it off）时，它会非常有效。
一个组织能防范这些攻击吗？当然。但很少有组织有专门的DNS管理员。DNS管理通常被整合到另一个团队中，如网络管理或服务器管理。你们有交换机要安装。桌面图像。目录已激活。你认为是“你真正的工作”的任务，其中DNS管理是一个无关紧要的小部分。
尽管如此，DNS故障的影响不成比例。一个名称服务器守护进程可以在仅仅兆字节的内存中运行，但如果它死了，网络上的所有东西都会失去理智。人们只关心DNS坏了的时候，他们用二进制术语来看待它。它有效吗？在有人被咬之前，损坏的DNS不会受到任何关注。
损坏的DNS对任何组织都是一个严重的威胁。如果攻击者可以让世界认为你的组织的网站在他运行的服务器上，他就可以拦截传入的流量。打算访问您网站的用户将转而访问入侵者的网站。攻击者的网站甚至可能看起来比你自己的网站更合法；拥有站点的X.509证书仅意味着请求证书的人控制着站点的DNS。精明的入侵者会默默地记录用户的数据，并将交易转发到您的服务器。只有当你的客户告诉你，他们购买你的小部件的那天，有人偷了他们的信用卡，你才会意识到发生了什么。
在这种情况下，你也不想成为客户。如果关键供应商、银行或主要互联网网站遭受DNS损坏，您可能会因信用卡号码丢失或装配线关闭而遭受损失。即使是盗窃网站身份验证凭据也会造成数小时或数月的悲痛。
但是网站上的X.509证书呢？证书验证网站的标识，但只有当流量到达正确的服务器时，它才能工作。要访问该站点，客户端必须具有正确的DNS信息。商业认证机构一再向与组织完全无关的人颁发大型组织的证书。颁发免费证书的非商业证书颁发机构使用DNS来验证对服务器的控制。可以将无效信息传入DNS的入侵者可以为您的网站获取TLS证书。
这些都会毁了你的一天。你肯定不想参加会计师问为什么拍卖网站使用他的公司信用卡从Space:1999购买斯科蒂TARDIS的原始套装的会议。在会议上，公司总裁也不想知道该公司革命性的低润滑油传动轴的计划是如何落入一个肆无忌惮的竞争对手手中的，而不是街上常见的原型打印机。
保护DNS的理由归结为：你没有时间听这些废话。
域名系统安全扩展（Domain Name System Security Extensions —— DNSSEC）确保DNS数据的真实性和完整性。
DNS当前映射名称和地址的方式有什么问题？是的，DNS服务器的安全历史参差不齐，但在互联网历史的大部分时间里，对于许多协议和实现来说，这是正常的。DNS协议本身容易被滥用。许多聪明人都非常努力地保护DNS，并且做得很好，但成功的协议安全从来不是事后的想法（successful protocol security is never an afterthought）。DNS的分布式特性加剧了这一问题。入侵者在权威服务器、递归服务器和客户端攻击DNS。要了解风险，请考虑DNS数据集。
DNS组织的基本单位是 zone (区域)。区域是共享相同后缀的记录的集合。许多人认为一个区域是一个域，就像 mwl.io 一样。是的，域就是一个区域。.com 和 .pizza 等父域名也是区域。反向(reverse)DNS区域也是如此，如 2.0.192.in-addr.arpa 。区域包含有关主机、子区域和区域主要特征的记录。.com 的区域包含 .com 下所有区域的委派名称服务器（nameserver —— NS）记录，包括 michaelwlucas.com 。根区域包含其子区域的委派，如 .com 和所有其他顶级区域。这本书经常使用更熟悉的术语 domains (域)，但你应该知道我们谈论的是所有区域。
如果入侵者可以入侵某个区域的权威服务器，她可以将任何她喜欢的数据输入该区域。每个人都会认为这些信息是有效的——毕竟，它来自权威服务器。这是危害DNS的最彻底的方法，但也是最难对具有安全意识的目标执行的方法之一。某些DNSSEC配置可以防止此类攻击。
递归(recursive)服务器，如组织面向客户端的名称服务器，通过查询权威服务器来获取信息。入侵者可能会破坏这些查询，在原本有效的查询中添加额外信息，或完全改变响应。入侵者有很多方法可以污染递归服务器的数据，人们不断发现更多。DNSSEC解决了这类常见的攻击。
最后，入侵者可以介入客户端与其递归名称服务器之间。验证DNSSEC的客户端不会受到此类攻击。不验证DNSSEC的客户端必须使用另一种机制，如HTTPS上的DNS（DNS over HTTPS —— DoH）或TLS上的DNS(DNS over TLS —— DoT)，以确保其与递归名称服务器之间的连接安全。
安全性(security)通常被认为是机密性(confidentiality)、完整性(integrity)和可用性(availability)的结合。DNS数据不仅是绝对公开的，公共数据必须保持公开才能工作。DNS可用性依赖于位于不同网络上的辅助服务器等技术。完整性是DNS安全的大问题，这就是DNSSEC发挥作用的地方。
DNSSEC为DNS数据添加数字签名。客户端可以验证它收到的受DNSSEC保护的数据是由权威服务器发送的数据，并拒绝不正确的数据。DNSSEC数字签名与TLS和OpenPGP等其他安全协议中的数字签名有很多共同之处。如果您熟悉加密哈希和数字签名，DNSSEC背后的原理不会让您感到惊讶。
入侵者仍然可以攻击终端客户端——毕竟，任何控制桌面的人都可以控制用户体验——但DNSSEC消除了一条广泛的攻击途径。
DNSSEC不会使您免于DNS配置错误。它不会阻止你的软件崩溃。它不会取代数据包过滤器、代理、防病毒、反恶意软件、常规服务器或个人卫生或计划。DNSSEC无法保护您免受网络中断或配置错误的影响，例如将所有权威服务器放在同一网段上。如果您不安装常规升级和安全补丁，DNSSEC可能会给您一种虚假的安全感。如果你从这本书的第一版开始就没有升级过你的密钥，那你就有麻烦了。
DNSSEC有两个组件。第一种是 signing (签名)，或将DNSSEC添加到您自己的区域。另一种是 validation (验证)，即在您不控制的区域上验证DNSSEC。请注意，“防止入侵者进入我的域名服务器”并未出现在此列表中。
本书面向希望将DNSSEC纳入其系统的域名管理员，以及希望通过DNS可靠分发信息的系统管理员和协议开发人员。我会抛出诸如“区域”和“反向DNS”之类的词，希望你能理解。我不会解释A、PTR、NS、MX和SOA记录等基础知识，也不会解释缓存和权威名称服务器之间的区别。我将详细介绍DNSSEC特定记录。
虽然本文中的DNSSEC理论、最佳实践和诊断指南适用于所有DNS服务器软件，但我的参考平台是互联网系统联盟（Internet Systems Consortium —— ISC）的BIND 9。BIND是公共互联网上最受欢迎的权威DNS服务器，由许多根域名服务器和顶级域名运行。然而，我已经将理论与实现分开了。使用当前BIND管理DNSSEC的最简单方法需要 rndc(8) ，因此请先配置它。必要时，我的示例使用BIND 9.16.22或BIND 9.17.18。许多Linux发行版，特别是其长期支持版本，都附带了旧的BIND版本，因此术语和功能可能会有所不同。
示例包括IPv4和IPv6。
传统DNS相当宽容。很少有实现严格遵守标准。这使得DNS的启动和工作变得容易。我见过有15年历史的名称服务器的网站，在这些网站上，根区域提示文件自服务器安装以来就没有更新过，DNS仍然可以工作。我见过带有各种奇怪快捷方式和滥用的区域文件，但它们经过解析、加载并正常工作。人们随机创建了公共领域的子区域，并发挥了作用。许多不良行为之所以被制度化，是因为它们一直在发挥作用。
这种灵活性让人们可以将各种东西塞进DNS。DNS可以是您公司的电话簿。您可以通过DNS从公司窃取数据。您可以通过DNS隧道传输交互式SSH。
DNSSEC不会宽容。如果数据不符合标准，就无法验证。如果您不确定自己的数据或DNS技能，请先在测试域上部署。不要让DNSSEC吓跑你，但一定要尊重它。把这看作是提高你DNS技能的机会。
我强烈建议您在首次部署DNSSEC时使用测试域。
在添加DNSSEC之前，请正确配置DNS服务器。首先安装推荐的名称服务器软件和所有安全补丁。如果可能的话，完全修补操作系统并配置主机以自动部署更新和修补程序。在超过四分之一个世纪的系统管理中，我很少有操作系统更新导致名称服务器拒绝运行。虽然更新可能会破坏名称服务器，但更新失败更有可能导致安全漏洞。
DNSSEC验证的递归名称服务器会进行与非验证服务器相同的查询，但会添加额外的查询来收集验证信息。这些名称服务器使用额外的内存和处理器时间来验证签名。如果没有DNSSEC，您可以在20年前的硬件上为数千个客户端提供服务。使用DNSSEC，这数千个客户端需要10年陈(10-year-old)的硬件。
DNSSEC会增加区域文件的大小。与现代磁盘和网络相比，即使是签名的区域文件也微不足道。如果您的名称服务器的区域文件已经使用了大量的磁盘空间，您将需要更多。
与任何公共服务器一样，禁用计算机上所有不必要的服务。使用 netstat(1) 、sockstat(1) 或 lsof(1) 查看哪些程序正在监听网络。禁用任何非严格必要的程序。将命令行访问限制为管理IP地址的简短列表，并要求SSH进行公钥身份验证。如果你不知道如何做到这一点，请允许我推荐我的书《SSH Mastery》（倾斜风车出版社，2018）。
服务器或解析器上的错误时间会破坏DNSSEC。让主机通过NTP从网络中维护其时间，或投资GPS时钟。我强烈建议您监控系统时钟，特别是在容易出现时间偏差的虚拟机上。注意使时间依赖于DNS，或DNS依赖于时间。
名称服务器应作为专用的无特权用户（而不是 nobody 或 root ！）在chroot中运行。默认情况下，大多数操作系统都以这种方式打包名称服务器，但请仔细检查您的。
不同的Unix品种将BIND配置文件放在不同的目录中。我会参考 /etc/namedb 目录，但你的Unix可能会把它放在任何地方。不需要将BIND目录移动到 /etc/namedb 。
验证重新启动后所有更改是否保持不变。是的，这一切都很乏味和烦人。然而，DNS故障令人兴奋。我喜欢无聊，并向IT行业的每个人推荐。
您经常会听到传统DNS使用UDP端口53，因为查询和响应可以容纳在单个UDP数据包中。TCP于三分之一个世纪多以前的1987年被添加到DNS中，RFC 7766记录了当前的标准。在20世纪90年代末，扩展DNS（EDNS）允许DNS查询使用大型UDP数据包，这些数据包可能会被碎片化和重新组装。客户端和服务器应该能够使用适用于其环境的任何协议。DNS查询和响应的设计几乎可以在任何网络中移动。
除了。
一些防火墙管理员认为DNS只使用UDP并阻止TCP端口53。更糟糕的是，一些防火墙产品具有过滤器，旨在防止在端口53上构建隧道，检查DNS流量以确保它确实是DNS。其中一些产品假设所有合法的DNS查询都是512字节或更小，并丢弃任何更大的查询。其他人则丢弃所有IP片段，而不是重新组装它们。有线电视和DSL调制解调器因这种愚蠢而臭名昭著。默认情况下，一些基于主机的防火墙会丢弃IP片段，但您可以更改此行为。如果您的数据包过滤器有任何类型的幼稚DNS过滤器，您的DNSSEC感知解析器将给出不稳定的答案。
你如何测试你的环境，看看你是否有这些限制之一？没有一种方法可以检测到所有可能的网络缺陷，但如果你的DNS服务器可以在大区域上执行查询，你应该没问题。最简单的测试是OARC回复大小测试仪(https://www.dns-oarc.net/oarc/services/replysizetest). 查询他们的回复大小测试仪将显示服务器可以接收到的最大响应。
$ dig +short rs.dns-oarc.net TXTrst.x4050.rs.dns-oarc.net.rst.x4058.x4050.rs.dns-oarc.net.rst.x4064.x4058.x4050.rs.dns-oarc.net."107.191.49.237 DNS reply size limit is at least 4064""107.191.49.237 sent EDNS buffer size 4096"截至2020年，1232字节的回复大小是足够的。此主机可以接收全尺寸响应。发送相同查询的其他主机可能显示较小的限制。这是来自另一个主机的请求。
xxxxxxxxxx$ dig +short rs.dns-oarc.net TXTrst.x1384.rs.dns-oarc.net.rst.x1347.x1384.rs.dns-oarc.net.rst.x1353.x1347.x1384.rs.dns-oarc.net."2607:f8b0:4001:c17::117 DNS reply size limit is at least 1384""2607:f8b0:4001:c17::117 sent EDNS buffer size 1400"我们这些自二十世纪以来一直在运行DNS的人可能会对此感到担忧，但1400比1232多。这已经足够好了。
Reply Size Tester页面记录了其他不太常见的回复。
如果OARC不再如此慷慨，不再提供此服务，您将需要查询一个大区域，看看会发生什么。运行 dig paypal.com any +notcp 这样的命令应该会喷出多个屏幕的信息。（任何查询默认使用TCP，因此您必须显式禁用它。）如果您可以通过UDP和TCP获得相同的答案，并且可以成功查询多个返回大答案的域，那么您可能没问题。
如果测试显示您的域名服务器存在数据包过滤不当的问题，请立即停止测试DNSSEC。在您解决网络问题之前，DNSSEC将无法工作。逐步调查您的网络，直到发现问题。您可能会发现ISC的文档“使用dig测试EDNS兼容性”很有用。
有关网络问题和DNSSEC的更多信息，请访问DNS标志日网站(https://dnsflagday.net)以及“DNS碎片避免”互联网草案。
在区域上部署DNSSEC需要父区域和您与该区域的接口的支持。
你的父区域可能是 .com 或 .org 之类的。这些区域中的大多数（但不是全部）都支持DNSSEC。它可能是一个反向DNS区域，如 198.in-addr.arpa 。它也可能是一个企业母区。如果您想在本地办公室的 detroit.myhugecompany.com 上部署DNSSEC，则 zone myhugecompany.com 必须具有DNSSEC。
您与父区域的接口也必须支持DNSSEC。您的公共IP地址通过路由信息注册表（Routing Information Registry —— RIR）进行管理。如果您有/24或更大的IPv4地址块并控制反向DNS，则可以在反向DNS上部署DNSSEC。如果你在一个私人组织网络上，请与管理全球网络的人交谈。棘手的部分来自域名注册商。尽管DNSSEC作为标准已有十多年的历史，但一些注册商并没有费心支持它。如果您的注册商不支持DNSSEC，那么在您的域由该注册商提供服务时，您将无法部署DNSSEC。找另一个注册商，并告知老注册商你离开的原因。
与其反复纠结于公司办公室、RIR和域名注册商，我将使用 registrar (注册商)一词来表示“您与父母域名的接口”。
除了域名注册商，域名还有一个 registry (注册中心)。注册中心是管理该区域的实体。你的注册商允许你注册一个 .com 域名。注册商将请求交给管理该区域记录的 .com 注册中心。
许多历史DNS攻击依赖于执行权威(authoritative)和递归(recursive)服务的名称服务器。递归服务器的目的是接受 来自 公共互联网的数据，而权威服务器的目的则是向公共互联网 提供 数据。想要向名称服务器提供有害数据的入侵者需要名称服务器接受数据。拒绝接受公众任何数据的权威服务器消除了这类攻击。
配置一组名称服务器为您的客户端提供服务。这些名称服务器不应该对任何公共区域具有权威性。（递归名称服务器应该对私有地址空间和其他垃圾域 —— 如 .local 、.belkin 、.home 、.invalid 、.localdomain 和 .domain —— 具有权威性，以避免用无用的查询淹没根服务器。）将第二组名称服务器配置为权威服务器，并完全禁用它们上的递归。
如果您对快速解析不可解析的域感兴趣，请查看AS112项目(https://www.as112.net).
这本书不是一本全面的DNSSEC手册。我介绍了保护正向和反向区域中信息的常见情况，以及在拥有DNSSEC后如何利用DNS的几个示例。我根据各种互联网标准和文件，如NIST的《Secure Domain Name System (DNS) Deployment Guide》(安全域名系统（DNS）部署指南)（NIST特别出版物800-81-2），推荐最佳实践。如果你想在DNSSEC之外通过DNS走私SSH，或者你想研究DNSSEC的详细信息，这本书不适合你。然而，本书将帮助您升级到基本的DNSSEC能力，并为您指明了解更多信息的方向。
dig 来识别和检查DNSSEC数据，并调查DNSSEC问题。说够了。让我们看看DNSSEC是如何改变DNS的。