DNS缓存污染真实存在，表现为DC定位异常、Kerberos认证失败、dcdiag“广告失败”等，根源常是客户端或转发器DNS缓存中存有错误SRV记录；需逐级排查客户端、域DNS服务器及上游转发器缓存，并验证SRV记录权威性。
确认DNS缓存污染是否真实存在
域控制器（dc）定位异常，如netlogon服务注册失败、kerberos认证报错（如krb_ap_err_modified）、dcdiag显示"广告失败"，可能不是网络或ad配置问题，而是客户端或转发器dns缓存中存了过期/错误的srv记录（如 _ldap._tcp.dc._msdcs.{domain}）。先排除其他因素：确保时间同步、防火墙放行udp/tcp 53、389、88等端口，再聚焦dns缓存。
分层排查DNS缓存位置
DNS污染可能发生在多个环节，需逐级验证：
- 客户端本地缓存：运行 ipconfig /displaydns | findstr "dc._msdcs" 查看当前解析结果；用 ipconfig /flushdns 清除后重试
- 域内DNS服务器（通常是DC自身）缓存：在DNS管理控制台 → 右键服务器 → “属性” → “高级” → 勾选“禁用递归”并重启DNS服务（临时措施），或直接运行 dnscmd /clearcache
- 上游DNS转发器（如ISP或公共DNS）：若域DNS启用了转发，且转发目标返回了错误SRV记录，污染会持续。改用根提示（Root Hints）测试，或临时将转发器指向可信DNS（如另一台干净DC）
验证SRV记录真实性与权威性
不能只看能否解析，要看是否来自权威源：
- 用 nslookup -type=srv _ldap._tcp.dc._msdcs.contoso.com 127.0.0.1（查本机DNS），对比 nslookup -type=srv _ldap._tcp.dc._msdcs.contoso.com （直连DC的DNS服务）——两者结果必须一致且指向当前在线DC
- 检查响应中的 auth 标志：若为 non-authoritative，说明是缓存结果；authoritative 才代表来自该DC的正向/反向区域
- 确认DC的DNS区域中已启用“动态更新”，且Netlogon服务正在运行（net start netlogon）；若SRV未自动注册，可手动运行 nltest /dsregdns
建立防御性缓存管理机制
避免反复踩坑，建议固化以下操作：
- 域内所有Windows客户端和DC统一使用域DNS服务器作为首选DNS，禁用任何非域DNS（如8.8.8.8）作为备用，防止缓存污染跨入
- 在DC的DNS服务器上，为 _msdcs.{domain} 区域设置较短的TTL（如300秒），加快错误记录过期速度
- 定期执行脚本检查关键SRV记录一致性，例如用PowerShell调用 Resolve-DnsName -Type SRV -Server
"_ldap._tcp.dc._msdcs.contoso.com" 并比对返回的target和port - 将DNS日志级别调至“详细”，在事件查看器中筛选Event ID 550–560，定位异常查询来源
