Windows DNS 遮蔽公网域名解析
1. 问题现象
公司内网环境中，部分域名（如 <managed-domain>）的公网权威解析已托管至第三方云 DNS 服务商（国科云、阿里云）。内网客户端访问此类域名时，若未在自建 Windows DNS 服务器上手动添加对应的公网解析记录，访问将失败，浏览器典型报错为「无法访问此网站」或「找不到服务器 IP 地址」（ERR_NAME_NOT_RESOLVED / DNS_PROBE_FINISHED_NXDOMAIN）。
2. 环境背景
| 组件 | 配置情况 |
|---|---|
| 内网 DNS | 自建 Windows Server DNS（域控/成员服务器），作为内网客户端的唯一/首选 DNS |
| 正向查找区域 | 本地托管了 <managed-domain> 等多个主区域（多因 AD 域控或内部业务系统解析需要而创建） |
| 转发器 | 配置了公共 DNS（114.114.114.114、119.29.29.29 等），用于处理非本地管辖域名的递归解析 |
| 公网侧 | <managed-domain> 的实际解析记录（网站、邮箱等）托管于国科云、阿里云的权威 DNS |
3. 根因分析
Windows DNS Server 的查询处理优先级（从高到低）：
- 本地区域数据（主区域/AD 集成区域/存根区域）——以**权威应答（Authoritative Answer）**方式直接回复
- 条件转发器（Conditional Forwarder）
- 转发器（Forwarder，递归查询）
- 根提示（Root Hints，迭代查询）
根本原因：本地权威区域对解析请求产生"遮蔽效应"（Zone Shadowing）。
只要服务器对某域名持有主要区域，它即认定自身为该域的权威服务器，所有命中该区域（含全部子域）的查询都会在本地数据库内终结，绝不会转向转发器或根提示。故障触发链如下：
- 客户端向内网 DNS 发起
www.<managed-domain>的解析请求； - 服务器按最大匹配原则命中本地区域
<managed-domain>，进入权威应答模式； - 仅检索本地区域数据库，未找到
www记录，本地查询失败； - 关键断点：由于服务器认定自己是权威，不会将请求转发至外部转发器（如 114 DNS），也不会向公网发起递归/迭代查询；
- 服务器直接向客户端返回 NXDOMAIN（RCODE=3，域名不存在）或空应答，客户端访问失败。
关键结论：转发器与根提示仅对「服务器不具权威性」的域名生效。即使为
<managed-domain>配置了条件转发器，只要同名主区域仍然存在，本地区域始终优先，转发规则永远不会被触发——这也是方案二必须先删除/迁移本地区域的原因。
4. 解决方案
4.1 方案一：手动镜像公网记录（应急恢复，适用于记录极少）
操作方法：在 <managed-domain> 本地区域内，手动创建与公网完全一致的 A/CNAME 记录（以内网 DNS 服务器执行 nslookup www.<managed-domain> 223.5.5.5 获取的公网真实记录为准）。
- 优点：立即生效，完全可控；可实现内外网差异化解析（例如内网解析至专线或内网负载均衡地址）。
- 缺点：双重维护、数据易漂移；公网记录变更后若未同步，将再次引发故障，且无任何自动变更提醒机制。
4.2 方案二：配置条件转发器（中期优化，适用于内网记录较少）
适用场景：域名在公网有大量记录，内网仅需解析极少数特定子域名（如域控 dc01.<managed-domain>）。
操作步骤：
- 全面梳理并导出本地区域中仍在内网使用的记录（
Get-DnsServerResourceRecord或dnscmd /zoneprint）； - 在公网权威侧（阿里云/国科云）补齐仍需内网可见的记录；
- 删除本地主区域
<managed-domain>（若该区域承载 AD 域信息，须先行迁移_msdcs、DC 的 SRV 等记录，切勿直接删除）； - 为纯内网使用的子域名单独创建小区域（如创建
dc01.<managed-domain>区域）； - 新建条件转发器：域名填
<managed-domain>，目标 DNS 填公网权威 NS 地址或公共 DNS（如 223.5.5.5）。
- 优点：大幅降低维护成本；除内网指定子域名外，其余请求自动转发至公网查询，与公网记录保持实时一致。
- 缺点：前提是必须准确梳理出哪些子域名为纯内网使用。
变体方案——存根区域（Stub Zone）：以公网权威 NS 为主服务器创建存根区域，通过 NS 引导解析。对权威 NS 变更较为敏感，一般优先推荐条件转发器。
4.3 方案三：拆分命名空间（长期最佳实践 ★）
从架构根源上消除内外网域名冲突（Split-DNS 架构反模式规避）。
操作方法：内网业务及 AD 域不再复用公网域名：
公网使用：
<managed-domain>内网使用：
internal.<managed-domain>、corp.<managed-domain>优点：内外网 DNS 命名空间物理隔离，彻底消除权威遮蔽问题，符合微软 Active Directory 部署的最佳实践。
缺点：对已有大量历史业务的老域名，迁移成本较高，需分阶段推进（双解析过渡 → 流量切换 → 下线旧区域）。
方案对比
| 方案 | 生效速度 | 维护成本 | 改动范围 | 适用阶段 |
|---|---|---|---|---|
| 手动镜像记录 | 立即 | 高（需持续同步） | 仅新增记录 | 应急恢复 |
| 条件转发器 | 中期 | 低（一次性配置） | 删区域+建转发 | 中期优化 |
| 拆分命名空间 | 慢 | 长期最低 | 架构级调整 | 长期规划 |
5. 验证与排障步骤
服务端验证：
# 模拟客户端向内网 DNS 查询
Resolve-DnsName www.<managed-domain> -Server <internal-dns-ip>
# 通过公共 DNS 获取公网真实记录及权威 NS
Resolve-DnsName www.<managed-domain> -Server 223.5.5.5
Resolve-DnsName <managed-domain> -Type NS -Server 223.5.5.5
# 清除 DNS 服务器端缓存（旧版系统可用 dnscmd /clearcache）
Clear-DnsServerCache -ComputerName <dns-server-name> -Force
客户端验证：
ipconfig /flushdns
nslookup www.<managed-domain>
判定依据：若 nslookup 应答服务器为内网 DNS 且返回 NXDOMAIN，而同一记录经公共 DNS 查询正常，即可确认命中「本地权威遮蔽」故障。
6. 后续行动建议
- 短期：对当前无法访问的域名，按方案一在 Windows DNS 中补齐记录，清除缓存后恢复业务访问。
- 中期：盘点
<managed-domain>等冲突域名的内网使用面，对「内网记录少」的域名实施方案二（条件转发），降低运维负担。 - 长期：规划命名空间拆分，从架构上杜绝此类问题复发。
- 客户端纪律：网卡 DNS 必须仅指向内网 Windows DNS，严禁同时混配公网 DNS（如 114.114.114.114），否则会导致 AD 域登录超时或解析结果随 DNS 顺序随机漂移。