Skip to main content
Resources

DNSSEC - 它是什么?为什么说它很重要?

本页面还提供其他语种:

您有兴趣深入学习域名系统安全扩展 (DNSSEC) 吗? 请点击下方图片查看关于 DNSSEC 定义和部署优势的信息图表。

BENEFITS OF DEPLOYING DNSSEC

DNS 运作方式的简要描述

了解域名系统安全扩展 (DNSSEC),这有助于对域名系统 (DNS) 有基本的认识。

互联网的正常运转离不开 DNS。访问的每一个网页、发送的每一封电子邮件,以及从社交媒体中检索到的每一张图片:所有这些交互都要通过 DNS 将易于使用的域名(如 icann.org)转换为 IP 地址(如 192.0.43.7 和 2001:500:88:200::7),服务器、路由器和其他网络设备需要根据 IP 地址将流量路由到互联网上的适当目的地。

无论在任何设备上使用互联网,都需要首先提供 DNS。例如,设想一下,如果用户在手机浏览器中输入网站名称,浏览器使用存根解析器(作为设备操作系统的一部分)开始将网站域名转换为互联网协议 (IP) 地址。存根解析器是一种极为简单的 DNS 客户端,它会将应用的 DNS 数据请求传递到更复杂的 DNS 客户端,也就是所谓的递归解析器。很多网络运营商运行递归解析器,以便处理设备通过其网络发送的 DNS 请求或查询。(有时,小型运营商和组织会对其他网络使用递归解析器,包括作为公众服务运行的递归解析器,如 Google Public DNS、OpenDNS 和 Quad9。)

递归解析器可跟踪或解析针对存根解析器发送的 DNS 请求做出的应答。该解析流程通常要求递归解析器将其 DNS 查询发送至多个不同的权威域名服务器。每个域名的 DNS 数据均存储于互联网某处的权威域名服务器中。域 DNS 数据称为区域。有些组织自行运行域名服务器发布区域,但很多组织通常将此职能外包给第三方。一些不同类型的组织代表他方(包括注册服务机构、注册管理机构、网络托管公司、网络服务器提供商等)托管 DNS 区。

DNS 本身并非安全无虞

DNS 设计于上世纪 80 年代,当时互联网规模小得多,安全性并非首要设计考虑因素。因此,当递归解析器向权威域名服务器发送查询时,解析器无法验证响应真实性。解析器仅可检查做出响应的 IP 地址与解析器发送初始查询的 IP 地址是否相同。但是,依赖响应对应的源 IP 地址并非强验证机制,因为 DNS 响应数据包的源 IP 地址很容易仿冒或伪造。鉴于最初设计 DNS 时,解析器无法轻易识别某一项查询的仿冒响应。攻击者很容易冒充看似来自权威服务器的响应,继而伪装成解析器最初查询的权威服务器。换言之,攻击者可以悄无声息地将用户重定向至潜在恶意网站。

递归解析器可缓存从权威域名服务器接收到的 DNS 数据以加速解析流程。如果存根解析器请求提供递归解析器缓存的 DNS 数据,递归解析器可以立即做出应答,避免首次查询一个或多个权威服务器引发的延迟。然而,依靠缓存存在一个缺点:如果攻击者发送的仿冒 DNS 响应获得递归解析器的接受,则意味着递归解析器缓存投毒成功。而后,解析器将源源不断地向其他查询设备返回欺诈性 DNS 数据。

缓存投毒攻击威胁为例,设想一下,如果用户访问银行网站,会怎么样?用户设备在其配置的递归域名服务器中查询银行网站的 IP 地址。不过,攻击者可以通过 IP 地址向解析器投毒,届时 IP 地址并非指向目标合法网站,而是指向攻击者创建的某个网站。这个欺诈网站冒充银行网站,看上去毫无差别。一如既往,用户毫无防备地输入名称和密码。很遗憾,用户在不经意间向攻击者透露了自己的银行凭证,攻击者可以堂而皇之地以用户的身份登录合法银行网站进行转账或执行其他未经授权的操作。

DNS 安全扩展 (DNSSEC)

互联网工程任务组 (IETF) 是一家负责制定 DNS 协议标准的组织,IETF 工程师们早已意识到缺乏更强的验证机制是 DNS 面临的一大问题。自上世纪 90 年代起,人们开始寻求解决方案,最终 DNS 安全扩展 (DNSSEC) 应运而生。

DNSSEC 采用基于公共密钥加密数字签名,从而增强 DNS 验证强度。DNSSEC 并非对 DNS 查询和响应本身进行加密签名,而是由数据所有者对 DNS 数据自身进行签名。

每一个 DNS 区均包含一个公私秘钥对。DNS 区所有者使用该区域的私钥对区域内的 DNS 数据进行签名,为这些数据生成数字签名。顾名思义,"私钥"是指 DNS 区所有者会对这些密钥材料保密。但是,该区域的公钥则在区域内公开发布,供全体用户检索。凡在区域内查找数据的递归解析器,还必需检索区域公钥,从而使用公钥验证 DNS 数据的真实性。解析器确认检索到的 DNS 数据的数字签名是否有效。如果有效,证明 DNS 数据合法,则将 DNS 数据返回给用户。如果签名未通过验证,解析器会假设发生攻击,丢弃数据并向用户返回错误。

