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
Allow root admin to configure DNS servers on behalf of a specific user/domain and support project-scoped DNS servers #13911
Currently, a DNS server can only be set up for the calling account/domain, there is no way for a root admin to configure one on behalf of a different account or domain, and no way for a DNS server to belong to a project.
As a root admin, I would like to be able to:
Set up a DNS server on behalf of a specific user/account
Set up a DNS server on behalf of a specific domain
Attach a DNS server to a project
Additional constraint:
If a DNS server was set up by root admin on behalf of a user/domain, that user/domain should not be able to modify its URL themselves. Only root admin (or whoever provisioned it) should be able to change it.
Motivation:
Asks 1 and 2 are primarily driven by the recent restriction that only root admin can configure a DNS server on a private/internal (RFC1918) address, domain admins and regular users can no longer do so directly (see PR #13821). Without a way for root admin to provision such a server on behalf of another account/domain, that use case is lost entirely for non-root-admin users.
Ask 3 (project support) wasn't part of the initial scope for this feature. It's being tracked here as a follow-up enhancement rather than a gap in the original design.
Ask 4 follows directly from 1 and 2: if the owning user/domain could freely change the URL afterward, they could redirect an admin-provisioned DNS server anywhere they like, defeating the purpose of restricting private-address setup to root admin in the first place.
Requests that root admins be able to configure DNS servers on behalf of another account/domain (not just their own), and for DNS servers to optionally be scoped to a project, with a constraint that admin-provisioned DNS servers can't have their URL changed by the target account/domain. Motivated by a recent restriction (PR #13821) limiting private-address DNS server configuration to root admin only, which otherwise removes this capability entirely for non-root-admin users.
📊 Assessment
Dimension
Value
Reasoning
Type
type:new-feature
Adds new capability (cross-account/domain provisioning, project scoping) not previously possible
Component
component:networking
DNS server configuration is a networking feature
Severity
n/a
Not a bug
Labels
type:new-feature, component:networking
Coding agent
Needs more info
Clear motivation and constraints (1-4) are given, but API parameter/permission design and exact enforcement points aren't specified — needs a design pass before implementation
🔗 Similar issues
No similar open issues found. (References PR #13821 as related prior work that created the need for this feature.)
💡 Notes and suggestions
Consider whether this should be scoped as one FS (for account/domain provisioning) with project support tracked as a separate, smaller follow-up enhancement, as the issue itself notes project support wasn't part of the original design scope.
@RosiKyu not for 24.0, it will be considered for next release. There are still some questions to clarify, such as; is it alright to share credentials of DNS server with the root admin. That seems bigger security risk to me. cc: @weizhouapache
Activity
github-actions commentedon Aug 24, 2026
🎯 Triage report
Requests that root admins be able to configure DNS servers on behalf of another account/domain (not just their own), and for DNS servers to optionally be scoped to a project, with a constraint that admin-provisioned DNS servers can't have their URL changed by the target account/domain. Motivated by a recent restriction (PR #13821) limiting private-address DNS server configuration to root admin only, which otherwise removes this capability entirely for non-root-admin users.
📊 Assessment
🔗 Similar issues
No similar open issues found. (References PR #13821 as related prior work that created the need for this feature.)
💡 Notes and suggestions
Consider whether this should be scoped as one FS (for account/domain provisioning) with project support tracked as a separate, smaller follow-up enhancement, as the issue itself notes project support wasn't part of the original design scope.
Add this agentic workflows to your repo
To install this agentic workflow, run
RosiKyu commentedon Sep 30, 2026
@sudo87 do you plan to create a PR to address this in 24.0?
sudo87 commentedon Oct 1, 2026
@RosiKyu not for 24.0, it will be considered for next release. There are still some questions to clarify, such as; is it alright to share credentials of DNS server with the root admin. That seems bigger security risk to me. cc: @weizhouapache