使用 DNSSEC 验证和保护 DNS 响应

2025-06-21
适用于: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

DNSSEC 资源记录用于验证和保护 DNS 响应。 DNS 区域通过区域签名使用 DNSSEC 进行保护。对区域进行签名可添加验证支持，而不会更改 DNS 查询和响应的基本机制。有关 Windows Server 中适用于 DNS Server 的 DNSSEC 的介绍，请参阅 DNSSEC 概述。

DNS 响应中包含数字签名以提供验证。这些数字签名包含在 DNSSEC 相关资源记录中，这些记录是在区域签名期间生成并添加到区域中的。

递归 DNS

当 DNSSEC 感知递归或转发 DNS 服务器收到来自 DNS 客户端的 DNSSEC 签名区域的查询时，它会请求权威 DNS 服务器也发送 DNSSEC 记录以验证 DNS 响应。如果递归或转发 DNS 服务器具有该区域的 DNSKEY（也称为信任锚），则它会识别该区域支持 DNSSEC。

重要

非权威 DNS 服务器可能会使用递归或转发来解析 DNS 查询。本主题将非权威服务器称为递归 DNS 服务器;如果服务器使用转发，则用于 DNS 响应的 DNSSEC 验证的过程是相同的。

DNSKEY 公司

递归 DNS 服务器使用 DNSKEY 资源记录来验证来自权威 DNS 服务器的响应。为了验证响应，DNS 服务器会解密 DNSSEC 相关资源记录中包含的数字签名，并比较哈希值。如果哈希值相同，它会向 DNS 客户端提供其请求的 DNS 数据的回复，例如主机（A）资源记录。如果哈希值不匹配，它将回复一条消息 SERVFAIL 。通过这种方式，无论 DNS 客户端是否支持 DNSSEC 并安装了有效信任锚点的解析 DNS 服务器都可以防止 DNS 欺骗攻击。

如果您的 DNS 客户端可识别 DNSSEC，则可以将其配置为要求 DNS 服务器执行 DNSSEC 验证。

下图显示了验证过程。

显示 DNSSEC 验证过程摘要的图表。

DNSKEY 用于计算哈希值和解密 RRSIG 记录。该图不显示执行的所有验证流程。还会进行更多验证，以确保 DNSKEY 有效，并且 DS 记录有效（如果存在）（屏幕截图中未显示）。

DNS 查询和响应过程

一个简单的示例说明了如何将 DNSSEC 合并到 DNS 查询和响应流程中以提供验证。

在以下示例中，DNS 客户端计算机查询递归（缓存）DNS 服务器，而递归 DNS 服务器又在返回响应之前查询权威 DNS 服务器。此示例假定 DNS 数据尚未缓存在客户端或服务器上。仅当区域已签名并且您使用的是 DNSSEC 感知服务器和客户端时，DNSSEC 数据才会验证 DNS 响应是否真实。

递归 DNS 查询过程如下图所示。

显示递归 DNS 查询过程的图表，如下表所示。

下表显示了使用可选 DNSSEC 数据的 DNS 查询和响应中的步骤。

步骤	查询-响应	可选的 DNSSEC 数据
1	DNS 客户端将 DNS 查询发送到递归 DNS 服务器。	DNS 客户端可以指示它是 DNSSEC 感知的（`DO=1`）。
2	递归 DNS 服务器向根和顶级域（TLD） DNS 服务器发送 DNS 查询。	递归 DNS 服务器可以指示它是 DNSSEC 感知的（`DO=1`）。
3	根服务器和 TLD 服务器将 DNS 响应返回给递归 DNS 服务器，提供区域的权威 DNS 服务器的 IP 地址。	父区域的权威服务器可以指示子区域是使用 DNSSEC 签名的，并包含安全委派（DS 记录）。
4	递归 DNS 服务器将 DNS 查询发送到区域的权威 DNS 服务器。	递归 DNS 服务器可以指示它是 DNSSEC 感知的（`DO=1`），并且能够验证要在响应中发送的签名资源记录（`CD=1`）。
5	权威 DNS 服务器将 DNS 响应返回给递归 DNS 服务器，并提供资源记录数据。	权威 DNS 服务器可以在 DNS 响应中包含 RRSIG 记录形式的 DNSSEC 签名，以用于验证。
6	递归 DNS 服务器向 DNS 客户端返回 DNS 响应，提供资源记录数据。	递归 DNS 服务器可以指示 DNS 响应是否使用 DNSSEC 进行了验证（`AD=1`）。

