Inside Salieno Core's DNS Manager: Why We Built It From Scratch

Why DNS Management Deserves Its Own Engine#

DNS is one of those layers that nobody notices until it breaks. For hosting resellers, a misconfigured zone or a slow propagation window can mean angry clients, lost emails, and support tickets that eat into already-thin margins. When we set out to build Salieno Core's DNS manager, we had a choice: wrap an existing tool like PowerDNS or BIND in a management layer, or design something purpose-built for the multi-tenant reseller workflow.

We chose to build from scratch. This post explains why, how it works under the hood, and what trade-offs we accepted in the process.

The Problem with Off-the-Shelf DNS Stacks#

PowerDNS, BIND, and NSD are battle-tested authoritative servers. The problem was never the server software itself — it was the gap between what those tools expose and what a reseller actually needs day-to-day.

A reseller managing 200 domains across 40 cPanel accounts needs:

• Per-account zone isolation — one client's misconfigured CNAME should never cascade into another client's outage.
• Instant propagation — when a client adds an MX record for Google Workspace, they expect it to work in seconds, not minutes.
• Bulk operations — changing nameservers across 50 domains after a server migration shouldn't require a script and a prayer.
• Audit trails — when something goes wrong, you need to know who changed what and when.

PowerDNS gives you an API and a database backend. BIND gives you zone files and rndc. Neither gives you a tenant-aware management plane with role-based access, rate limiting, and a UI that a non-technical end user can navigate without opening a support ticket.

We could have bolted those features onto PowerDNS with a middleware layer. We explored it. The complexity of keeping that middleware in sync with zone state, handling edge cases around DNSSEC key management, and maintaining compatibility across PowerDNS versions convinced us it would become a maintenance burden that grew faster than the product.

How Salieno Core's DNS Manager Works#

The DNS manager in Salieno Core is a purpose-built authoritative DNS server with an integrated management API. Here's the architecture at a high level.

The Authoritative Server#

At the core is a lightweight authoritative-only nameserver written in Go. It reads zone data from a shared PostgreSQL database and caches it in memory. It does not recurse, it does not forward — it serves authoritative answers for the zones it owns, and that's it.

This matters for two reasons. First, security surface: an authoritative-only server that never initiates outbound queries is inherently harder to abuse for amplification attacks. Second, performance: the in-memory zone cache means lookups are served from RAM with no disk I/O. In internal benchmarks on a modest 2-core VPS, the server sustained over 80,000 queries per second with sub-millisecond response times.

Zone Management and Tenant Isolation#

Every zone is scoped to an account. The management API enforces this at the database level — there is no shared namespace between tenants. When a reseller's client logs into their control panel and edits a DNS record, the API call is scoped to their account ID. There is no path, even through a bug or misconfiguration, for one tenant to read or modify another tenant's zones.

Zone changes are written to the PostgreSQL database and immediately picked up by the authoritative server via a lightweight change-notification channel (PostgreSQL's LISTEN/NOTIFY). This means propagation is effectively instant — the moment a record is saved, it is live. No reload commands, no polling intervals.

DNSSEC, Done Simply#

DNSSEC is one of those features that is technically important but operationally painful in most hosting panels. We wanted it to be a single toggle.

When a reseller enables DNSSEC for a zone, Salieno Core generates a KSK and ZSK pair, signs the zone, and publishes the DS record to the parent zone via an API call to the domain's registrar (where supported). Key rotation is handled automatically on a configurable schedule. The reseller sees a green badge and the DS record details — nothing more.

We know this won't satisfy every edge case. If a registrar doesn't support automated DS updates, the reseller will need to handle that manually, and the UI makes that clear. We'd rather be honest about the limit than pretend we've solved universal DNSSEC deployment.

Trade-Offs We Accepted#

Building from scratch means we own the bugs. There is no upstream community to file issues against when something goes wrong. We accepted that cost because the alternative — maintaining a compatibility layer over PowerDNS — would have introduced a different class of bugs that are harder to diagnose and fix.

We also accepted a narrower feature set at launch. Salieno Core's DNS manager does not currently support hidden primaries, AXFR zone transfers to external secondaries, or ALIAS/ANAME flattening at the apex. These are on the roadmap, but we shipped without them because the core reseller workflow — create zone, add records, enable DNSSEC, serve answers — works reliably and fast.

For resellers who need to run their own secondary nameservers or integrate with external DNS providers, Salieno Core exposes a standard zone-export API that outputs BIND-compatible zone files. It's not as seamless as native AXFR, but it covers the migration and backup use case.

What This Means for Resellers#

If you're running Salieno Core, the DNS manager is already handling your zones. You don't need to install PowerDNS or manage a separate BIND instance. The nameserver runs as part of the core service, uses the same database, and is monitored by the same health-check system.

If you're evaluating Salieno Core and DNS is a concern — and it should be, because DNS is where hosting reliability is won or lost — the key points are these: tenant isolation is enforced at the database level, propagation is sub-second, and DNSSEC is a toggle rather than a project.

We built it this way because resellers told us DNS was the layer they spent the most time firefighting and the least time choosing deliberately. That felt like the right problem to solve.