Skip to main content

ICANN 推迟 KSK 轮转的背后理由

现在,许多人都知道 ICANN 已经发布声明决定推迟对密钥变更的时间,以保护域名系统 (Domain Name System, DNS)。这次变更,又称"轮转",最初定于在 10 月 11 日进行。

我想向大家谈一谈我们做出推迟轮转这一决定的背后详细理由。您可以称其为背后的故事。

以前,我们无法采用任何方式确定域名系统安全扩展 (DNSSEC) 验证器到底配置了哪些信任锚,因此很难确定根区密钥签名密钥 (KSK) 在轮转时可能带来怎样的影响。但这种情况近期发生了变化,我们收到了一些无法忽视的新数据。

"DNS 安全扩展 (DNSSEC) 的信任锚报告信息"(请参见 RFC 8145 中的定义)是近期推出的一套协议扩展,旨在允许验证器向根区域名服务器汇报针对该根区配置了哪些信任锚。

该协议仅在 2017 年 4 月定稿,且只有普遍使用的解析器软件最新版(即 BIND 9.10.5b1 版和 9.11.0b3 版和后续版本,以及 Unbound 1.6.4 版和后续版本)才对该协议提供支持。最初,我们认为该协议的部署不够广泛,无法为首次根区 KSK 轮转提供有用的信息。

然而,某些非常初步的研究(通过威瑞信公司 (Verisign) 和 ICANN 组织)显示,越来越多的验证器开始向根服务器报告其信任锚配置。从六大根服务器地址返回的数据显示,在 2017 年 9 月期间,大约有 12,000 个唯一源 IP 地址发送了信任锚配置报告。且提交报告的数量还在不断上升,目前每天已有约 1,400 个唯一地址发出报告。

这些返还的报告显示,所有验证器中大约有 5%,且每天的报告中大约有 6%-8% 的验证器都在使用 KSK-2010 版本,即根区 KSK 目前签署的根区密钥 (DNSKEY) 资源记录集 (RRset)。重要的是,若 KSK 按照预期进行轮转后,这些验证器将无法进行正确解析。

根据这一最新信息,我们决定将根区 KSK 轮转推迟至少一个季度。

在整个项目推进的过程中,我们一直强调根区 KSK 的轮转是按照正常运营条件进行的,且整个推进过程是审慎而不冒进的。正是出于审慎考量,我们决定推迟变更。鉴于我们对当前密钥 KSK-2010 版本的安全性充满信心,因此在运营层面上并无变更压力。

验证器只能针对 KSK-2010 提供报告的背后原因有许多,例如:使用老式静态配置的信任锚(例如:BIND"可信密钥"声明)或在使用 RFC 5011 自动升级协议时发生故障,因软件缺陷、运营商操作错误或其他原因而无法自动升级。

鉴于目前有相当数量的验证器只能使用 KSK-2010,因而 ICANN 认为在进行根区 KSK 轮转之前必须理清背后原因。我们将在不久后发布只能报告 KSK-2010 的验证器清单,并请求运营社群帮助我们识别、诊断和修正这些系统。

我们诚挚感谢社群给予我们的理解,并期待着大家能够伸出援手,搜集必要信息,使得我们能够推进根区 KSK 轮转。

Comments

    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."