包括 DNSSEC 数据

DNSSEC 相关标志（bits）用于 DNS 查询和响应中，以确定是否包含 DNSSEC 数据，并执行验证。这些标志是通过打开或关闭 DNS 数据包标头中的扩展数据位来设置的。当这些标志打开时，它被称为 “设置” 位（值设置为 1）。关闭标志称为 “清除” 位（值设置为 0）。

DO：DO 位包含在 DNS 查询中，是“DNSSEC OK”的缩写。如果设置了 DO 位（），DO=1则客户端是 DNSSEC 感知的，并且 DNS 服务器在响应中返回 DNSSEC 数据是安全的。如果未设置 DO 位（），DO=0则客户端无法识别 DNSSEC，并且 DNS 服务器无法在 DNS 响应中包含任何 DNSSEC 数据。即使 DNS 客户端无法识别 DNSSEC，它们仍然可以使用 DNSSEC 进行保护。在此上下文中，DNS 客户端是发送 DNS 查询的任何计算机。当递归 DNS 服务器向权威 DNS 服务器发送查询时，递归 DNS 服务器必须表明它是 DNSSEC 感知的，以便权威 DNS 服务器在响应中发送 DNSSEC 数据。
AD：AD 位包含在 DNS 响应中，是“authenticated data”的缩写。如果设置了 AD 位（），AD=1则表示 DNS 响应是真实的，因为它是使用 DNSSEC 验证的。非验证 DNSSEC 感知计算机（例如运行 Windows 8 的计算机）不执行 DNSSEC 验证，但可以配置为要求 DNS 响应是真实的。如果未设置 AD 位（），AD=0则未验证 DNS 响应。 AD 位可能未设置，因为未尝试验证，或者因为验证失败。
CD：CD 位包含在 DNS 查询中，是“checking disabled”的缩写。如果在查询中设置了 CD 位（），CD=1则意味着无论验证是否成功执行，都应该发送 DNS 响应。如果未设置 CD 位（），CD=0则在需要验证但验证失败时，不会发送 DNS 响应。如果 CD 位是清零的（），CD=0则意味着“已启用检查”，并且可以进行 DNSSEC 验证。 CD 位可能在查询中设置（CD=1），因为主机能够执行 DNSSEC 验证，并且不需要上游验证，例如运行 Windows Server 2012 或更高版本的递归 DNS 服务器。非验证存根解析程序（如运行 Windows DNS 客户端的计算机）会在 CD 位清除的情况下发出查询 CD=0。有关更多信息，请参见 RFC4035，第 3.2.2 节。

DNS 数据包报头中可以存在的第四个重要标志（位）是 AA 位。此标志不是 DNSSEC 的新功能，但可以在部署 DNSSEC 时使用：

AA：AA 位包含在 DNS 响应中，是“权威答案”的缩写。如果设置了 AA 位，则意味着 DNS 响应是真实的，因为它直接来自权威 DNS 服务器。需要 DNSSEC 验证的客户端（）AD=1 接受 AA 位（AA=1， AD=0）。如果客户端直接查询权威服务器，因为不需要验证权威响应。权威服务器验证自己的响应是多余的。

DNS 查询示例

以下示例显示了使用 Resolve-DnsName cmdlet 从运行 Windows 8.1 的 DNS 客户端计算机执行的 DNS 查询结果。 Resolve-DnsName cmdlet 是在 Windows Server 2012 和 Windows 8 中引入的，可用于显示包含 DNSSEC 数据的 DNS 查询。

重要

请勿使用 nslookup.exe 命令行工具测试区域对 DNSSEC 的支持。该工具 nslookup.exe 使用无法识别 DNSSEC 的内部 DNS 客户端。

示例 1：在以下示例中，向递归 DNS 服务器发送查询，以获取签名区域中的地址（A）记录 secure.contoso.com。DO=0

Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com


Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

未设置 DO 位，因为未包含 dnssecok 参数。

示例 2：在以下示例中， DO=1 通过添加 dnssecok 参数来设置标志。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

当 DO=0时，DNS 服务器不会在 DNS 回复中发送 DNSSEC 数据。当 DO=1时，客户端指示它能够接收 DNSSEC 数据（如果可用）。 secure.contoso.com由于区域已签名，因此 RRSIG 资源记录包含在 DNS 响应中DO=1。

在示例 1 和示例 2 中，区域都 secure.contoso.com 不需要验证，因为名称解析策略表（NRPT）未配置为需要验证。

