Skip to main content
Resources

检查 DNS 验证解析器中的当前信任锚

本页面还提供其他语种：

本文档已翻译为多种语言，仅供参考之用。原始官方版本（英文版）可在以下位置找到：https://www.icann.org/dns-resolvers-checking-current-trust-anchors

本页专供希望确保使用了最新信任锚来进行 DNSSEC 验证的 DNS 解析器（有时称为"递归解析器"）管理员使用。如果您使用了此类解析器，而又不确定您的解析器是否可用于 KSK 轮转，则可以按照本页上的说明来确保您拥有最新的信任锚。

我们还提供了一份介绍如何更新到最新信任锚的附加文档，位于此处。有关 KSK 轮转的详细信息，请点击此处。

只有当您的 DNS 解析器正在验证 DNSSEC 时，您才需要本页面上的信息。只要合适，ICANN 建议随时验证 DNSSEC，但如果您尚未验证 DNSSEC，则不需要本页面上的说明。

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

dig @ADDRESS dnssec-failed.org a +dnssec

在以上命令中，请使用您的解析器的 IPv4 或 IPv6 地址替换字符串 ADDRESS。

如果响应包含以下内容：

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

则说明解析器正在执行 DNSSEC 验证。（此处的 SERVFAIL 状态标识表明验证失败，这说明实际上执行了验证。）

相反，如果响应包含以下内容：

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

则说明解析器没有执行 DNSSEC 验证。

本页面上的其他部分列出了各种解析器实现和检查其信任锚所需参照的说明。

BIND

BIND 版本 9.9、9.10 和 9.11 支持使用自动 RFC 5011 更新的 DNSSEC 验证。这些版本的最新子版本随附 KSK2017，将其作为信任锚的组成部分。

首先检查是否在您的配置文件中设置了 DNSSEC 验证。options 部分应该有一行 dnssec-validation auto; 或 dnssec-validation yes; 命令。如果您的配置显示 dnssec-validation yes;，则必须将其更改为 dnssec-validation auto;，并重新启动服务器，然后执行以下步骤。

要生成包含使用的信任锚的文件，请提供以下命令

rndc secroots

该命令可在创建 BIND 的其他文件的同一目录中创建一个 named.secroots 文件。该文件应包含两行，一行是 ./RSASHA256/20326，另一行是 ./RSASHA256/19036。如果其中没有包含这些键，则应按照此处 所述更新您的信任锚。

BIND 的创建者 ISC 提供了关于 BIND 的 DNSSEC 信任锚的其他信息，网址为 https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html [kb.isc.org]。

Unbound

请在 Unbound 的配置目录中查看 root.key 文件，通常位于 /etc/unbound 下。其中应有 DNSKEY 记录，一条包含文本 id = 20326，另一条包含文本 id = 19036；两条记录都包含 ;;state=2 [ VALID ]。

如果您使用的是 Unbound 1.6.2 或更新版本，则在资源类型 TXT 的类 CH 中查询名称为 trustanchor.unbound 的解析器也可以获得信任密钥列表，如使用以下命令：

dig @address trustanchor.unbound -c CH -t TXT

如果该文件没有这两个密钥，或其中一个密钥的状态不是 ;;state=2 [ VALID ]，或者如果查询没有同时指明两个密钥，则应按照此处 所述更新您的信任锚。

PowerDNS Recursor

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

在命令行界面中提供以下命令：

rec_control get-tas

您应得到一行包含文本 . 20326 的命令和另一行包含文本 . 19036 的命令。如果其中没有包含这些键，则应按照此处 所述更新您的信任锚。

Knot Resolver

Knot Resolver 的所有版本支持使用自动 RFC 5011 更新的 DNSSEC 验证。

请查看 Knot Resolver 的配置目录（具体取决于分发）中的 root.keys文件。您应找到两行命令，其中一行包含文本 0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB，另一行包含文本 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5。如果其中没有包含这些键，则应按照此处 所述更新您的信任锚。

Windows Server 2012R2 和 2016

Windows Server（2012R2 和 2016）支持使用自动 RFC 5011 的 DNSSEC 验证。以下命令使用 Windows PowerShell。

要检查信任锚的内容，请使用：

Get-DnsServerTrustAnchor -Name .

应看到：

TrustAnchorName TrustAnchorType TrustAnchorState TrustAnchorData
--------------- --------------- ---------------- ---------------
. 		DNSKEY 		Valid 		 [19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...
. 		DNSKEY 		Valid 		 [20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...

该密钥标签显示在 TrustAnchorData 下。对于根信任锚，应看到两个密钥标签：19036 和 20326。这两个信任锚的状态都应该是"Valid"（有效）。如果其中没有包含这些键，则应按照此处 所述更新您的信任锚。

要查看服务器上活动的当前信任点，请使用：

Get-DnsServerTrustPoint

该命令将显示：

TrustPointName 	TrustPointState LastActiveRefreshTime 	NextActiveRefreshTime
-------------- 	--------------- --------------------- 	---------------------
.		Active 		9/11/2017 8:37:02 PM 	9/12/2017 8:37:02 PM

Akamai DNSi Cacheserve

Akamai DNSi Cacheserve（版本为 7.1.2.3、7.2.0.3、7.2.1.2 或更高）支持使用 RFC5011 托管密钥的 DNSSEC 验证。尽管在更低版本中也支持此功能，但不应使用，因为轮转代码存在问题。要检查 Akamai DNSi Cacheserve 是否确实在验证，请运行以下命令：

nom-tell cacheserve resolver.mget fields='(trusted-keys managed-keys-state)'

如果输出中有任何 trusted-keys 或 managed-keys-state 字段，则说明 Akamai DNSi Cacheserve 正在执行 DNSSEC 验证，但您要确保使用的密钥正确。在根 ('.') 的 managed-keys-state 中，应看到 keyid 的值为 19036 和 20326，且两者的 state 均为 valid，同时 has-validated 字段设置为 True。对于信任密钥，您要对比实际密钥材料。要进行检查，或者如果密钥与上文所述不同，要进行修复，请参阅此处 的介绍。

Infoblox NIOS

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

检查 NIOS 中的当前信任锚的步骤如下：

  1. 登录 NIOS GUI
  2. 导航到"数据管理"→ DNS
  3. 单击工具栏中的"网格 DNS 属性"
  4. 开启"高级模式"
  5. 选择"DNSSEC"选项卡
  6. 向下滚动至"信任锚"
  7. 所有配置的信任锚将显示在"信任锚"表格中。查看"区域"列中包含"."且"安全入口点"点中包含复选标记的条目。（如果没有此类信任锚，则说明没有配置根区签名密钥。）将鼠标指针指向"公开密钥"列中的值可查看完整值。

如果从成员级别进行检查：

  1. 登录 NIOS GUI
  2. 导航到"数据管理"→ DNS →"成员/服务器"
  3. 选择 DNS 服务器
  4. 单击"编辑"
  5. 开启"高级模式"
  6. 选择"DNSSEC"
  7. 向下滚动至"信任锚"
  8. 所有配置的信任锚将显示在"信任锚"表格中。查看"区域"列中包含"."且"安全入口点"点中包含复选标记的条目。（如果没有此类信任锚，则说明没有配置根区签名密钥。）将鼠标指针指向"公开密钥"列中的值可查看完整值。

要区分旧根密钥签名密钥和新密钥，可看到旧根区密钥签名密钥为：

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

新（当前）根区密钥签名密钥显示为：

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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