Granular restriction: hide "SOA" and "Zone Settings" tabs for non-admin roles

[vducros-neyrial]

Hello everybody,

I'm running PowerDNS-AuthAdmin as a self-service frontend for my hosting clients: each client gets access to their own zone(s) so they can manage their own DNS records directly, without going through me.

I want clients to be able to freely create/edit/delete records (A, AAAA, CNAME, MX, TXT, etc.), but I do not want them to be able to touch:

• the SOA record
• the Zone Settings tab (metadata: SOA-EDIT-API, Zone Type, etc.)

These are administrative settings that, if misconfigured by a client, can break zone transfers or the zone's authority.

---

I've scoped a custom role per team with :

permissions: [zone.read, record.read, record.create, record.update, record.delete, dnssec.read, dnssec.configure]

I already know the current permission doesn't let me separate "edit records" from "edit SOA" or "edit zone settings" — both fall outside what record.* alone can restrict, and there's no dedicated permission for the SOA specifically.

---

Is there another way to achieve this restriction today (a workaround, a UI-level setting, an env var, or something in provisioning.yaml I might have missed) ?
And if not, is a more granular split (e.g. a dedicated record.update.soa permission, or excluding SOA/NS from record.update scope) already on the roadmap ? Happy to open a feature request if it isn't tracked yet.

Thanks a lot for this great project, by the way — it's exactly what I needed to move away from PowerDNS-Admin, really appreciate the work ! 🙏

[jseifeddine]

Thanks @vducros-neyrial

This is a good use case and feature...

Another user posted an issue regarding multi-tenant / client management as you seem to be doing. Hope that it works well for you, however if you think it needs more tweaks let me know... Also would be good to get some clear doc write up regarding your setup example.

Regarding the seperation, ill look at allowing more granular permissions so you can lock them out of the domain settings, just allowing record changes.

Thanks

[vducros-neyrial]

Hello and thanks for the reply, @jseifeddine

Quick context on my setup: 1 primary + 3 secondaries, around 300 DNS zones. I create/provision all base zones myself (SOA, NS, delegation...), and clients only come in afterwards to manage records in their own zone(s). We were previously on PowerDNS-Admin, but since the project is now unmaintained/dead, we're looking to move to something else, which is how we landed here.

The Team system fits this use case really well already. The only gap is what I described: no way to let clients freely manage records while keeping SOA and Zone Settings out of reach. Even with clear instructions, mistakes happen, a wrong SOA-EDIT-API value or a zone type change can break transfers to the secondaries, and clients don't have the context to know that.

A dedicated permission for this would be enough, just don't display the SOA record and Zone Settings tabs when the role doesn't have it.

Thanks again for looking into it 🙏

[jseifeddine]

@vducros-neyrial

please pull latest (1.5.6 + )

Please let me know if the RBAC / Permissions scope now offers what you need.

Thank you !

[vducros-neyrial]

Just updated to 1.5.6 and tested it, this covers my use case perfectly, exactly what I needed 🎉

Thanks a lot, really appreciated !