DNSSEC 简介

DNS是Internet上权威的支柱之一。DNS用于将域名（例如www.gingerdoc.com）转换为数字Internet地址（例如198.41.214.163），它通常被称为“ Internet电话簿”。

DNSSEC是DNS的一组安全扩展，它提供了用于验证DNS记录的方法。

介绍

域名系统（DNS）是现代Internet上最古老，最基础的组件之一。作为一种将域名映射到Internet协议（IP）地址的机制，它提供了易于阅读的层来浏览Internet上数百万台机器和设备。在1980年代初期，当设计DNS时，协议中没有考虑强大的安全机制。与当时的计算机相比，当时的计算机功能不足，公钥密码术是一个相对较新的概念，并且受到严格监管，并且网络规模较小，相对知名和信任的参与者较少。随着网络的发展和发展，DNS作为一种不安全且未经身份验证的协议保持不变。

在1993年，IETF开始了关于如何使DNS更值得信赖的公开讨论。最终，一组DNS扩展被称为“域名系统安全扩展（DNSSEC）”，并于2005年正式发布。这些扩展取代了先前的提议，作为确保DNS安全的最终方法。尽管距本刊物出版已有十多年了，但DNSSEC仍距离主流采用还很遥远。

有多种推动DNSSEC采用的催化剂，其中之一是Dan Kaminsky 自2008年以来的缓存中毒攻击。此次攻击突显了传统DNS中的重大信任问题，以及DNSSEC如何很好地解决了这些问题。但是，即使工作量很大，采用率仍会滞后-有几个因素会阻碍DNSSEC的采用。其中有网络运营商（出于充分的理由）更喜欢稳定性而不是复杂性。采用DNSSEC的另一个困难是，关于DNSSEC是否是保护DNS的正确工具尚无共识。

在本文中，我们将探讨DNS固有的不安全性，以及如何使用DNSSEC来提高对Internet基本部分的信任。

DNS：凉爽之前的分布式键值存储

DNS的概念很简单：它是一个有关域名信息的全球数据库。这是互联网的电话簿。

如果客户端要连接到诸如“ www.example.com”的地址，并且需要知道该地址对应的IP地址，则可以询问DNS。通常，所有DNS消息都是通过UDP发送的。

DNS可以回答几种类型的资源记录（RR）。最重要的RR之一称为“ A记录”，它存储与域关联的IPv4地址。要找出给定域的任何记录的值，您可以询问DNS解析器。例如，如果您想要www.example.com的IP地址，您可能会问的问题是：

“域名www.example.com的A记录是什么？”

原始DNS请求是一个UDP数据包，如清单1所示。该请求包含一个ID（0x27e1），一些标志（表明该请求是一个请求）以及问题本身。

清单2显示了原始DNS请求的响应。此响应带有匹配的ID（0x27e1），回显的原始请求的副本，一些标志（1/0/0）和问题的答案： 93.184.216.119。它还包含一个有效期，称为生存时间（TTL），以指示记录有效的时间。

原始DNS请求：

 0x0000: 5ad4 0100 0001 0000 0000 0000 0765 7861 ‘............exa
 0x0010: 6d70 6c65 0363 6f6d 0000 0100 01        mple.com.....

Wireshark的解释是：

原始DNS响应：

 0x0000: 51d4 8180 0001 0001 0000 0000 0765 7861 ‘............exa
 0x0010: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
 0x0020: 0100 0100 0031 f500 045d b8d8 77 .....1...]..w

Wireshark的解释是：

DNS如何运作

DNS是分布式键/值数据库。从理论上讲，返回的值可以是任何值，但实际上需要适合众所周知的类型，例如地址，邮件交换，服务器列表，自由格式文本记录等。键由名称，类型和类组成。名称空间是分层的（请参阅下文），DNS信息由权威服务器“发布”。DNS解析器将遵循从一个权威DNS服务器到下一个权威DNS服务器的命名层次结构，通过询问适当的权威服务器来查找请求的信息。ISP通常提供一个递归解析器，该解析器将代表客户执行解析。您还可以使用公共解析器，例如Google（8.8.8.8，8.8.4.4）或OpenDNS（208.67.222.222，208.67.220.220）提供的解析器。

支持Web的应用程序（例如浏览器）使用称为Stub Resolver的工具与DNS进行交互。一旦应用程序或浏览器获得了网站的IP地址，他们就可以使用HTTP或HTTPS协议访问它。

DNS命名空间

DNS名称空间的层次结构定义明确：DNS名称由以点分隔的标签组成。因此是“ www.example.com”。由4个标签“ www”（叶）“ example”（域）“ com”（TLD）和“。”组成 即根。解析程序通过从标签的最长匹配处开始进行搜索，即，如果它仅知道根，则从那里开始搜索。如果他们了解.com，就会从这里开始。

