AD集成DNS区域数据直接存储在域控制器的ntds.dit数据库中，与用户、计算机对象同属AD目录；其依赖AD多主复制同步，不使用AXFR/IXFR文件传输，SRV记录必须由AD集成区域动态注册，且仅支持Kerberos认证的安全动态更新。

AD集成DNS区域到底把数据存在哪儿

它不存文件，而是直接写进ntds.dit——也就是域控制器的ad数据库。这意味着dns记录和用户、计算机对象一样，是ad目录的一部分，不是独立服务。你删掉一台dc上的dns服务，只要ad数据库还在，记录就还在；反过来，如果ad复制没完成，哪怕dns服务重启了，也看不到新记录。

• 传统主/从DNS靠AXFR/IXFR传文件，有单点风险；AD集成区域靠AD多主复制同步，所有DC DNS服务器读的是同一份权威源
• SRV记录（比如_ldap._tcp.dc._msdcs.contoso.com）必须由AD集成区域动态注册，非集成区域无法自动更新——客户端加域、登录、查GC全靠它
• 安全动态更新只认Kerberos票据，普通客户端不能随便改A记录；非集成区域开DDNS等于裸奔

为什么改完记录要等几分钟才生效

因为DNS服务默认每5分钟轮询一次AD数据库，不是实时监听。AD复制完成了≠DNS加载完成了。你看到repadmin /replsummary显示“成功”，但nslookup _kerberos._tcp.contoso.com可能还是旧结果。

• 手动立即加载：在目标DC上运行dnscmd /zoneupdatefromds contoso.com（替换为你的区域名）
• 调快轮询频率：dnscmd /config dspollinginterval 60（最小30秒），注意这只是本机DNS服务读AD的节奏，不影响AD本身复制延迟
• 别漏掉：这个操作只对AD集成区域有效；转发器、根提示、条件转发这些配置不在AD里，不参与同步

非集成区域真不能用？什么时候会踩坑

能用，但会断掉域核心功能。比如把DC的DNS指向一个非AD集成的Linux BIND服务器，它查不到_msdcs子域下的SRV记录，客户端加域失败、组策略不刷新、Kerberos预认证报错0x12——全是DNS找不到KDC惹的祸。

• 常见误操作：在DC上卸载DNS角色后重装，忘了勾选“存储该区域于Active Directory中”
• 迁移场景下可转出：用dnscmd /zoneresettype contoso.com /primary转成标准主区域，生成ASCII文件供BIND使用，但从此失去动态注册和ACL控制
• 混合环境要注意：非Windows客户端（如Linux加入域）依赖net ads join自动注册A+PTR，这一步在非集成区域会静默失败

备份DNS服务器为啥长期不同步

因为AD集成区域不走AXFR，备份DNS如果不是域控制器，压根没法从AD读数据。它只能作为转发器或缓存服务器存在，不是真正意义上的“备份DNS服务器”。

• 如果你配了一台非DC的Windows Server跑DNS，并设为“辅助区域”，它永远收不到AD集成区域的变更——辅助区域只支持文件式区域的传送
• 正确做法：所有权威DNS服务器都应是域控制器；非DC机器只能做条件转发器，或者用dnscmd /resetforwarders统一指向上游DC
• 最隐蔽的坑：某些网络设备（防火墙、负载均衡器）内置DNS代理，缓存了旧SRV记录，清空设备DNS缓存比改DC还关键

AD集成DNS不是“DNS加了个AD插件”，它是把DNS从网络服务降级为目录服务的一个视图——理解这点，才能分清哪些操作该去AD里改，哪些该去DNS管理器里点。