← Back

Why we built dnswiz

June 10, 2026

We ran our domains across GoDaddy, IONOS, Strato, and a few others. Managing DNS across them was painful enough, and locked down enough, that building our own made more sense than living with it.

For years our domains were spread across the usual registrars and providers: GoDaddy, IONOS, Strato, a couple of others. All of them do DNS, technically. None of them made it something you would want to touch twice.

The day-to-day was bad

Editing a record meant logging into whichever panel that domain happened to live in, each with its own layout, its own idea of what a TTL field should look like, and its own small surprises. There was no consistent way to see or change records across providers, so the same simple task felt different every time depending on where the zone was hosted. For something as load-bearing as DNS, the tooling was an afterthought.

The automation was paywalled or missing

That was the part that really stung. The whole point of how we build now is that you script it: infrastructure in version control, changes through a pipeline, nothing done by hand. With IONOS, API access to your own DNS is a paid add-on, a monthly charge for permission to automate the records you already own. Others had no usable API at all. So DNS stayed the one manual, click-only corner of an otherwise automated stack, and paying extra to fix that felt backwards.

Multi-cloud made it untenable

Then came the requirement that ended it. We were building apps across more than one cloud, deliberately, for resilience. And if your reason for going multi-cloud is to survive one provider's bad day, the thing that steers traffic between them cannot itself sit inside one provider. DNS is that steering layer. Ours was scattered across registrars that could not health-check a target, let alone fail over between clouds.

Route53 trades one lock-in for another

The obvious answer is a cloud DNS like Route53. It is genuinely capable and it has the global load balancing features. But it solves the problem by putting your resilience control point inside AWS. You set out not to depend on a single cloud and end up depending on a single cloud for the exact layer that is supposed to protect you from depending on a single cloud. For us that defeated the purpose.

So we built our own

dnswiz is hosted authoritative DNS that stays neutral about where your infrastructure lives. It is programmable from the first record, the API is the product rather than an upsell, and health-checked global load balancing is built in instead of sold as a tier. Failover pools, geo steering, DNSSEC, and query analytics are all there because we wanted them for our own apps first.

We run our own DNS on it today. If you have felt the same friction, the clunky panels, the API behind a paywall, the resilience layer you did not want to hand to a cloud, that is who we built it for.