共有13个由12个不同的组织维护rootservers。根区域由IANA维护，IANA是ICANN的一部分，由运营两个根服务器的Verisign发布。根区域的内容是每个TLD的权威服务器的列表，但没有其他内容。因此，如果根DNS服务器收到对“ www.example.com”的查询，它将使用对“ .com”解析器的引荐进行回答。根服务器的答案包含一组称为NS（名称服务器）的记录。这些记录列出了名称服务器，这些名称服务器应具有有关所请求区域的更多信息，即“ .com”服务器。

每个TLD权威域名服务器都知道其下域（example.com，gingerdoc.com，google.com等）的权威域名服务器。向下进行下去，您最终将到达服务器，该服务器可以针对您要查找的名称回答有关记录的查询。

DNS是世界上最大的分布式委托数据库。委派意味着每个名称可以具有可以维护信息的不同权限，并且任何更改都将反映在DNS中。因此，重要的是解析程序不要永远保留他们学到的东西。同样，重要的解析器必须重用他们获取的信息，这一点很重要。信息的重用是通过在每个DNS记录上放置一个TTL来实现的，它告诉解析器他们可以重用记录多长时间来回答问题。解析器返回缓存的值时，它将向下调整TTL，以反映数据已驻留在其缓存中的时间。

DNS中间人攻击

某些DNS解析提供商可以通过修改DNS的映射，当用户发起查询时，返回的是一个非真实网站的ip地址。

卡明斯基的进攻

在2008年，Dan Kaminsky揭露了对DNS系统的攻击，该攻击可能诱使DNS递归解析器存储错误的DNS记录。一旦名称服务器存储了错误的响应，它将很高兴地将其返回给所有询问的人，直到缓存条目到期（通常由TTL指示）为止。这就是所谓的“ DNS中毒”攻击，它可能允许任意攻击者欺骗DNS，并将Web浏览器（和其他应用程序）重定向到错误的服务器，从而劫持流量。

DNS中毒攻击很容易描述，但难以实施。采取事件的顺序：

• 客户端查询递归解析器
• 递归解析器查询权威服务器
• 权威服务器回复递归解析器
• 递归解析器对客户端的答复

Kaminsky的攻击基于UDP是无状态协议且源IP地址被盲目信任这一事实。此处描述的每个请求和响应都是一个单独的UDP请求，其中包含往返于IP地址的请求。理论上，任何主机都可以伪造UDP消息上的源地址，使它看起来像来自预期的源。任何坐在不过滤出站数据包的网络上的攻击者都可以构造一条UDP消息，该消息表示来自权威服务器，并将其发送到递归解析器。

在上述请求中，第3条消息是很好的攻击目标。这是因为递归解析器将接受与其查询匹配的问题的第一个答案。因此，如果您可以比权威服务器更快地回答问题，则递归解析器将接受您的回答为事实。这是攻击的核心：

• 选择一个您要劫持其DNS条目的域。
• 向您的递归解析器发送要中毒的记录的请求。
• 发送许多假冒的UDP响应，假装自己是权威服务器，并提供您选择的答案（即，将A记录指向您控制的IP）。

如果您的一个恶意（可接受的）响应之一早于实际响应到达，则递归解析器将相信您的记录并将其缓存只要设置了TTL。然后，任何其他要求中毒记录的客户端都将被定向到您的恶意服务器。

有一些复杂性使它比实际听起来更难。例如，您必须猜测：

• 请求ID-16位数字
• 查询发送到的权威服务器地址
• 用于发送查询的递归解析器地址
• 用于将查询发送到权威服务器的UDP端口

当最初提出卡明斯基的攻击时，其中许多值很容易被猜测或发现，从而使DNS中毒成为真正的威胁。从那时起，请求ID，端口随机化和源地址轮换使这种特定攻击更加难以实施，但并非不可能。DNS缓存中毒是一个实际问题，并且在2014年9月之前就已经有报道。

允许发生这种攻击的根本问题是，解析程序无法验证记录是否应为真实记录。注意：如果攻击者可以查看来自递归解析器的查询流量，则它具有伪造答案所需的所有信息（请参阅http://www.wired.com/2014/03/quantum/）。

域名系统

DNS的安全性扩展增加了对DNS记录的保护，并允许解析器和应用程序对接收到的数据进行身份验证。这些强大的功能将意味着来自DNS的所有答案都是可以信任的。前面我们描述了DNS解析如何从根名称服务器开始，然后降级（例如，对于“ www.example.com”，它是从根服务器开始，然后是“ com”，然后是“ example.com”）。这与通过DNSSEC授予信任的方式相同。DNS根是确定的信任根，并且从任何DNS条目到根都建立了信任链。这与用于验证TLS / SSL证书的信任链非常相似，不同之处在于，有一个受信任的根密钥由DNS根维护者IANA管理，而不是许多受信任的根证书。

