首先得明确核心问题：Windows域控制器作为our.domain的权威DNS服务器，对于本域内未找到的记录，会直接返回NXDOMAIN，不会触发转发规则——这是权威DNS的固有逻辑，你测试test.lab能正常转发，就是因为它不是DC的权威域。你的核心需求是让用户不用区分域名，同时AD相关记录留在DC，其他记录存在PowerDNS（PHPIPAM同步），下面给你几个可行的方案：

方案一：子域委派（最稳妥的标准方案） #

这是DNS体系中处理这类需求的常规做法，既不破坏AD的DNS权威，又能实现记录分离：

• 在PowerDNS上创建一个子域（比如app.our.domain），所有非AD相关的主机记录都放在这个子域下，由PHPIPAM同步维护。
• 在Windows DC的DNS管理器中，给app.our.domain创建委派记录：指定phpipam.our.domain（10.10.10.250）作为该子域的权威DNS服务器。
• 这样用户访问AD相关资源（比如域内机器、域服务）时，直接由DC解析；访问业务系统时，用xxx.app.our.domain的域名，DC会自动引导查询请求到PowerDNS，完全不用切换DNS服务器。

关于SOA/NS记录的一致性：父域our.domain的SOA/NS保持DC的配置，子域app.our.domain的SOA/NS用PowerDNS的配置即可——这符合DNS的层级逻辑，用户感知不到差异，甚至可以把常用业务系统的记录做别名到子域，进一步降低记忆成本。

方案二：反向转发架构（实现完全同域名解析） #

如果完全不想用子域，只能把PowerDNS作为前端DNS，反向转发AD相关查询到DC：

1. 调整PowerDNS配置：
   • 在PowerDNS上创建our.domain的权威区域，导入所有非AD的主机记录。
   • 配置PowerDNS的转发规则：把AD核心记录的查询（比如_ldap._tcp.dc._msdcs.our.domain、_kerberos._tcp.our.domain、DC的A记录、域用户的SRV记录等）转发到DC的IP（10.10.10.101/102）。
   • 注意：必须确保PowerDNS不会处理AD专属的记录，避免和DC的记录冲突（比如不要在PowerDNS中创建DC的A记录）。
2. 调整客户端DNS设置：
   • 把PowerDNS（10.10.10.250）设为客户端的主DNS服务器，DC设为备用DNS。这样客户端所有查询先到PowerDNS，AD相关请求被转发到DC，其他记录直接由PowerDNS返回。
3. 关键测试：
   • 必须测试AD登录、组策略应用、Kerberos认证等核心功能，确保PowerDNS能正确转发所有AD依赖的DNS记录。

这个方案能实现完全同域名的解析，但配置复杂度更高，而且需要长期维护PowerDNS的转发规则，避免AD记录变更后出现解析问题。

为什么你的初始方案不生效？ #

再次强调：权威DNS服务器不会对自己负责的域触发转发。DC作为our.domain的权威，收到本域的查询时，只会查自己的AD数据库/区域文件，找不到就直接返回NXDOMAIN，不会去查转发服务器——这是DNS协议的规定，所以你之前的尝试无法实现同域下的记录转发。

关于SOA/NS记录一致性的补充 #

如果想让our.domain的SOA/NS同时包含DC和PowerDNS，只有方案二能做到，但风险很高：

• 你需要确保DC和PowerDNS的our.domain区域中没有重复的记录（比如同一个主机名不能在两边都有A记录），否则会出现解析混乱。
• AD的SOA记录是由DC自动维护的，强行修改可能破坏AD的正常运行，所以不建议这么做。

综上，子域委派是最推荐的方案，既符合DNS规范，又能最小化配置和维护成本，同时满足用户的使用需求。

备注：内容来源于stack exchange，提问作者Dave