Skip to main content
Resources

使用最新的信任锚更新 DNS 验证解析器

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到:https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

本页面旨在为 DNS 解析器(有时称为"递归解析器")的管理员提供相应信息。在以下任一情况下,此处的信息都会很有用:

  • 使用 DNS 解析器的运营商发现他们未安装新的 KSK
  • 在 KSK 轮转后,DNS 解析器针对所有 DNS 请求均报错

根据本页面的说明,可能会需要使用最新的信任锚进行 DNSSEC 验证。

有一个相关的文档说明了如何检查是否在使用最新的信任锚;您可以在此处 找到该文档。可在此处 找到有关 KSK 轮转的更多信息。

要测试您使用的解析器是否执行 DNSSEC 验证,可以使用由 Comcast 作为公共服务来运营的特殊域"dnssec-failed.org"。此特殊域会导致验证解析器故意无法做出响应。在 shell 命令行中输入以下命令:

dig @ADDRESS dnssec-failed.org a +dnssec

在此命令中,将字符串 ADDRESS 替换为所用解析器的 IPv4 或 IPv6 地址。

如果响应包含以下内容:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

那么表明解析器执行了 DNSSEC 验证。(此处的状态指示 SERVFAIL 表示验证已失败,这意味着实际执行了验证。)

相反,如果响应包含以下内容:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

那么表明解析器未执行 DNSSEC 验证。

本页面的其余部分列出了各种解析器实施以及更新解析器所需的说明信息。


BIND

BIND 版本 V9.9、V9.10 和 V9.11 支持使用自动 RFC 5011 更新的 DNSSEC 验证。这些版本的最新子版本随附 KSK2017,将其作为信任锚的组成部分。

首先,请检查是否在配置文件中设置了 DNSSEC 验证。您应该在 options 部分中看到一行内容:dnssec-validation auto;dnssec-validation yes;。如果将 dnssec-validation 设置为 auto,那么无需更新软件或配置。只需使用通常用于停止和启动 BIND 的任何命令重新启动软件;这将为 dnssec-validation auto 引入最新的信任锚。

如果配置显示 dnssec-validation yes;,那么必须将其更改为 dnssec-validation auto;,重新启动服务器,然后再执行以下步骤。

如果可更新软件,请执行以下操作:

  1. 通过您安装软件时使用的方法将该软件更新为 BIND 9.9、BIND 9.10 或 BIND 9.11 的最新子版本。如果当前运行的是 BIND 9.8,由于该版本的软件不再受支持,因此需要更新为 BIND 9.9 或更高版本。您至少需要以下某一个子版本:
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. 在配置文件中,确保 options 部分包含如下一行:dnssec-validation auto;
  3. 使用通常用于停止和启动 BIND 的任何命令,停止旧版本的 BIND 并启动新版本。

如果无法更新软件,请执行以下操作:

  1. 更新 bind.keys 文件以包含新的信任锚。bind.keys 文件应存储在创建其他 BIND 文件的同一目录中。或者,如果您的 named.conf 文件中包含列出信任锚的 managed-keys 部分,那么可更新此部分。修改后的文件或配置部分应包含以下内容:

    managed-keys {
    	. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    		FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    		bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    		X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    		W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    		Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    		QxA+Uk1ihz0=";
    
    	. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    		+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    		ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    		0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    		oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    		RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    		R1AkUTV74bU=";
    };
    

如果配置中的 dnssec-validation 设置为 auto,那么 bind.keys 文件的内容将与配置中 managed-keys 部分的内容进行组合。可在以下位置找到有关此部分的更多信息:https://www.isc.org/downloads/bind/bind-keys/

ISC(BIND 的创建者)在以下位置提供了有关用于 BIND 的 DNSSEC 信任锚的更多信息:https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html


Unbound

但是,低于 1.6.5 的所有 Unbound 版本都存在一个限制,如果首次启动这些 Unbound 版本的时间在轮转前 30 天内,那么此限制会阻止它们接受新的信任锚。

如果您运行的是 Unbound 版本 1.6.5 或更高版本,请执行以下操作:

  1. 使用以下命令删除当前的信任锚:

    rm root.key
  2. 使用以下命令获取最新版本的信任锚:

    unbound-anchor
  3. 使用通常用于启动 Unbound 的任何命令,重新启动 Unbound,以使其重新加载新配置。

如果您运行的是 Unbound 版本 1.6.4 或更低版本,并且可更新软件,请执行以下操作:

  1. 更新为 Unbound 版本 1.6.5 或更高版本。

  2. 使用以下命令删除当前的信任锚:

    rm root.key
  3. 使用以下命令获取最新版本的信任锚:

    unbound-anchor
  4. 使用通常用于启动 Unbound 的任何命令,重新启动新版本的 Unbound,以使其重新加载新配置。

如果您运行的是 Unbound 版本 1.6.4 或更低版本,root.key 文件中有一个密钥未列为 [ VALID ],并且您无法更新软件,请执行以下操作:

  1. 访问页面 https://www.unbound.net/root-11sep-11oct.html,了解如何从 NLnet Labs 获取两个密钥均设置为 [ VALID ] 的新 root.key 文件。
  2. 使用通常用于启动 Unbound 的任何命令,重新启动 Unbound,以使其重新加载新配置。

PowerDNS Recursor

PowerDNS Recursor 版本 4 支持 DNSSEC 验证,但尚不支持使用自动 RFC 5011 更新的 DNSSEC 验证。这意味着,对于 PowerDNS Recursor,每次信任锚发生更改时,都需要获取一组新的信任锚。版本 4.0.5 和更高版本的 PowerDNS Recursor 随附 KSK2017,将其作为已安装信任锚的组成部分。

