如何让加入AADDS域的VM工作负载自主管理DNS条目且遵循最小权限？

核心思路 #

避开直接修改AADDS权威域的权限或冲突问题，通过子域隔离+DNS递归转发的方式，既保留AADDS的域服务功能，又让产品团队自主管理各自环境的DNS记录。

方案一：子域私有DNS区域（推荐） #

• 创建环境专属子域私有DNS区域：为每个环境（如env1）创建env1.mydomain.co.uk私有DNS区域，关联对应的环境VNET。
• VM DNS配置不变：所有环境VM仍使用AADDS的IP作为DNS服务器，确保域加入、域内SRV记录等核心功能正常。
• 利用DNS递归解析：当VM查询myapp.env1.mydomain.co.uk时，AADDS作为mydomain.co.uk的权威服务器会递归查询子域记录——由于子域私有DNS区域已关联VNET，Azure DNS会返回正确的内部IP。
• 公网解析匹配：在公网mydomain.co.ukDNS区域中，要么添加env1子域的NS记录指向公网DNS子域服务器，要么直接添加myapp.env1.mydomain.co.uk的A记录指向公网IP，实现同域名内外网解析。
• 权限隔离：为产品团队的流水线授予对应子域私有DNS区域的DNS Zone Contributor权限，无需赋予AAD DC Administrators等高权限，完全满足自主启停环境的需求。

方案二：自定义DNS服务器（适合复杂场景） #

• 在Hub VNET部署自定义DNS服务器（如Windows DNS或Bind），配置转发规则：
  • 所有mydomain.co.uk根域的请求转发至AADDS的IP，保障域服务功能正常。
  • 所有*.env*.mydomain.co.uk的请求转发至Azure私有DNS区域的解析端点（或直接在自定义DNS上维护这些记录）。
• 修改环境VNET的DNS配置：将所有环境VNET的DNS服务器指向Hub的自定义DNS服务器。
• 权限管理：产品团队仍可管理对应子域的私有DNS区域，自定义DNS负责转发逻辑，实现权限隔离。
  • 缺点：需要额外维护自定义DNS服务器，增加运维成本。

方案三：AADDS自定义记录的权限限制规避（不推荐） #

如果必须在根域下添加记录，可创建受限的AAD DC Administrators成员账户，仅用于DNS记录管理，并通过Azure AD条件访问限制该账户的使用范围（如仅允许特定流水线的IP访问）。但此方案仍存在误操作风险，不符合最小权限原则，仅作为备选。

内容的提问来源于stack exchange，提问作者Colin Smith