You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DNS Framework: tenants cannot own DNS servers or vanity zones (no account/domainid on addDnsServer/createDnsZone) #14525
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
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.
Only one DNS server entry per account + URL is allowed
("This Account already has a DNS server integration for URL: ...").
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.
Zones created by root are owned by root and are not visible to tenants.
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
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.
Alternatively, an API to change zone ownership
(e.g. assignDnsZone / updateDnsZone account=... domainid=...).
Allow domain admins to call addDnsServer as documented, or update the
docs if root-only is intended.
Allow multiple allowed suffixes per public server, or per-domain suffix
rules (e.g. domain ROOT/CustomerA may create customer.com).
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
As root admin, add a public PowerDNS server with publicdomainsuffix=cloud.provider.example.
As a tenant user, try to create zone customer.com -> forced under the suffix.
As a tenant user or domain admin, try addDnsServer -> "can only be called by root admin".
As root, try addDnsServer again with the same URL -> "already has a DNS server integration for URL".
As root, create zone customer.com -> owned by root, not visible to the tenant.
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.
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.
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
The docs-versus-permission mismatch (domain admins documented as able to call addDnsServer, but the API is root-only) is already acknowledged by a maintainer as a docs issue to fix.
Activity
boring-cyborg commentedon Oct 29, 2026
Thanks for opening your first issue here! Be sure to follow the issue template!
sudo87 commentedon Oct 30, 2026
Thank you @abaltic for testing the feature and for the detailed report.
github-actions commentedon Oct 30, 2026
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.
addDnsServeris root-only, the documentation says domain admins may call it, andaddDnsServerandcreateDnsZonehave noaccount,domainidorprojectidparameters. 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
🔗 Similar issues
💡 Notes and suggestions
addDnsServer, but the API is root-only) is already acknowledged by a maintainer as a docs issue to fix.Add this agentic workflow to your repo
To install this agentic workflow, run