DNSSEC 在 DNS 协议中新增了两项重要功能:

  • 数据来源验证 - 解析器可以通过加密的方式验证收到的数据是否确实来自其认定的数据传送区域。
  • 数据完整性保护 - 解析器可以确信,自区域所有者使用区域私钥初次进行数据签名以来,数据在传输过程中并未遭到修改。

信任 DNSSEC 密钥

每个区域都会发布公钥,递归解析器可检索公钥以验证区域中的数据。那么,解析器如何确保区域公钥本身真实可靠呢?与区域中的其他数据一样,区域公钥也经过签名。但是,公钥并非由区域私钥签名,而是由父区域私钥签名。例如,icann.org zone 的公钥由 org 区域进行签名。DNS 区域的父区域负责发布子区域的权威域名服务器列表;同样,区域的父区域还需负责核实其子区域公钥的真实性。每一个区域的公钥均由其父区域签名,但根区除外:没有可供进行密钥签名的父区域。

因此,根区公钥是验证 DNS 数据的重要出发点。如果解析器信任根区公钥,则可信任经根区私钥签名的顶级区域公钥,如 org 区域公钥。由于解析器可以信任 org 区域公钥,因而可以信任经其各自私钥签名的公钥,如 icann.org 公钥。(在实际工作中,父区域不会直接对子区域密钥进行签名 - 实际机制更加复杂 - 但效果与父区域对子区域密钥进行签名一致)。

对其他加密密钥进行签名的加密密钥序列称为信任链。信任链最前端的公钥称为信任锚。解析器具有信任锚列表,其中列出了解析器隐含信任的不同区域的公钥。大部分解析器仅配置一个信任锚:根区公钥。通过信任 DNS 层次结构顶端的这个密钥,只要对路径中的每一个区域均进行签名,则解析器可以为 DNS 域名空间的任意位置构建信任链。

使用 DNSSEC 验证和签名

为确保互联网的普遍安全性,需广泛部署 DNSSEC。DNSSEC 并非自动启用:目前不仅需要网络运营商在递归解析器中专门启用,还要域名所有者在区域权威服务器中启用。解析器和权威服务器运营商为系统启用 DNSSEC 的激励措施有所不同;然而一旦决定启用 DNSSEC,将可保证越来越多的用户就其 DNS 查询获得经过验证的应答。简言之,用户可保证最终抵达理想的在线目的地。

在递归解析器中启用 DNSSEC 验证很简单。事实上,早在多年前,几乎所有常用解析器均支持 DNSSEC 验证。为启用 DNSSEC 验证验证,只需在解析器的配置文件中更改几行内容。随后,如果用户向解析器请求来自签名区域的 DNS 信息,但上述数据遭到篡改,用户将可(有意选择)拒绝获取数据。DNSSEC 可检测攻击及防止用户获取被篡改的数据,从而阻止用户从签名区域中获取恶意数据。

使用 DNSSEC 进行区域签名分几个步骤,但鉴于有数百万个区域执行 DNS 信息签名,因而可以保证验证解析器的用户获取安全数据。几乎所有常用权威域名服务器软件均支持区域签名,很多第三方 DNS 托管提供商还支持 DNSSEC。通常,为托管提供商区域启用 DNSSEC 的过程非常简单:往往只需单击复选框而已。

如果区域所有者要部署 DNSSEC,不仅需要对区域数据进行签名,还要对区域的父区域、父区域的父区域一直到根区进行签名,从而尽可能加强 DNSSEC 的有效性。自根区开始建立持续的签名区域链,解析器将可从根区起构建信任链以验证数据。例如,为在 icann.org 区域中有效部署 DNSSEC,需对 org 区域及根区进行签名。令人欣慰的是,自 2010 年起,人们已对 DNS 根区进行了签名,所有通用顶级域及很多 ccTLD 也已经过签名。

为在区域中部署 DNSSEC,还要完成另外一个步骤:需将新签名的区域公钥材料发送至该区域的父区域。如前所述,父区域对子区域的公钥进行签名,形成一条自父区域延伸至子区域的信任链。

而今,区域所有者通常需要将区域公钥材料手动发送给父区域。在大多数情况下,通过区域所有者的注册服务机构完成这一通信过程。区域所有者通过其注册服务机构对区域做出其他更改,如区域权威域名服务器列表;同样,区域所有者也可联系注册服务机构,以更新该区域的公钥材料。虽然现阶段此流程仍采用手动形式,但最近开发的协议有望在未来实现流程自动化。

DNSSEC 的后续工作

随着 DNSSEC 部署规模的扩大,人们很可能以 DNS 为基础开发其他协议并要求设法安全存储数据。新协议依托 DNSSEC 开发,因而仅可在签名区域中使用。例如,基于 DNS 的名称实体验证 (DANE) 允许在区域中面向邮件传输等应用发布安全传输层协议 (TLS) 密钥。DANE 开创了一种验证公钥真实性的方法,不再依赖认证机构。未来在开发向 DNS 查询添加隐私的新方法时也可以使用 DANE。

2018 年,ICANN 首次更改 DNS 根信任锚。在此过程中,积累了大量有关 DNSSEC 的经验教训。此外,很多解析器运营商开始加大对 DNSSEC 的关注度并启用验证,全世界对于 DNSSEC 系统整体运作方式的认识越来越清晰。在未来的几年里,ICANN 希望解析器运营商和区域所有者越来越多地采用 DNSSEC。这意味着,全球各地的更多用户可以通过 DNSSEC 的有力加密保证受益,在查询时获得真实可靠的 DNS 应答。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."