StackX DNS is the StackX product for managed primary and secondary DNS servers based on BIND.
It is designed for clients who want dedicated DNS servers managed and monitored by ScalarX without relying exclusively on DNS from a registrar, hosting provider, or cloud provider.
The target architecture uses at least two separate roles: a primary DNS server and a secondary DNS server. When the context justifies it, these nodes can be placed with different providers, in different countries, or in separate network environments.
The objective is simple: retain control of the DNS zone, limit provider dependencies, and maintain a DNS foundation operated as a first-class production component.
What StackX DNS Provides
Managed DNS Baseline
Managed DNS Baseline| Component | Role |
|---|
| Managed BIND | Dedicated DNS server with a controlled configuration maintained by ScalarX |
|---|
| Primary DNS | Main administration point for zones and DNS changes |
|---|
| Secondary DNS | Zone replication and continued resolution if the primary is unavailable |
|---|
| Zone transfer | Controlled synchronization between primary and secondary |
|---|
| Validation before publication | Syntax validation of the zone before it goes live |
|---|
| Monitoring | Availability, consistency, and operational state checks depending on scope |
|---|
| Configuration backup | Retention of zones, configuration, and the elements required for recovery |
|---|
Why Choose Dedicated DNS
Why Choose Dedicated DNS| Requirement | StackX DNS Response |
|---|
| Avoid dependency on one provider | Primary and secondary servers can be distributed across multiple providers |
|---|
| Retain control of your zones | DNS zones remain operated as a dedicated infrastructure component |
|---|
| Separate registrar and DNS | The registrar does not have to be the operational DNS provider |
|---|
| Standardize changes | DNS changes, checks, and deployments within a managed operations framework |
|---|
| Improve resilience | Multiple DNS nodes, separate roles, and an optional multi-provider architecture |
|---|
Architecture ModelsPrimary, secondary, and multi-provider deployment
Architecture Models| Model | Benefit |
|---|
| Dedicated primary + secondary | Standard baseline with two separate DNS roles |
|---|
| Multi-provider | Distribute nodes across multiple providers to reduce dependency |
|---|
| Multiple geographic zones | Placement tailored to country, latency, or availability constraints |
|---|
| Dedicated client DNS | Complete isolation for a client, group, or sensitive scope |
|---|
| ScalarX operator DNS | Managed operations within a StackX / ScalarCloud architecture |
|---|
Operational ManagementZones, transfers, DNSSEC, and monitoring
Operational Management| Topic | StackX DNS Handling |
|---|
| Add or modify a zone | Change prepared, applied, and checked according to procedure |
|---|
| Modify a record | Locked, backed up, validated, then atomically published, with rollback on failure |
|---|
| Consistency checks | Validation of records, serials, and primary / secondary synchronization |
|---|
| DNSSEC | Explicit activation per zone, state checks, and generation of DS records for publication at the registrar |
|---|
| Resolution monitoring | External checks possible from multiple measurement points |
|---|
| Administration security | Access restricted to authorized operators through a bastion or defined scope |
|---|
| Logging | Operational records retained according to the selected level |
|---|
Dedicated DNS is not only about resolution.
It is a critical dependency: if DNS is centralized with a single provider, an outage, block, or account error can affect the entire scope. StackX DNS treats DNS as a complete infrastructure component.
When to Choose StackX DNS
When to Choose StackX DNS| Context | Benefit |
|---|
| Critical domain | Reduce dependency on shared DNS or DNS supplied only by a registrar |
|---|
| Multi-provider infrastructure | Align DNS with a distributed architecture |
|---|
| Independence requirement | Retain control of resolution even when a provider experiences an incident |
|---|
| Sensitive scope | Dedicated, logged, and operated within a controlled framework |
|---|
| Client with multiple entities | Centralize DNS management without relying on one provider console |
|---|
Product Positioning
Product Positioning| Item | Status |
|---|
| Technical foundation | Managed primary / secondary BIND |
|---|
| Target architecture | At least two separate DNS roles |
|---|
| Multi-provider | Possible and recommended when independence is an objective |
|---|
| Client availability | Subject to scoping, depending on the number of zones, criticality, and desired architecture |
|---|
| Natural complements | StackX Bastion, decentralized monitoring, backup, and recovery procedures |
|---|
Need dedicated, managed DNS servers?
We can define a primary / secondary DNS architecture, with one or more providers, along with monitoring, backup, and operating procedures tailored to your critical domains.
Define Your DNS Scope