When you buy hosting, your domain's nameservers get pointed somewhere. Most often that "somewhere" is Cloudflare or AWS Route 53 — the hosting company has outsourced the DNS layer entirely. There's nothing inherently wrong with this; both are excellent operators.
We don't do it that way. Your domains point at ember.truecorehosting.com, litespeed.truecorehosting.com, spark.truecorehosting.com — three nameservers we run ourselves, on three independent machines, in two countries.
This post explains why, and how it actually works.
What's running
The DNS server is flame-dnsd — our own authoritative DNS daemon, written in Go. It's small (a few thousand lines), audited (by us), and has exactly the features we need and no others. It serves zones from a flat directory on disk; each customer domain is a single zone file.
It runs on three nodes:
- NS1 — primary, source of truth, where zone changes happen
- NS2 — secondary, separate physical box, separate provider
- NS3 — tertiary, separate physical box again
Three separate boxes means a single hardware failure, a single provider outage, or a single botched config push can't take all of DNS down at once. DNS is the most critical layer of the hosting stack — if it's gone, every site is gone, even if the web servers are healthy.
Zone propagation
When you add a record on the customer panel, the change writes to NS1's zone file. A service on NS1 called spark-sync watches the zone directory using inotify (a Linux kernel API for filesystem change notifications). The instant a file changes, spark-sync rsyncs the updated zones to NS2 and NS3 over WireGuard, then verifies the file hash matches on both ends.
End-to-end propagation from "you click save" to "all three nameservers are serving the new record": typically under 5 seconds.
The sync runs over WireGuard rather than the public internet, so the sync traffic itself is encrypted and authenticated even though the zone files themselves are public information. (DNS is public — that's the point. But the sync channel being authenticated means an attacker can't inject fake zone data between nodes.)
Why we don't outsource DNS
Speed of change. When we want to add a feature to our DNS layer (DNSSEC signing, a new record type, per-customer query metrics) we just add it. There's no vendor roadmap to wait for. Our needs and the DNS server's design are the same problem because the DNS server is ours.
Operational coupling. Our DNS layer knows about our provisioning system. When a new customer signs up, the DNS records for their domain appear without a separate API integration to a third-party DNS provider. Fewer moving parts means fewer failure modes.
Sovereignty. This is the harder-to-articulate reason. We don't want our customers' DNS to depend on a US tech giant's infrastructure decisions, pricing changes, or compliance posture. If we're going to operate our own hosting infrastructure, the DNS layer is part of that infrastructure. Outsourcing it would be a hole in the boat.
What this means for you
In practice, mostly nothing — you'd get good DNS from any reputable provider. The differences only show up at the edges:
- When you ask "how fast does a DNS change propagate?" — for us, sub-5-second internally; the public DNS cache TTLs are still the limiting factor at the resolver level
- When you ask "what happens if Cloudflare has a routing issue?" — for us, that's not in our path
- When you ask "can I see DNS query logs for my domain?" — yes, because we operate the server (this is on the roadmap; not exposed in the panel yet)
The honest tradeoff
Running your own DNS is more work than pointing at someone else's. We have to monitor three nameservers instead of zero, handle our own zone-transfer security, manage our own DNSSEC keys (when we ship that), and respond to our own DNS-layer incidents.
We accept the work because the alternative — a single dependency on a giant we have no leverage over — is worse for us strategically and worse for our customers' resilience. If we ran fifty thousand sites, the calculus might change. At our scale, three boxes we control are better than one cloud account we don't.
DNS is invisible when it works. The whole goal is to be the layer of the stack you never have to think about. We think about it constantly so you don't have to.