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还关键