如果可更新软件,请执行以下操作:

  1. 通过您安装软件时使用的方法将软件更新为 PowerDNS Recursor 的最新子版本。确保所检索的版本为 4.0.5 或更高版本。
  2. 使用通常用于停止和启动服务器的任何方法,退出当前版本的 PowerDNS Recursor,并启动新版本。

如果无法更新软件,请执行以下操作:

  1. 如果您的主 PowerDNS 配置中尚不存在 lua-config-file 行,那么必须添加该行。该行指向包含其他 PowerDNS 配置的文件。该行可能类似于以下行:

    lua-config-file=/etc/pdns/luaconf.txt
  2. lua-config-file 行所指向的文件中,添加以下两行:

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. 使用通常用于停止和启动服务器的任何方法,重新启动 PowerDNS Recursor。


Knot Resolver

Knot Resolver 的所有版本都支持使用自动 RFC 5011 更新的 DNSSEC 验证。要获取最新版本的信任锚,您可以删除包含密钥的当前版本文件,然后重新启动 Knot Resolver。因此,您无需更新 Knot Resolver 版本;只需获取最新的信任锚并重新启动 Knot Resolver。

  1. 在配置文件中,确保存在如下一行:

    trust_anchors.file = 'root.keys'
  2. 如果此文件中没有包含 1903620326 的行,请使用通常所用的任何方法停止服务器,删除 root.keys 文件,然后重新启动服务器。这将使 Knot Resolver 使用来自 IANA 的最新信任锚重新创建该文件。


Windows Server 2012R2 和 2016

Windows Server(包括 2012R2 和 2016)支持使用自动 RFC 5011 的 DNSSEC 验证。要获取最新版本的信任锚,您可以更新当前版本的文件,然后重新启动 Windows Server。以下命令使用 Windows PowerShell。

信任锚通常会自动更新。要查看信任锚的刷新时间,请使用以下命令:

Get-DnsServerTrustPoint

结果将显示:

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

显示的时间为 UTC。如果信任锚未正常刷新,您可以使用以下命令替换信任锚:

Add-DnsServerTrustAnchor -Root

添加信任锚后,您应该在 Get-DnsServerTrustPoint 命令的输出中看到更新的 LastActiveRefreshTime

注意:如果 Add-DnsServerTrustAnchor -Root 失败,请确保在服务器上启用 DNSSEC。使用以下三个命令:

$a = Get-DnsServerSetting -All
$a.EnableDnsSec = 1
$a | Set-DnsServerSetting

您可以使用以下命令验证 RootTrustAnchorsURL 是否指向 https://data.iana.org/root-anchors/root-anchors.xml

(Get-DnsServerSetting -All).RootTrustAnchorsURL

如果 Add-DnsServerTrustAnchor -Root 命令仍不起作用,那么可能是防火墙拦截了传输。在某些安全等级很高的环境中可能会发生此情况。要手动添加 DS 信任锚,您需要知道摘要、算法和密钥标记。要添加 DNSKEY 信任锚,需要使用公共 DNSKEY (Base64Data)。或者,如果您可以访问密钥集(针对 DNSKEY 锚)或 DSSET(针对 DS 锚)文件,那么可导入信任锚。可在以下位置查看根信任锚的摘要、算法(摘要类型)和密钥标记:https://data.iana.org/root-anchors/root-anchors.xml

以下命令可演示手动向根区中添加 DS 信任锚的操作。

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

更新信任锚后,无需重新启动 DNS 服务。但是,你可以使用以下命令清除 DNS 服务器缓存:

Clear-DnsServerCache -Force

可在以下位置找到 Microsoft 提供的更多信息:https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor


Akamai DNSi Cacheserve

Akamai Cacheserve(版本 7.1.2.3、7.2.0.3、7.2.1.2 或更高版本)支持使用 RFC5011 受管密钥的 DNSSEC 验证。尽管在更低版本中也支持此功能,但不应使用,因为轮转代码存在问题。

如果可更新软件,请执行以下操作:

  1. 要获取最新的 DNSSEC 根密钥,最简单的方法是使用受管密钥并将 Akamai DNSi Cacheserve 更新为以下版本:

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    或者各自系列上的更高版本,其中已内置新的根密钥且生效。

如果无法更新软件,请执行以下操作:

  1. 请参阅 https://support.nominum.com/view-article/965 中的信息,或通过 https://support.nominum.com/ 联系 Akamai。

Infoblox NIOS

Infobox NIOS 支持 DNSSEC 验证,但尚不支持使用自动 RFC 5011 更新的 DNSSEC 验证。这意味着对于 Infoblox NIOS,每次信任锚发生更改时,都需要配置一组新的信任锚。

在 NIOS 中将新的根区密钥签名密钥作为信任锚进行添加的步骤如下:

  1. 登录 NIOS GUI
  2. 导航至"数据管理"→"DNS"
  3. 单击工具栏中的"网格 DNS 属性"
  4. 开启"高级模式"
  5. 选择"DNSSEC"选项卡
  6. 向下滚动至"信任锚"
  7. 单击"添加"按钮并输入密钥的详细信息。区域为".",算法为"RSA/SHA-256(8)"。
  8. 将密钥粘贴到"公共密钥"列。公共密钥为:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    

如果从成员级别添加,请执行以下操作:

  1. 登录 NIOS GUI
  2. 导航至"数据管理"→"DNS"→"成员/服务器"
  3. 选择 DNS 服务器
  4. 单击"编辑"
  5. 开启"高级模式"
  6. 选择"DNSSEC"
  7. 向下滚动至"信任锚"
  8. 单击"添加"按钮并输入密钥的详细信息。区域为".",算法为"RSA/SHA-256(8)"。
  9. 将密钥粘贴到"公共密钥"列。公共密钥为:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    
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."