可以使用 Get-DnsClientNrptPolicy cmdlet 查看当前的 NRPT 规则。有关更多信息，请参阅 Get-DnsClientNrptPolicy。

示例 3：在以下示例中，显示了 secure.contoso.com的 NRPT 规则。

Get-DnsClientNrptPolicy

Namespace : .secure.contoso.com

QueryPolicy :

SecureNameQueryFallback :

DirectAccessIPsecCARestriction :

DirectAccessProxyName :

DirectAccessDnsServers :

DirectAccessEnabled :

DirectAccessProxyType : NoProxy

DirectAccessQueryIPsecEncryption :

DirectAccessQueryIPsecRequired : False

NameServers :

DnsSecIPsecCARestriction :

DnsSecQueryIPsecEncryption :

DnsSecQueryIPsecRequired : False

DnsSecValidationRequired : False

NameEncoding : Utf8WithoutMapping

在此示例中， DnsSecValidationRequired 的值为 False。当值为 false 时，不需要 DNSSEC 验证。

示例 4：为启用 secure.contoso.comDNSSEC 验证后，NRPT 对 DnsSecValidationRequired 显示 True。此示例仅显示 secure.contoso.com 命名空间和 DnsSecValidationRequired 参数。

(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired

True

如果 DnsSecValidationRequired 的值为 True ，则可识别 DNSSEC 的客户端计算机始终使用 DO=1发送查询，即使不包含 dnssecok 参数也是如此。

示例 5：当名称解析策略表（NRPT）中需要 DNSSEC 验证时，会自动为可识别 DNSSEC 的客户端设置 DNSSEC OK 位（DO=1）。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

在此示例中，在 DNS 响应中发送 RRSIG 记录，以满足的验证要求 secure.contoso.com。在递归 DNS 服务器上 dns1.contoso.com还配置了有效的信任锚点。

如果 DNS 客户端无法识别 DNSSEC，则 NRPT 规则不适用，并且查询是使用 DO=0发送的，即使存在需要 DNSSEC 验证的 NRPT 规则也是如此。

示例 6：在以下示例中，执行与示例 5 中相同的查询，但没有在上配置 dns1.contoso.com有效的信任锚点。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet

At line:1 char:1

+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti

on

+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName

在此示例中，DNS 解析失败，并显示消息 DNS_ERROR_UNSECURE_PACKET。解析失败，因为 NRPT 中需要验证，但由于区域缺少有效的信任锚 secure.contoso.com点而无法执行。 Resolve-DnsName cmdlet 报告所遇到的故障类型的详细结果。如果 DNS 客户端尝试解析 finance.secure.contoso.com 以连接到此主机，则会失败。

DNSSEC 场景

DNSSEC 可以部署在许多不同的环境中，具有独特的服务器和客户端设置，了解 DNS 查询和响应如何受到影响非常重要。

请考虑以下四个与 DNSSEC 相关的语句。每个声明都会影响 DNSSEC 在给定场景中的工作方式：

finance.secure.contoso.com资源记录已使用 DNSSEC 正确签名。
递归 DNS 服务器能够验证对 .finance.secure.contoso.com
DNS 客户端可识别 DNSSEC。
DNS 客户端配置为要求对命名空间中的所有 secure.contoso.com 查询进行验证。

让我们更详细地考虑这四个语句中的每一个。

DNSSEC 签名状态：DNSSEC 对区域中的所有记录进行签名，此条件是指区域的状态 secure.contoso.com ，而不仅仅是 finance.secure.contoso.com 资源记录。您不能在签署某些记录的同时不签署其他记录。因此，的 finance.secure.contoso.com DNSSEC 状态取决于的 DNSSEC 状态 secure.contoso.com。
- Signed correctly： secure.contoso.com 区域可以以有效的方式签名，从而可以 finance.secure.contoso.com 验证为真实区域。要有效，必须使用有效、未过期的密钥对区域进行签名，并且必须存在所有必需的 DNSSEC 相关资源记录。
- 未签名： secure.contoso.com 区域可能未签名，在这种情况下，没有与 finance.secure.contoso.com关联的 RRSIG 记录，并且无法验证对查询的 finance.secure.contoso.com DNS 响应。如果客户端需要验证，则发送到递归 DNS 服务器的 DNS 查询将失败，因为 DNS 客户端不接受未经验证的响应。如果客户端直接查询权威服务器，则不会通过验证，因为响应已被视为真实响应。
- 未正确签名： secure.contoso.com 区域可能已签名，但未以有效方式签名。例如，一个或多个 DNSSEC 签名密钥可能已过期。在您最初对区域进行签名后，必须在签名密钥有效期到期之前定期使用新密钥对区域进行重新签名，以保持安全的 DNSSEC 运行状态。 DNSSEC 签名密钥的有效期应足够短以维护安全性，但又应足够长以便于管理。 Windows Server 2012 和 Windows Server 2012 R2 中的 DNSSEC 支持自动密钥滚动更新，为您的 DNSSEC 签名区域提供安全性和易管理性。
验证状态：具有区域的有效信任锚（公有加密密钥） secure.contoso.com 的递归 DNS 服务器能够验证资源记录的 finance.secure.contoso.com DNS 响应。递归 DNS 服务器还必须支持用于对区域进行签名的 DNSSEC 标准和算法。
- 可以验证：如果递归 DNS 服务器支持用于对区域进行签名 secure.contoso.com 的所有加密算法，并且它具有可用于解密与已签名资源记录关联的 DNSSEC 签名的有效信任锚，则它可以验证 finance.secure.contoso.com 资源记录是否为真实。
- 无法验证：非 DNSSEC 感知 DNS 服务器无法进行验证。同样，当前没有区域 secure.contoso.com的有效信任锚点的 DNS 服务器无法验证的 DNS 响应 finance.secure.contoso.com。在重新签名区域时（例如，在密钥滚动更新期间），必须更新信任锚点。 Windows Server 2012 和 Windows Server 2012 R2 中的 DNSSEC 支持根据 RFC 5011“自动更新 DNS 安全（DNSSEC）信任锚点”在密钥滚动更新时自动更新信任锚点。
DNSSEC 感知状态：DNS 客户端的 DNSSEC 感知状态取决于它运行的作系统。 Windows 7 或 Windows Server 2008 R2 及更高版本作系统中的 Windows DNS 客户端服务是 DNSSEC 感知的非验证存根解析程序。以前的 Windows作系统无法识别 DNSSEC。 DNS 客户端在发送 DNS 查询时通知 DNS 服务器它是否能够识别 DNSSEC。
- 客户端和服务器都可识别 DNSSEC：如果客户端和服务器都可识别 DNSSEC，则从服务器到客户端的 DNS 响应包括 DNSSEC 身份验证数据（AD）标志。如果 DNS 响应已使用 DNSSEC 验证，则 AD=1 发送。如果 DNS 响应未经过验证，则 AD=0 发送。
- DNS 服务器无法识别 DNSSEC：如果 DNS 服务器无法识别 DNSSEC，则不执行验证，并且无论 DNS 客户端是否支持 DNSSEC，都不会设置 AD 标志（AD=0）。
- DNS 客户端无法识别 DNSSEC：如果 DNS 客户端无法识别 DNSSEC，则 DNS 服务器不会在对客户端的响应中设置 AD 标志，即使它理解 DNSSEC。但是，如果 DNS 服务器可识别 DNSSEC，并且具有区域的信任锚，则服务器会尝试验证来自权威服务器的响应。如果验证失败，它将向 DNS 客户端返回 DNS 服务器故障。如果验证成功，它将查询结果返回给客户端。通过这种方式，DNSSEC 感知递归 DNS 服务器可以保护非 DNSSEC 感知 DNS 客户端。在这种情况下，如果区域未签名，则不会尝试验证，并且响应将正常返回给客户端。
验证要求：此设置确定 DNSSEC 感知 DNS 客户端对来自 DNS 服务器的响应中 DNSSEC 数据（AD 标志）的要求。为了使 DNS 客户端需要验证，它必须是 DNSSEC 感知的。不能强制非 DNSSEC 感知 DNS 客户端要求 DNSSEC 验证。如果 DNS 客户端直接查询权威 DNS 服务器，则即使区域未签名，也会验证响应。这是因为权威 DNS 服务器始终返回真实的响应。
- 需要验证：如果需要验证，则客户端必须接收 AD=1 （验证成功）或拒绝 DNS 响应。如果验证不成功或未尝试（），AD=0则 DNS 解析失败。即使区域未签名，也是如此。这仅适用于针对递归、非权威 DNS 服务器的查询。
- 不需要验证：如果不需要验证，则客户端将接受来自非 DNSSEC 感知递归 DNS 服务器的响应。但是，如果递归 DNS 服务器可识别 DNSSEC 并且验证失败，则即使客户端不需要验证，它也会将服务器故障转移返回给客户端。

后续步骤

以下是一些文章，可了解有关 DNS 服务器的 DNSSEC 的更多信息。