← All dispatches
infrastructure

Why We Built Our Own DNS Infrastructure (And What It Actually Looks Like)

Most SaaS teams treat DNS as an afterthought. Here's what a deliberately designed DNS mesh looks like, and why it matters more than you'd think.

Most SaaS teams treat DNS as an afterthought. You pick Route53 or Cloudflare, point your records at them, and forget about it. It works — until it doesn't.

We didn't build our own DNS infrastructure because something broke. We built it because when you're running hosting infrastructure for other businesses, DNS is your product. Every millisecond of resolution time and every minute of downtime is visible to your customers, even if they can't name the cause.

Here's what we actually built and why.


The Problem With Managed DNS (For Us)

Managed DNS providers are fine for most use cases. But they come with trade-offs that matter at the infrastructure level:

  • You share fate with millions of other customers. When Cloudflare has an incident, so do you.
  • You have no control over propagation. Zone changes go out on their schedule, not yours.
  • rDNS is a nightmare. Getting reverse DNS delegation working across IP blocks through a third party involves too many moving parts.

For a hosting company operating its own ASN with customers across multiple continents, these weren't acceptable constraints.


What We Built: A Three-Node DNS Mesh

The architecture is straightforward but deliberate.

Hidden Primary

The authoritative source of truth is a hidden primary nameserver in Frankfurt. It's not publicly listed in NS records and never responds to recursive queries directly. Its only job is to hold the canonical zone data and push updates to secondaries via AXFR/IXFR zone transfers.

This means:

  • It's never exposed to the public internet's query volume
  • DDoS against our public nameservers can't affect zone integrity
  • Zone updates are atomic — all secondaries get the same data from one source

Three Geographic Secondaries

Public queries are handled by three secondary nameservers, each in a different region:

NodeLocationHostname
QuasarFrankfurt, EUquasar.expanse.host
PulsarSingapore, ASpulsar.expanse.host
VegaNew York, NAvega.expanse.host

These pull zone updates from the hidden primary and serve all public DNS queries. Clients get resolved by whichever node their resolver reaches — typically the geographically closest one.

We also offer authoritative DNS hosting for customer domains on this same mesh — the same multi-region secondaries and propagation path we rely on for our own zones. If you want your records on infrastructure we run end-to-end, that’s part of what Expanse provides; say the word when you’re onboarding or reach out.

Real Resolution Times

We ran global DNS resolution tests across all three nodes. Here's a sample of what we're seeing:

Quasar (Frankfurt)

  • Amsterdam → 0ms
  • Bucharest → 8ms
  • Ashburn, US → 18–20ms
  • Chiba, Japan → 12ms

Pulsar (Singapore)

  • Chiba, Japan → 16ms
  • Ashburn, US → 10–11ms
  • Amsterdam → 83ms

Vega (New York)

  • Ashburn, US → 4–20ms
  • Calais, France → 12ms
  • Amsterdam → 36ms

The picture this paints: European queries hit Quasar at sub-20ms, US queries hit Vega at under 20ms, and Asian queries have Pulsar nearby. No single node is a bottleneck.


rDNS Delegation

Reverse DNS — mapping IP addresses back to hostnames — is often neglected but matters for email deliverability, abuse handling, and general network hygiene.

We handle rDNS for our own IP space by having our upstream LIR delegate the reverse zones to our own nameservers via NS delegation. This means we control PTR records for our entire IP block directly, without going through a provider's web UI or waiting on ticket queues.


What This Actually Gives Us

  • No shared fate with other DNS providers' incidents
  • Full zone control — changes propagate on our timeline
  • Sub-20ms resolution across Europe and North America, sub-30ms in Asia
  • Direct rDNS control over our entire IP space
  • DNS hosting for customers — your zones can live on the same mesh, not bolted onto a separate third-party stack

Is This Overkill for Most Teams?

Probably, yes. If you're a SaaS company running on AWS, Route53 with health checks and latency-based routing covers most bases at low operational overhead.

But if you're building infrastructure that others depend on, the control you get from owning your DNS layer is worth the setup cost. It's not complex, it's just deliberate.

The real lesson isn't "build your own DNS." It's: understand what you're outsourcing and whether the trade-offs are acceptable for your specific situation.

For us, they weren't. So we built it ourselves.


Expanse is a hosting and infrastructure company with nodes in Frankfurt, New York, Singapore, and Johannesburg. We offer dedicated and managed hosting, plus authoritative DNS hosting on our own anycast-style mesh. Get in touch if you want your apps and your DNS on the same operator.


Published April 22, 2026