DNSSEC需权威服务器签名、递归服务器配置信任锚、客户端通过NRPT强制验证三者协同：签名生成DNSKEY/RRSIG/DS记录，递归服务器导入信任锚并验证，客户端启用DNSSEC策略确保响应真实可信。
dnssec 不是开启一个开关就能生效的功能，它需要在权威服务器、递归解析器和客户端三个层面协同配置。核心在于让 dns 响应能被密码学验证，防止缓存污染和中间人篡改。整个过程围绕“签名—分发—验证”闭环展开。
对 DNS 区域执行签名操作
这是 DNSSEC 部署的第一步，必须在权威 DNS 服务器（如 Windows Server 的 DNS 服务）上完成。签名会自动生成并添加几类关键资源记录：DNSKEY（存放公钥）、RRSIG（每条记录的数字签名）、DS（父区用于验证子区公钥的摘要）。操作路径为：DNS 管理控制台 → 右键目标正向查找区域 → “DNSSEC” → “签署此区域”。系统会引导你选择密钥算法、密钥长度和签名策略。注意：签名后所有记录（A、MX、CNAME 等）都会附带 RRSIG，但客户端默认不会请求这些记录，需递归服务器显式要求。
在递归 DNS 服务器上配置信任锚
递归服务器（例如企业内部的 DNS 缓存服务器）必须知道从哪里开始信任——这个起点就是“信任锚”，通常是根区或父区的 DNSKEY 或 DS 记录。Windows Server DNS 支持手动导入信任锚：打开 DNS 管理器 → 右键服务器名称 → “属性” → “Trust Anchors” 选项卡 → 点击“添加”。可导入根区的 DNSKEY（标准做法），也可导入你所管理子域的 DS 记录（适用于私有 DNS 树）。导入后，该服务器收到对已签名区域的查询时，会自动请求并验证 DNSSEC 相关记录；若验证失败（如签名过期、哈希不匹配），则返回 SERVFAIL 而非错误数据。
通过 NRPT 强制客户端执行 DNSSEC 验证
即使递归服务器支持验证，普通 Windows 客户端默认并不检查响应是否经过 DNSSEC 签名。要确保关键业务域名（如 corp.internal、bank.example.com）的解析强制验证，需配置名称解析策略表（NRPT）。使用组策略（GPO）或 PowerShell 设置 NRPT 规则：
- 指定命名空间：可选“后缀”（如 .contoso.com）、“FQDN”（如 dc1.contoso.com）等；
- 启用“启用 DNSSEC”选项；
- 可选勾选“要求验证”——这会让客户端拒绝未通过验证的响应；
- 若策略应用于域环境，建议链接到域 GPO 并刷新客户端组策略（gpupdate /force）。
验证部署是否生效
部署完成后不能仅凭界面判断。推荐组合使用以下方式确认：
- 在客户端执行 nslookup -debug example-signed-domain.com，查看响应中是否包含 ad 标志（authenticated data）；
- 使用在线工具如 dnsviz.net 或 dnssec-analyzer.verisignlabs.com 输入域名，获取可视化验证链报告；
- 在递归服务器上启用 DNS 日志（事件查看器 → DNS Server → Analytic 日志），筛选 DNSSEC 验证失败事件（ID 706）或成功日志（ID 700）；
- 尝试人为干扰响应（如伪造 RRSIG），观察是否触发 SERVFAIL，这是最直接的安全性验证。
