Skip to content

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

New issue
New issue
Open
Feature
Open
DNS Framework: tenants cannot own DNS servers or vanity zones (no account/domainid on addDnsServer/createDnsZone)#14525
Feature
Milestone
25.0

Description

@abaltic
abaltic
opened on Oct 29, 2026

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.

Activity

  1. boring-cyborg commented on Oct 29, 2026

    @boring-cyborg
    boring-cyborgBot
    on Oct 29, 2026 – with boring-cyborg

    Thanks for opening your first issue here! Be sure to follow the issue template!

  2. sudo87 commented on Oct 30, 2026

    @sudo87
    sudo87
    on Oct 30, 2026
    Contributor

    Thank you @abaltic for testing the feature and for the detailed report.

    • Root-only addDnsServer: This is intentional. The DNS server URL is user-supplied and the management server connects to it, so we restricted add, update and delete to root admin as a security fix (DNS Provider URL Validation #13821). Docs are out of date, will fix them.
    • Ownership by account, domain or project: apache/cloudstack#13911 tracks adding account, domainid and projectid so root can provision a server on a tenant’s behalf
    • Zone ownership (createDnsZone, reassigning zones): This isn’t covered by apache/cloudstack#13911. We’d like to design it together with that work so ownership rules stay consistent.

  3. github-actions commented on Oct 30, 2026

    @github-actions
    github-actionsBot
    on Oct 30, 2026 – with GitHub Actions

    Warning

    threat detection engine error
    The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.

    What happened

    The threat detection engine failed to produce results.

    Review the workflow run logs for details.

    🎯 Triage report

    In the DNS Framework (4.23.0.0), tenants cannot manage zones for domains they own. addDnsServer is root-only, the documentation says domain admins may call it, and addDnsServer and createDnsZone have no account, domainid or projectid parameters. A maintainer comment says root-only add, update and delete is intentional (#13821, a security fix), that ownership by account, domain or project is tracked in #13911, and that zone ownership is not covered by #13911 and will be designed with it.

    📊 Assessment

    Dimension Value Reasoning
    Type type:enhancement Feature and ownership-model request; docs mismatch noted
    Component component:api Parameters and permission checks on DNS framework APIs
    Severity n/a Not a bug report
    Labels type:enhancement, component:api No DNS-specific label exists in the repository
    Coding agent Not suitable Ownership and permission design; maintainers want it designed together with #13911

    🔗 Similar issues

    💡 Notes and suggestions

    Generated by Daily Issue Triage · copilot · haiku55 · ~3 AIC · ⊞ 3.8K · ◷

    Add this agentic workflow to your repo

    To install this agentic workflow, run

    gh aw add githubnext/agentics/workflows/daily-issue-triage.md@139fa09ef17cde4135e696ff8e7af09bc5ddfa6e
  4. DaanHoogland
    added this to the 24.0 milestone on Nov 4, 2026

  5. DaanHoogland commented on Nov 4, 2026

    @DaanHoogland
    DaanHoogland
    on Nov 4, 2026
    Contributor

    @sudo87 I read you reaction as "this is future work" . should we label this as feature?

  6. sudo87 commented on Nov 5, 2026

    @sudo87
    sudo87
    on Nov 5, 2026
    Contributor

    @DaanHoogland right, it will be future work. I doubt if we can tag this to 24.0 milestone.

    FYI, raised this pr #14567 to enable creating dns zones on behalf of other accounts (item #1 from proposal). This will allow admin to provision domains for tenants without enforced suffix.

    Adding dns server for other account is yet under discussion, sharing creds with root admin is not safe enough.

  7. DaanHoogland
    modified the milestones: 24.0, 25.0 on Nov 5, 2026
  8. DaanHoogland
    added the
    Feature
    issue type on Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Feature

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions