企业合并或收购完成后，IT基础设施整合通常被划分为网络、存储、身份认证、邮件和业务系统几个板块，DNS却容易被放在最后甚至被忽略。实际上，DNS位于所有访问链路的最前端，一旦解析策略混乱，用户可能无法登录邮箱、无法访问内部OA、无法完成单点登录跳转，甚至连域控之间的复制都会受到影响。制定DNS整合计划的核心任务是先明确新旧域名如何共存、如何迁移、如何委派，再通过控制TTL和分阶段切换把业务中断时间降到最低。
合并场景下的DNS整合并不是简单地把两台DNS服务器停掉一台，或者把所有区域记录手工复制一遍。它涉及外部公共域名、内部AD域名、云上私有区域、分支机构本地解析以及上下游转发关系之间的协同。一个完整的整合计划需要从审计现有环境开始，逐步形成目标架构，再通过并行运行和灰度切换完成最终收敛。
一、合并收购场景下的DNS整合挑战
两家企业完成合并后，最常见的问题是命名空间重叠。例如A公司内部域名为corp.a.com，B公司内部域名为corp.local，如果直接合并到同一套DNS体系，可能会出现相同主机名指向不同IP、相同区域名称包含不同记录、内部域名与外部注册域名不一致等情况。尤其是后缀为.local的旧式AD域名，在解析外部资源时容易与mDNS产生冲突，需要结合实际情况决定是否保留、重命名还是通过条件转发隔离。
区域委派关系复杂是另一个难点。大型企业通常会按照组织单元或地理位置拆分DNS区域，例如总部DNS向分支DNS委派子域，或者上级域控向子域控委派_msdcs区域。合并后如果委派关系没有重新梳理，解析请求可能被旧DNS服务器错误应答，或者因为原DNS服务器下线导致整个子域无法解析。此时不能只关注A记录和CNAME记录，还要重点检查NS记录、SOA记录、SRV记录以及胶水记录是否完整。
TTL缓存带来的延迟也不可忽视。很多业务系统在迁移前几分钟才修改解析记录，但旧记录可能已经在本地DNS缓存、浏览器缓存或运营商递归解析器中存留了数小时甚至数天。合并项目中如果直接切换IP而不提前降低TTL，就会出现一部分用户访问新系统、一部分用户仍然访问旧系统的割裂状态。更隐蔽的是AD客户端会缓存SRV记录，导致域控切换后客户端仍然向旧域控发起LDAP或Kerberos请求。
二、DNS整合计划的关键步骤与架构设计
第一步是资产盘点与区域审计。需要从原公司和被收购公司分别导出所有DNS区域、记录类型、权威服务器列表、转发器配置以及域名注册信息。Windows环境可以使用PowerShell导出区域和记录，BIND环境则可以直接读取named.conf和区域文件。审计过程中要区分三类区域：公共权威区域、内部解析区域、AD集成区域。公共权威区域由注册商或云DNS托管，内部解析区域由内部DNS服务器承担，AD集成区域通常与域控紧密绑定。
# 导出Windows DNS服务器上的所有区域 Get-DnsServerZone | Select-Object ZoneName,ZoneType,IsDsIntegrated | Export-Csv -Path C:\dns-audit\zones.csv -NoTypeInformation # 导出指定区域的所有记录 Get-DnsServerResourceRecord -ZoneName "corp.a.com" | Export-Csv -Path C:\dns-audit\corp-a-records.csv -NoTypeInformation
第二步是确定命名空间策略。常见方案有三种：保留收购方域名、保留被收购方域名、启用全新统一域名。如果业务系统不强依赖内部域名，最稳妥的做法是保留双方现有域名，通过DNS转发和条件转发实现互相解析，待应用层迁移完成后再逐步废弃旧域名。不要在项目初期就强行统一域名，因为AD域重命名、邮箱域名切换、证书更新和第三方SaaS回调地址变更都会产生大量不可控风险。
第三步是设计转发与委派拓扑。假设A公司为存续主体，A公司DNS作为主解析入口，B公司DNS先保持运行。A公司DNS上配置指向B公司DNS的条件转发，例如将b.com区域转发到B公司原DNS服务器；B公司DNS上配置指向A公司DNS的条件转发，实现双向解析。对于外部用户访问，可以在云DNS或注册商处同时保留两条NS委派，内部切换时只需修改A记录，不涉及域名注册变更。
区域迁移应优先选择区域传送或标准导出导入，而不是手工逐条重建。BIND环境下可以通过AXFR/IXFR进行区域传送，Windows DNS则支持主区域到辅助区域的复制。对于AD集成区域，不能直接复制文件，需要在新域控上创建相同区域并等待AD分区复制，或使用dnscmd工具进行区域导入。
# 使用dig验证区域传送是否正常 dig @old-dns.b.com b.com AXFR # 使用nslookup验证条件转发结果 nslookup app.b.com new-dns.a.com
迁移前必须提前降低关键记录的TTL。建议在正式切换前至少一个TTL周期就完成调整，例如原TTL为86400秒，应提前24到48小时将TTL降至300秒。这样即使切换过程中出现问题，也能快速改回原记录并让解析快速生效。对于AD内部的SRV记录，TTL默认较短，但仍建议在域控切换前通过组策略或DNS管理工具确认客户端能够及时感知新的域控地址。
三、迁移实施与风险控制
实施阶段应采用分区域、分记录类型的灰度切换。先迁移非关键的测试区域或低风险CNAME记录，观察递归解析器、邮件网关和反向代理的解析行为是否正常；再迁移主要业务系统的A记录；最后处理MX记录、TXT记录和SRV记录。邮件系统尤其需要谨慎，因为MX记录切换涉及垃圾邮件策略、SPF、DKIM和DMARC验证，如果新旧邮件网关同时在线，还需要确认反向解析PTR记录是否已经更新。
并行运行是降低切换风险的有效手段。切换过程中保持旧的DNS服务器继续存活，即使新DNS服务器已经接管部分区域，旧服务器仍能作为辅助区域或转发目标响应查询。对于关键业务系统，可以在新DNS中临时保留旧IP作为备用记录，或者通过负载均衡设备同时代理新旧地址。监控解析日志和查询失败率，重点关注NXDOMAIN、SERVFAIL和超时错误。
回滚方案必须提前写入变更计划。如果切换后发现大量业务无法解析，应立即将所有区域的SOA记录切回旧DNS服务器，并将TTL恢复到较低值。对于云DNS场景，回滚通常只需在控制台修改NS记录或A记录，但由于公共DNS传播存在延迟，回滚生效时间可能比TTL显示的时间更长。变更前务必保留完整的旧配置导出文件，包括区域文件、转发器列表、条件转发配置和防火墙规则。
# 检查递归解析结果和权威响应 dig +noall +answer app.a.com @8.8.8.8 dig +noall +authority +answer app.a.com @new-dns.a.com # 批量测试解析连通性 for host in mail.a.com portal.a.com sso.a.com; do getent hosts $host || echo "failed: $host" done
DNSSEC配置在合并场景下容易被遗漏。如果原域名已经启用DNSSEC，迁移前需要确认新DNS服务器是否支持相同的签名算法，并同步更新DS记录。如果新托管平台不支持原有算法，可能导致域名被递归解析器判定为验证失败，所有依靠该域名的服务都会中断。建议在迁移窗口前单独验证DNSSEC链，不要在切换业务记录的同时变更签名策略。
四、Active Directory与云DNS的整合要点
AD环境中的DNS区域与普通区域有本质区别。域控注册的SRV记录、_ldap、_kerberos、_gc等记录是域成员定位域控、执行复制和身份认证的基础。合并收购后如果涉及AD域林信任或域迁移，DNS整合必须与AD信任关系同步推进。例如A公司与B公司建立林信任前，需要确保双方DNS能够互相解析对方的SRV记录，否则信任验证会失败。可以配置条件转发指向对方域控，或者在双方DNS上创建辅助区域来复制AD集成区域。
云DNS在合并后通常承担外部公共解析和内网私有区域的混合角色。Azure DNS、AWS Route 53或者阿里云DNS都可以托管公共权威区域，同时提供私有区域用于VPC或虚拟网络内部解析。如果两家公司分别使用不同云平台，短期内不必强制统一，可以通过公共区域的NS委派和私有区域的转发规则逐步收敛。例如在Azure私有DNS中创建指向AWS Route 53入站端点的条件转发，使云主机能够解析对端云中的内部服务名称。
混合DNS架构中要特别注意解析优先级。Windows客户端会优先查询自己的主DNS服务器，如果主DNS无法解析，再尝试辅助DNS。很多合并项目在客户端网络切换时只修改了主DNS，辅助DNS仍然指向旧服务器，导致主DNS短暂故障时解析被旧服务器劫持。建议将新旧DNS统一纳入同一套转发体系，旧DNS只作为转发器角色存在，不再保留任何权威区域，避免出现双侧权威数据不一致。
# 在Windows DNS上配置条件转发器
Add-DnsServerConditionalForwarderZone -Name "b.com" -MasterServers 10.10.20.53,10.10.20.54 -PassThru
# 查看条件转发器状态
Get-DnsServerZone | Where-Object {$_.ZoneType -eq "Forwarder"} | Select-Object ZoneName,MasterServers
最终收敛阶段应当制定域名退役计划。旧域名在业务系统全部迁出后才能下线，退役前至少保留一个只读的辅助区域，并持续观察三个月以上。对于外部公共域名，建议保留旧域名解析至统一跳转页或自动重定向服务，避免合作伙伴、客户和搜索引擎缓存长时间无法访问。内部旧域名则可以在所有客户端DNS配置更新完毕后，通过防火墙限制旧DNS服务器的入站查询，观察无异常后再正式关闭。
DNS整合计划的成功与否，不只是技术层面的解析连通性，更取决于对业务访问链路的完整梳理。只要在切换前完成充分审计、提前降低TTL、保留并行运行能力，并为每个区域准备独立的回滚方案，合并收购中的DNS迁移就可以做到用户无感知、业务无中断。