Security and Operating Model
Security and Operating Model describes the boundaries between panel sessions, external API users, provider credentials, cluster communication, and server-local administration.
Where to find it: Documentation > DNS Manager > Security and Operating Model.
Available to: All readers; root is responsible for server-wide policy and recovery controls.
What this page does
This page helps operators choose the correct identity and interface. A browser session is for people, the public API is for customer integrations, AI Mode works through the signed-in role, and cluster communication is a private service-to-service concern. Credentials from one boundary are not interchangeable with another.
Before you start
Identify who or what is calling, the source network, the owned zones, the least permission needed, and whether the operation changes DNS, topology, provider state, or operating-system access.
Security layers
| Boundary | Controls | Important rule |
|---|---|---|
| Panel session | Username/password, conditional 2FA, revocable server-side session, CSRF protection, account revalidation, and panel IP rules. | Use a named human account; disabling or resetting the account revokes relevant sessions. |
| Public API | Non-root API name/key or Basic authentication, active linked panel account, permissions, ownership, and separate API IP rules. | Call only the documented port-882 routes. Root is deliberately rejected. |
| AI Mode | Signed-in identity, role-scoped catalog, confirmation for destructive work, and exclusions for human-only credentials. | The model does not supply trusted identity or permission. |
| Cloudflare and WHMCS | Encrypted provider secrets, allowlisted operations, domain ownership, optional WHMCS validation, delegation checks, and audit events. | Tokens and API secrets are never documentation examples and are not redisplayed after save. |
| Cluster transport | Private peer authentication and a dedicated internal listener. | It is not a customer API and is intentionally absent from the public reference. |
| Node administration | Root password, SSH port/AllowUsers, system update policy, local TLS, and root IP rules. | Verify an alternate access path before changing anything that can lock out operators. |
How to use it
- Choose a named human account or dedicated integration identity.
- Enable 2FA for people and source-IP rules where stable addressing permits it.
- Grant only the role, zone ownership, and API permission needed.
- Read current state and create a backup before disruptive DNS, cluster, restore, or update work.
- After the change, inspect Audit and verify from the system that consumes the result.
Result and next check
Each caller uses the correct trust boundary and a compromised key cannot silently inherit root, another user's zones, private peer access, or a provider secret. See Security for controls and Public API for the external contract.
Theme color