DNSSEC的目的是提供一种让接收记录的人信任DNS记录的方法。DNSSEC的关键创新是使用公共密钥加密技术来确保DNS记录是真实的。DNSSEC不仅允许DNS服务器证明其返回记录的真实性。它还允许断言“记录不存在”。

DNSSEC信任链是一系列记录，用于标识公共密钥或一组资源记录的签名。此信任链的根是由DNS根的操作员维护和管理的根密钥。DNSSEC由IETF在RFC中定义4033，4034，和4035。

有几种重要的新记录类型：

• DNSKEY：公共密钥，用于签署一组资源记录（RRset）。
• DS：委托签署者，密钥的哈希。
• RRSIG：共享名称/类型/类别的RRset的签名。

DNSKEY记录是加密的公共密钥，DNSKEY可以分为两个角色，可以通过单独的密钥或单个密钥来处理

• KSK（密钥签名密钥）：用于签署DNSKEY记录。
• ZSK（区域签名密钥）：用于对域中所有其他记录进行权威性签名。

对于给定的域名和问题，有一组答案。例如，如果您要求gingerdoc.com提供A记录，那么您将获得一组A记录作为答案：

 gingerdoc.com.            285    IN    A    198.41.212.157
 gingerdoc.com.            285    IN    A    198.41.213.157

域的给定类型的所有记录的集合称为RRset。RRSIG（资源记录SIGnature）本质上是RRset的数字签名。每个RRSIG与一个DNSKEY相关联。DNSKEY的RRset用密钥签名密钥（KSK）签名。其他所有都使用区域签名密钥（ZSK）签名。通过RRSIG将信任从DNSKEY授予记录：如果信任DNSKEY，则可以信任由该密钥正确签名的记录。

但是，域的KSK是自己签名的，因此很难信任。解决方法是将域移至下一个/父区域。要验证example.com的DNSKEY是否有效，您必须询问.com权威服务器。这就是DS记录发挥作用的地方：它充当了DNS父级信任的桥梁。

DS记录是DNSKEY的哈希。.com区域为提供DNSSEC密钥信息的每个区域存储该记录。DS记录是.com区域中RRset的一部分，因此具有关联的RRSIG。这次，RRset由.com ZSK签名。.com DNSKEY RRset由.com KSK签名。

信任的最终根源是DNS根的KSK DNSKEY。该密钥是众所周知的并已发布。

这是2010年8月发布的DNSKEY根KSK，将在2015年或2016年某个时候使用（以base64编码）：

 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcC jFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJR kxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efu cp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA 6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQd XfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhY B4N7knNnulqQxA+Uk1ihz0=

通过将DNSKEY，DS和RRSIG记录链链接到根，可以信任任何记录。

这些记录足以证明资源记录的完整性，但是还需要更多的东西来证明资源记录不存在。这是另外两个记录类型NSEC和NSEC3起作用的地方。

如果DNS权威服务器知道没有特定请求的记录，则它可以响应此类请求。当要求的名称不存在时，它返回一条消息，该消息具有返回码（RCODE）NXDOMAIN。当名称存在但请求的类型不存在时，它将返回NODATA响应，即空答案。

这些不存在的答案未经身份验证，可以像任何其他DNS响应一样由第三方伪造。但是，DNSSEC通过创建一个记录类型来解决此问题，该记录类型表示存在的名称以及每个名称驻留的类型。该记录称为NSEC。NSEC可以由DNSSEC签名，并经过根验证。通常，使用NSEC覆盖区域中具有记录的所有域之间的间隙。在大多数情况下，这实际上使该区域中的记录数增加了一倍，但允许权威的名称服务器以任何问题的签名响应进行回复。

区域ietf.org.使用NSEC记录。询问“ trustee.ietf.org”会给您一个肯定的答案，提供IP地址和RRSIG记录。询问“ tustee.ietf.org”会给您一个否定的回答：“ trustee.ietf.org和www.ietf.org之间没有名称”，并带有相应的RRSIG。 例如：

询问：

 tustee.ietf.org/A

回复：

 trustee.ietf.org.        1683        IN        NSEC        www.ietf.org. A MX AAAA RRSIG NSEC

这意味着，当按字母顺序排序时，trustee.ietf.org和www.ietf.org之间的区域没有名称，有效地证明了tustee.ietf.org不存在。

RFC5155通过NSEC3记录定义了一种模糊的方式来拒绝存在。NSEC3使用类似的逻辑，但是对名称进行了哈希处理。询问examplf.com（e在f之前）会给您“在A和B之间没有散列的记录”，其中A是依字典顺序在词典中排在倒数第二的哈希，而b是在其后倒数第二。

结论

DNSSEC是用于提高DNS（现代Internet的骨干）的信任和完整性的宝贵工具。