4. 本地DNS基础设施评估

在混合云DNS与跨域解析工程中，本地DNS基础设施评估是决定后续架构走向的关键前置工作。很多跨域解析故障并非出在Route 53或云侧解析器，而是本地DNS的转发链、条件转发器或域控制器委派关系早已存在隐性缺陷。本节的目标是建立一份可执行的本地DNS资产与配置清单，覆盖三类核心对象：企业自建BIND服务器、Windows DNS服务器（含域控制器角色）、以及各类转发器与条件转发器配置。

一、评估范围与对象分类

本地DNS基础设施通常由以下角色构成，评估时需逐一识别并记录其解析职责：

• 递归解析器：面向终端或应用提供递归查询，常见为BIND 9、Unbound、Windows DNS Server。
• 权威服务器：托管企业内网域（如 corp.example.com）或反向区（in-addr.arpa），可能由BIND或Windows DNS承载。
• 域控制器（AD DS）：Windows域控同时承担AD集成DNS区，是AD域内SRV记录、Kerberos认证解析的核心。
• 转发器与条件转发器：将特定域或全部未知查询转发至上游，是混合云解析的“接缝点”。
• 存根区域与委派：用于将子域解析权交给云侧或另一套DNS。

评估的第一步不是改配置，而是“看清现状”。建议以“服务器—区域—转发策略—上游依赖”四个维度建立台账，避免只记录IP而忽略解析路径。

二、BIND服务器的梳理要点

对BIND服务器，重点检查 named.conf 中的 options、zone、forwarders 与 forward 指令。典型配置片段如下：

options {
    directory "/var/named";
    recursion yes;
    allow-query { 10.10.0.0/16; 10.20.0.0/16; };
    forwarders { 10.10.0.53; 10.10.1.53; };
    forward only;
};

zone "corp.example.com" IN {
    type master;
    file "corp.example.com.zone";
};

zone "aws.example.com" IN {
    type forward;
    forwarders { 172.31.0.2; };
};

这里需要特别关注两点：一是 forward only 与 forward first 的差异，前者在转发器不可用时直接失败，后者会回退到根迭代；二是条件转发器 zone "aws.example.com" 是否与云侧Route 53私有托管区名称完全一致。名称不一致是跨域解析失败的高频原因。

此外，应记录BIND版本、是否启用DNSSEC验证、allow-transfer 限制、以及日志中 query-errors 与 lame-servers 的出现频率。这些数据能反映现有解析链的健康度。

三、Windows DNS与域控制器的梳理要点

Windows环境需区分“DNS服务器角色”与“域控制器角色”。在域控上，AD集成区默认存储在 CN=MicrosoftDNS,DC=DomainDNSZones,DC=corp,DC=example,DC=com 下，复制范围可能是“所有域控”或“所有DNS服务器”。评估时应使用以下命令导出关键信息：

Get-DnsServerZone | Select ZoneName, ZoneType, IsDsIntegrated, ReplicationScope
Get-DnsServerForwarder
Get-DnsServerConditionalForwarderZone
Get-DnsServerZone | Where-Object {$_.IsReverseLookupZone} | Select ZoneName

重点判断：条件转发器是否指向云侧DNS（如Route 53 Resolver Inbound Endpoint的IP）；是否存在“转发器指向自己”的环路；AD集成区的复制范围是否覆盖所有需要解析的站点。若企业有多个AD站点，还需检查站点内DNS服务器是否都配置了相同的条件转发器，否则会出现“部分客户端能解析、部分不能”的典型现象。

四、转发器配置的评估方法

转发器是本地DNS与云DNS之间的桥梁。评估时建议按“域—目标—协议—超时—回退”五要素记录。例如：

评估中要特别警惕“默认转发器覆盖条件转发器”的优先级问题。在BIND中，更具体的 zone 条件转发优先于全局 forwarders；在Windows DNS中，条件转发器优先于服务器级转发器。若配置顺序或作用域理解错误，云侧域名可能被错误地转发到本地上游，导致解析到错误IP或超时。

五、解析路径可视化与验证

完成清单后，应绘制一张“客户端—本地DNS—转发器—云侧解析器”的解析路径图，并标注每个节点的查询类型与失败点。下图给出一个典型的混合云解析路径评估示意，用于对照实际环境逐段验证。

验证时建议使用 dig +trace、nslookup -debug 或 Resolve-DnsName -Server 逐段确认。例如，在客户端执行 nslookup aws.example.com 10.10.0.53，若返回SERVFAIL，再在本地DNS上执行 dig @172.31.0.2 aws.example.com，即可判断问题出在本地转发还是云侧解析器。若云侧正常而本地失败，通常指向条件转发器未生效或防火墙未放行UDP/TCP 53。

六、评估输出物建议

本节最终应形成一份可交接的评估成果，至少包含：DNS服务器资产表（主机名、IP、角色、版本）、区域与转发策略表（域名、类型、目标、优先级）、解析路径图、以及已知风险清单（如单点转发器、无回退、AD复制范围不足）。这份成果将直接作为后续Route 53 Resolver规则、出站终端节点和条件转发设计的输入依据。只有把本地DNS的“家底”摸清，跨域解析工程才不会在割接当晚才暴露隐藏的转发环路或域名不一致问题。