We Built DNS Into the Hosting Stack. Here's Everything It Does.

Most hosting companies give you a nameserver field and leave you to figure out the rest. You point your domain at their servers, hope propagation works, and only find out something broke when your site goes down or a customer emails you.

We wanted something better. Not just for us — for everyone running on Expanse.

So we built DNS into the hosting stack from scratch. Not as an afterthought, not as a resold third-party product. As a first-class feature that we actually use ourselves, on our own infrastructure, for our own domains.

Here's what that looks like in practice.

---

The infrastructure underneath

Before getting into the product, it helps to understand what's running underneath it.

Our DNS runs on a hidden-primary architecture with three geographic secondaries. The primary is a PowerDNS instance in Frankfurt that never appears in public NS records and never answers queries directly. Its only job is to hold the canonical zone data and push updates to secondaries via AXFR/IXFR zone transfers.

The three secondaries are what the world sees:

All public DNS queries hit one of these three nodes. The hidden primary is never exposed to query volume, which means a DDoS against our nameservers can't affect zone integrity. Changes propagate from the primary to all secondaries typically within 1–3 seconds — we've measured it.

Authoritative DNS resolution latency — how long it takes a resolver to get an answer from our nameservers for your zone. That's the number that reflects geographic proximity to Pulsar, Quasar, and Vega — not your application's HTTP response time.

This is the same mesh your domains live on when you host with Expanse. Not a separate product, not a third-party stack bolted on — the same infrastructure we trust for our own zones.

---

What you actually get

DNSSEC

DNSSEC is available on every zone. We use ECDSAP256SHA256 (CSK, 256-bit) — a modern algorithm that's fast and well-supported by resolvers. When you enable it, we generate the cryptographic keys and surface the DS records you need to add at your registrar to complete the chain of trust.

It's included here.

Health checks

You can attach a health check to any A or AAAA record. We probe from three regions — Frankfurt, Singapore, and New York — every minute. Two or more failures constitutes a down event.

What you configure:

• Protocol (HTTP or HTTPS)
• Port
• Path
• Check interval
• Alert email (defaults to your account email)
• Webhook URL for Slack, Discord, PagerDuty, whatever you use

The per-region latency breakdown is the round-trip probe time from that region to your server over HTTPS — not DNS resolution time. You might see FRA at ~76ms, SIN at ~376ms, NYC at ~243ms; if your origin is in Frankfurt, Singapore probing across continents explains a high SIN number — that's your server's response path to the probe, not how fast DNS resolves.

Health checks are free. Route53 charges $0.50 per check per month. Cloudflare gates health checks behind paid plans. We don't.

Propagation check

After making a DNS change, you can trigger a propagation check directly from the record. We query six public resolvers simultaneously and show you per-resolver status and response time.

These figures are how long each resolver took to respond to our propagation query — not end-user DNS resolution latency in general, and not the same as the authoritative resolution numbers earlier on this page. Your TTL determines how long public resolvers cache your records.

| Resolver | Example panel latency | |---|---|---| | Google DNS (8.8.8.8) | 177ms | | Google DNS 2 (8.8.4.4) | 2ms | | Cloudflare (1.1.1.1) | 330ms | | Cloudflare 2 (1.0.0.1) | 325ms | | Quad9 (9.9.9.9) | 219ms | | OpenDNS | 125ms |

We're also adding our own nameservers (Pulsar, Quasar, Vega) to this check, so you can see your records are in sync on our infrastructure immediately — and distinguish that from public resolver cache lag, which is just TTL doing its job.

Nobody else has this built into the panel. You'd normally open whatsmydns.net in a separate tab.

Change history and rollback

Every record change is logged — creates, updates, deletes — with a timestamp and the exact before/after values. You can roll back any individual change with one click.

This isn't just audit logging. It's a real undo button.

A few details on how it works:

• Rolling back a CREATE removes the record and any associated health check
• Rolling back an UPDATE restores the previous record value; the health check config stays intact, and we reset the check status so you don't see a stale DOWN state from the old IP
• Rolling back a DELETE restores the record and the health check that was attached to it — we snapshot the health check config at delete time so it can be fully restored

That last one took some deliberate engineering. Most systems that log changes don't think about dependents. If you accidentally delete a record that had a health check on it and then roll it back, you'd normally have to reconfigure monitoring from scratch. We persist the health check snapshot in the change log so the rollback is complete.

History is retained at 200 entries per zone, pruned automatically.

Record locking

You can lock any record. A locked record can't be edited or deleted until you explicitly unlock it. No confirmation dialogs that get click-through'd — a hard lock.

This is underrated for critical records. Lock your MX records. Lock your root A record. Lock anything that would cause a serious outage if changed accidentally.

---

How this compares

Honest comparison across the features that matter:

Route53: $0.50/check/mo for non-AWS endpoints; first 50 free for AWS endpoints only.

The honest gaps: we don't have GeoDNS yet, and our anycast rollout is in progress as we build out our BGP infrastructure. Cloudflare has 300+ PoPs and years of uptime reputation we haven't had time to accumulate. Those are real differences.

What we have that nobody else does at this price: per-record rollback with health check snapshot restoration, built-in propagation checking, and record locking. These aren't premium features. They're just included.

---

Why it's free

The DNS product is free right now, with no current plans to change that.

The honest reason: DNS hosting is most valuable when it's integrated with the rest of your hosting stack. Billing you separately for DNS while you're already a hosting customer would be friction for no good reason. We'd rather you have one less thing to manage elsewhere.

If that changes, you'll know ahead of time. Your zones are always exportable as standard BIND format — you're never locked in.

---

What's next

A few things in active development or on the near roadmap:

• Anycast — once our own BGP anycast infrastructure matures, the secondary mesh moves onto it. Global query latency drops significantly.
• GeoDNS — not in scope for this architecture today, but on the list
• Customer-facing DNSSEC toggle — the backend is fully live, the UI toggle is being wired in
• Edge resolvers in propagation check — Pulsar, Quasar, Vega will appear as named servers alongside the public resolvers

---

One last thing

The hidden primary is the authoritative source of truth for all zones on our mesh. It's protected by a firewall allowing only known secondary IPs, and sits behind Aurologic DDoS mitigation on the Frankfurt edge. It's not listed in any public record and never will be.

If you want your domains on infrastructure run end-to-end by one operator — same team that handles your servers, your IPs, your network, your DNS — that's what Expanse is. Get in touch or just point your nameservers at Pulsar, Quasar, and Vega when you onboard.

---

Published April 28, 2026