DNS Framework: tenants cannot own DNS servers or vanity zones (no account/domainid on addDnsServer/createDnsZone)

未关闭
  • 哪里不对？
#14,525 5 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
java
领域
backend-api-design

调研方向

Start by reading the DNS Framework API definitions and permission checks for addDnsServer and createDnsZone, then trace how DNS server and zone ownership and public suffixes are handled. The issue proposes several alternative changes, including tenant ownership, domain admin access, and suffix rules, so first agree on scope with maintainers. Done means tenants can manage delegated vanity zones under the agreed ownership and access rules without receiving the PowerDNS API key.

由索引模型根据 Issue 内容生成。

描述

ISSUE TYPE
  • Improvement Request / Bug Report
COMPONENT NAME

DNS Framework (PowerDNS provider), API, UI

CLOUDSTACK VERSION

4.23.0.0

SUMMARY

The new DNS Framework works well for provider-owned zones, but in a multi-tenant
cloud there is no way for a tenant to manage a zone for a domain they own
(e.g. customer.com). Every tenant zone is forced under the public server's
suffix, and the admin cannot create a server entry or zone on a tenant's behalf.

OBSERVED BEHAVIOUR
  1. addDnsServer called by a non-root account fails with
    "This API can only be called by root admin".
    The documentation states that admins and domain admins can create public
    DNS servers, so either the docs or the permission check is wrong.
  2. Only one DNS server entry per account + URL is allowed
    ("This Account already has a DNS server integration for URL: ...").
  3. addDnsServer and createDnsZone have no account, domainid or
    projectid parameters (verified with list apis ... filter=params),
    so root cannot create a server entry or zone owned by a tenant.
  4. Zones created by root are owned by root and are not visible to tenants.
  5. Tenants creating zones on a public server are always restricted to the
    single publicdomainsuffix.

Result: a tenant who owns customer.com and delegates it to our nameservers
cannot manage that zone through CloudStack. The only workarounds are manual
management by root, a separate DNS UI outside CloudStack, or CNAMEs from the
vanity zone into a suffixed tenant zone.

USE CASE
  • Provider runs a PowerDNS cluster and wants to offer managed DNS to tenants.
  • Default: tenants self-serve zones under cloud.provider.example
    (works today).
  • Some tenants own their own domains (customer.com), delegate them to the
    provider's nameservers, and need to manage records (A, MX, TXT, CNAME)
    and VM auto-registration for them, without access to the PowerDNS API key.
PROPOSED IMPROVEMENTS
  1. Add account + domainid (and projectid) to addDnsServer and
    createDnsZone, consistent with other CloudStack resource APIs, so root
    can provision a server entry or zone owned by a tenant.
  2. Alternatively, an API to change zone ownership
    (e.g. assignDnsZone / updateDnsZone account=... domainid=...).
  3. Allow domain admins to call addDnsServer as documented, or update the
    docs if root-only is intended.
  4. Allow multiple allowed suffixes per public server, or per-domain suffix
    rules (e.g. domain ROOT/CustomerA may create customer.com).
  5. Optional: an ownership verification step (TXT challenge) before a tenant
    can create a zone outside the public suffix, to prevent zone squatting.
STEPS TO REPRODUCE
  1. As root admin, add a public PowerDNS server with publicdomainsuffix=cloud.provider.example.
  2. As a tenant user, try to create zone customer.com -> forced under the suffix.
  3. As a tenant user or domain admin, try addDnsServer -> "can only be called by root admin".
  4. As root, try addDnsServer again with the same URL -> "already has a DNS server integration for URL".
  5. As root, create zone customer.com -> owned by root, not visible to the tenant.
主要语言
Java
星标
3.1k
派生
1.4k
平均合并
7 天 16 小时
30 天内合并 PR
15

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/cloudstack 的其他 Issue

查看 apache/cloudstack 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。