Cluster Settings
Cluster Settings manages deployment-wide defaults and security/retention policies that should remain consistent across SDM members.
Where to find it: SDM root sidebar > Cluster Settings.
Available to: root.
What this page does
The page groups related controls into tabs so root can change the shared policy without confusing it with node-local networking or TLS. Saved values are part of the cluster settings contract and are expected to synchronize to peers.
Before you start
Check node health and current values, understand the effect on new versus existing zones, and avoid simultaneous edits from multiple nodes. For security controls, keep a second valid session or access path available.
Settings tabs
| Tab | Controls | Why it matters |
|---|---|---|
| Timezone | IANA timezone. | Keeps displayed times, schedules, logs, and audit interpretation consistent. |
| DNS Resolver | Search domain and up to four resolver nameservers. | Controls server-side name resolution used by SDM operations. |
| Zone Defaults | Default TTL, SOA primary override, responsible mailbox, refresh, retry, expire, minimum. | Provides authoritative defaults for newly created zones and dynamic SOA behavior. |
| Server Logs | Journald retention and storage policy. | Balances diagnostic history and disk use; see Server Logs Settings. |
| Server Audit | Audit retention and storage budget. | Defines how long change evidence remains available. |
| Two-Factor | Root 2FA bootstrap, enable, and disable. | Protects the highest-authority panel account. |
| IP Access | Root panel IP/CIDR allow rules. | Restricts where root may sign in. |
| Rate Limit | Maximum failures 1–50; window 1–1,440 minutes; automatic block 0–10,080 minutes; manual block/unblock. | Slows credential attacks and exposes current blocks. |
Controls and fields
| Control, Field, Or Section | What It Does | What It Affects | Recommended Usage |
|---|---|---|---|
| Timezone tab | Loads the cluster-wide timezone selector and current server date/time display. | Affects timestamp display and correlation for logs, audit events, jobs, backups, and troubleshooting views. | Set it to the operational timezone used by the customer support team. Keep all nodes consistent. |
| Timezone selector | Lists valid system timezone names such as UTC or region/city values. | Determines how time is displayed and stored by related runtime services. | Use UTC for multi-region operations or the customer business timezone for single-region support. |
| Update Timezone | Saves the selected timezone through the settings API. | Updates system/panel time behavior after backend validation. | Run before comparing audit/log timestamps across incidents. |
| DNS Resolver tab | Loads DNS search-domain and resolver nameserver settings. | Controls outbound DNS lookups performed by the SDM server when it needs to resolve external names. | Use reliable recursive resolvers reachable from every node. |
| DNS Search Domain | Optional domain appended to short/unqualified hostnames during resolver lookups. | Can make internal short names resolve as full names. | Leave empty unless the environment intentionally uses short internal hostnames. |
| Primary Nameserver | First recursive resolver used for outbound DNS resolution. | Primary lookup path for external DNS queries from the server. | Required for a healthy resolver configuration. Use a trusted internal resolver or stable public resolver. |
| Secondary / Third / Fourth Nameserver | Additional fallback recursive resolvers. | Improve resolver availability if the primary resolver is unreachable. | Add at least one secondary resolver for production clusters. |
| Save Changes in DNS Resolver | Stores resolver search domain and nameserver values. | Updates resolver configuration used by server-side lookups. | Save during maintenance if changing resolver infrastructure; verify lookups after saving. |
| Zone Defaults tab | Loads the default TTL and SOA template used when new zones are created from the panel or external API. | Affects only newly created zones unless another workflow explicitly applies changes to existing zones. | Review before onboarding customers so every new zone starts with correct authoritative metadata. |
| Default TTL | Default Time To Live in seconds for new DNS records created with a zone. | Controls how long resolvers may cache default answers before asking again. | Typical production values are 3600 seconds. Use lower values for dynamic migration environments, but avoid very low values at scale. |
| SOA Primary NS | The MNAME field in the SOA record: the primary authoritative nameserver for newly created zones. | Tells secondary DNS systems which nameserver is considered primary for zone transfers and SOA authority. | Use the canonical SDM nameserver hostname, usually the first authoritative nameserver for the platform. Include the final dot if your DNS policy requires fully qualified names. |
| SOA Responsible Mailbox | The RNAME field in the SOA record: administrative contact for newly created zones, written in DNS mailbox format. | Publishes who is responsible for the zone in DNS metadata. | Use a monitored hostmaster-style mailbox. In DNS SOA format, the first dot represents the at-sign, so confirm formatting before saving. |
| SOA Refresh | Time in seconds that secondary DNS servers wait before checking whether the zone serial changed. | Controls how quickly secondary servers learn that a zone may have newer data. | Use a balanced value such as 10800 unless you run aggressive external secondary synchronization. |
| SOA Retry | Time in seconds that a secondary waits before retrying after a failed refresh check. | Controls retry behavior during temporary primary reachability problems. | Keep retry lower than refresh so secondaries recover quickly after transient failures. |
| SOA Expire | Maximum age in seconds after which a secondary should stop serving the zone if it cannot reach the primary. | Protects users from serving very old DNS data after long primary outages. | Use a sufficiently long value for resilience, commonly measured in days; avoid values shorter than normal maintenance windows. |
| SOA Minimum | Minimum/negative cache TTL used by resolvers for negative answers such as non-existing names. | Affects how long NXDOMAIN or negative answers can be cached. | Use values that balance fast correction with resolver load; 3600 is a common safe default. |
| Save Zone Defaults | Stores the TTL and SOA template values. | Changes the template applied to future zone creation via UI and supported external API flows. | After saving, create a test zone in a non-production namespace if you need to verify exact SOA output. |
| Server Logs tab | Loads journald/server log retention, storage, coverage, and prune controls. | Controls how much server log evidence remains available for troubleshooting. | Keep at least the standard 30-day / 5 GB baseline unless support approves a different retention model. |
| Server Log Retention Minimum | Minimum number of days of server logs to keep. | Defines the time window available for incident investigation. | Use 30 days or more for production. Values below the baseline are automatically raised by the UI workflow. |
| Server Log Storage Allocation | Disk budget in GB for server log storage reporting and policy. | Limits log growth and helps estimate utilization. | Increase it on busy DNS clusters; avoid setting it so low that useful logs rotate before support can inspect them. |
| Save Policy in Server Logs | Saves log retention and storage policy. | Updates the logging policy used by the server. | Save after changing retention or storage; watch the notice card for baseline warnings. |
| Prune Now in Server Logs | Runs immediate cleanup of archived logs outside the current policy after hostname confirmation. | Deletes old log journals and cannot be used for later incident reconstruction. | Export or capture important evidence first. Type the hostname only when you intend to prune. |
| Server Audit tab | Loads native audit retention, storage budget, event coverage, and prune controls. | Controls how long API and UI action evidence remains queryable. | Keep enough audit history for customer disputes, security review, and support escalation. |
| Audit Retention Minimum | Minimum number of days audit events are kept. | Defines how far back administrators can investigate actions. | Use 30 days or more unless compliance requires a longer window. |
| Audit Storage Allocation | Cluster-wide audit storage budget used for utilization reporting. | Does not itself decide which events are pruned; pruning is retention-based. | Use it as capacity planning input and keep it realistic for the event volume. |
| Save Policy in Server Audit | Saves audit retention and storage budget, then requests a settings sync run. | Updates cluster policy and helps replicate the setting to peers. | Save during quiet periods if the change affects compliance or support procedures. |
| Prune Now in Server Audit | Deletes audit events older than retention after hostname confirmation. | Permanently reduces audit history. | Export required evidence before pruning. Do not prune during an active security investigation. |
| Two-Factor Authentication tab | Loads root 2FA enrollment or disable workflow. | Controls second-factor protection for the root/control-plane account. | Enable 2FA for production root access and store recovery procedures securely. |
| Generate QR Code | Creates root 2FA enrollment data including QR code, secret, label, algorithm, digits, and period. | Prepares an authenticator app enrollment; it does not finish enablement until code verification. | Generate only when the administrator is ready to scan and confirm immediately. |
| Verification code | Current one-time code from the authenticator app. | Proves the secret was scanned correctly before 2FA is enabled. | If verification fails, check device time sync and regenerate enrollment data. |
| Enable 2FA / Disable 2FA | Turns root 2FA on after verification or disables it when already active. | Changes root login security immediately. | Disable only for recovery or approved maintenance, then re-enable. |
| IP Access Control tab | Loads root/control-plane trusted IP or CIDR rules. | Restricts who can access the panel/root scope based on source address. | Add at least two trusted management locations where possible to avoid lockout. |
| IP Address | Trusted IP address or CIDR block. | Defines allowed control-plane source addresses. | Use narrow CIDR ranges; avoid broad public ranges. |
| Comment | Human note for why the IP rule exists. | Improves auditability and future cleanup. | Write the office/VPN/customer reason, not a vague label. |
| Add IP Address | Adds the trusted source rule. | Can immediately restrict access depending on current rule state. | Confirm your current management IP is included before enabling restrictive policies. |
| Delete IP rule | Removes a trusted source rule from the table. | May block future login/API access from that address. | Remove stale VPN/office ranges only after confirming replacement access exists. |
| Rate Limit tab | Loads login-protection thresholds and manual blocked-IP controls. | Protects the login page from brute-force and abusive traffic. | Use stricter values for exposed panels and more tolerant values for noisy but trusted VPNs. |
| Max failed attempts | Number of failed logins allowed before the source is blocked. | Controls sensitivity of automatic blocking. | Keep low enough to stop brute-force attempts but high enough to avoid locking out normal typo mistakes. |
| Window | Time window in minutes used to count failures. | Defines how quickly repeated failures accumulate. | Shorter windows are more forgiving; longer windows catch slower attacks. |
| Auto block duration | Temporary block duration in minutes; zero means permanent until removed. | Controls how long abusive sources remain blocked automatically. | Use temporary blocks for normal environments; permanent blocks need an unblock process. |
| Save Rate Limit | Stores max attempts, window, and block duration. | Changes login protection behavior immediately. | Announce changes to support so lockout tickets can be interpreted correctly. |
| IP or CIDR | Manual block target. | Blocks a single source or range from login attempts. | Use CIDR only when you are sure the whole range is abusive. |
| Reason | Audit-friendly explanation for a manual block. | Helps future administrators understand why a source was blocked. | Include ticket number or abuse reason when available. |
| Block Rule | Adds a manual blocked-IP rule. | Immediately prevents matching sources from authenticating. | Use for confirmed malicious traffic or emergency containment. |
| Blocked IPs table | Shows blocked IP/CIDR, source, reason, creator, creation time, expiry, and actions. | Provides operational visibility into active lockouts. | Review before telling a customer credentials are wrong. |
How to read the result
| Status Or Message | Meaning | What To Check |
|---|---|---|
| Not set | The setting is empty or not returned by the backend. | For Zone Defaults, fill missing SOA/TTL values before onboarding production zones. |
| Enabled / Not enabled | Security feature state such as root 2FA. | Enable root 2FA for production and document recovery. |
| Last prune OK / Never | Indicates whether audit/log prune has run successfully before. | If never, verify retention policy and manually prune only when old data should be removed. |
| Blocked until expiry | A source is currently blocked by rate-limit policy or manual rule. | Check source IP, reason, and expiry before unblocking. |
Safety notes
- Zone Defaults affect newly created zones from both the panel and supported external API flows.
- Resolver settings are for outbound recursive lookups; they do not replace authoritative nameserver records.
- Prune actions permanently remove older audit or log evidence.
- IP access and rate-limit settings can lock out legitimate administrators if recovery access is not planned.
How to use it
- Select one tab and read the current value.
- Check the linked feature page for field limits and side effects.
- Change only the intended policy and save.
- Confirm the returned state, then check another healthy member when the value is replicated.
- For security policy, test a permitted login path before ending the current session.
Result and next check
The deployment reports one coherent cluster-wide policy and healthy peers receive it. Node-local hostname, IP, certificate, SSH, and operating-system settings remain under Local Settings.
Theme color