How Salieno Core Handles DNS Without a Dedicated Nameserver Daemon

The DNS Problem Every Hosting Stack Faces#

Every hosting control panel needs to solve DNS. Customers add domains, create subdomains, set up email — each action requires DNS records to be created, modified, and served authoritatively to the internet. The traditional approach, used by cPanel, Plesk, and most competitors, is to run a full DNS server daemon like BIND or PowerDNS alongside the control panel. That daemon watches a database for changes, rebuilds zone data on the fly, and answers queries in real time.

It works. It's also a persistent operational headache.

A separate DNS daemon means another service to monitor, another set of logs to parse, another attack surface to patch, and another process that can crash at 3 AM. BIND's configuration language alone has caused more late-night debugging sessions than most hosting engineers care to remember. PowerDNS is leaner but still adds a database dependency and its own failure modes.

Salieno Core takes a different path. It doesn't run a DNS daemon at all — at least not in the way you'd expect.

Static Zone Files, Generated at Write Time#

When a customer adds a domain through Salieno Core's panel or API, the system doesn't insert a row into a DNS database and hope a daemon picks it up. Instead, it generates a complete, standards-compliant BIND-format zone file and writes it to disk. Every A, AAAA, MX, TXT, and CNAME record is baked in at generation time.

This happens synchronously during the provisioning event. The zone file is written, a serial number is incremented, and the authoritative server is signaled to reload — all within the same request lifecycle.

The zone file format is vanilla BIND syntax. If you've ever opened /var/named/example.com.db on a cPanel server, you already know the structure. This is deliberate. Zone files in a known format mean you can inspect them with cat, validate them with named-checkzone, or hand-edit them in an emergency without learning a proprietary schema.

A Minimal Authoritative-Only Server#

Salieno Core ships with a bundled authoritative DNS server based on a minimal, purpose-built binary. It does exactly three things:

• Serves DNS queries over UDP and TCP on port 53
• Reloads zone data when signaled (via SIGHUP or an internal IPC call)
• Responds to SOA and NS queries for its hosted domains

That's it. No recursion. No caching. No dynamic update protocol. No zone transfers to secondaries (though you can configure external secondaries that pull via AXFR if you set that up separately).

The binary is compiled as part of the Salieno Core distribution and runs under a dedicated unprivileged user. It chroots itself into the zone file directory and drops all capabilities after binding to port 53. Because it serves only static files, there's no database to corrupt, no write-ahead log to truncate, and no replication state to reconcile.

Why Not Just Bundle BIND or NSD?#

We considered it. BIND is the obvious choice — it's battle-tested, universally understood, and already installed on most Linux systems. NSD is lighter and purpose-built for authoritative-only service.

The problem is operational surface area. BIND's named.conf supports dozens of directives that Salieno Core would never use: recursion ACLs, views, TSIG keys for zone transfers, response rate limiting, query logging policies. Shipping BIND means inheriting all of that complexity, including its CVE history. BIND security advisories are a genre unto themselves.

NSD is closer to what we wanted, but it still expects its own configuration file, its own zone database format (compiled from zone files via nsd-control), and its own process management. It's a separate system with its own lifecycle.

By shipping a single-purpose binary, Salieno Core keeps DNS as a component, not a dependency. There's no installer step that configures a DNS daemon. There's no separate service to enable in systemd. The DNS server starts when Salieno Core starts and stops when it stops.

What This Means in Practice#

For a reseller running Salieno Core on a single VPS, the practical difference is tangible:

• One fewer process to monitor. If Salieno Core is running, DNS is running. There's no scenario where the panel is up but the DNS daemon silently died six hours ago.
• No database dependency for DNS. Zone data lives on the filesystem as plain text. You can back it up with rsync, grep it, diff it, or version it in Git if you want.
• Faster provisioning. There's no asynchronous queue between "customer adds domain" and "domain resolves." It's synchronous and typically completes in under 200ms.
• Simpler disaster recovery. If you need to rebuild a server from a filesystem snapshot, the zone files come along for free. No database dump and restore required.

The tradeoff is that Salieno Core's built-in DNS server is not a general-purpose nameserver. It doesn't support DNSSEC signing (you'd need an external signer), it doesn't do recursion (use your provider's resolver or Unbound for that), and it doesn't natively replicate to geographically distributed secondaries. For that, you pair it with a service like NS1, Cloudflare DNS, or a self-hosted secondary NSD instance that pulls zones via AXFR.

When You'd Want Something Heavier#

If you're running a hosting operation with hundreds of resellers, each managing dozens of domains, and you need features like DNSSEC, GeoDNS, or automatic failover between nameservers — Salieno Core's built-in DNS is the starting point, not the finish line. You'd point domains at an external authoritative provider (Cloudflare, Route 53, a self-hosted PowerDNS cluster) and use Salieno Core's API to push record updates there.

The built-in server handles the 80% case: a reseller managing a few hundred domains on a single server who wants DNS to just work without babysitting another daemon. For the other 20%, the zone file generation logic is the same — it just writes to a different destination.

The Broader Design Principle#

This approach reflects a pattern throughout Salieno Core: prefer static artifacts over running services, prefer the filesystem over databases where possible, and prefer a single process over a stack of cooperating daemons. DNS is one place where that philosophy produces a noticeably simpler operational experience.

If you've ever spent a morning debugging why BIND won't load a zone because of a missing semicolon in a file you didn't know existed, you'll appreciate why we built it this way.