The DNS Hosting Pivot

Quick note before you read this one: UDNS Hosting is in partner preview right now, not a full release. It's already been tested plenty on my end, but a handful of MSPs have it live on real client zones too now, because real workflows still turn up things a test environment never will. This is what building it has looked like so far.

The Wall I Kept Hitting

Someone asked me in a meeting a while back why nobody had already built this. I didn't have a great answer at the time. The best one I've got now is that it's easy to build a platform assuming every DNS provider and registrar will just hand you API access, and some of the biggest ones flat out won't.

The whole idea behind Unified DNS was managing every provider from one place, Cloudflare, Route53, Namecheap, whatever the client's already on, point the platform at it and stop juggling ten different dashboards. That only works if the provider actually lets you in, though.

Most do. Some really don't, and GoDaddy is the worst offender. Their Management and DNS APIs aren't gated behind anything I can buy or negotiate on my end, the gate sits on the client's own GoDaddy account. They need 10 or more domains in that single account, or they're paying GoDaddy a monthly subscription just for API access (the Discount Domain Club Domain Pro Plan, if you're curious what that's called). The Availability API wants 50 domains or more. Most small business clients aren't anywhere close to that, and there's no reason for them to pay GoDaddy extra just so their MSP can automate changes. Network Solutions and Squarespace have their own versions of the same wall.

Here's the thing though, most MSPs I talked to didn't actually care about GoDaddy's API restrictions for their own sake. What they cared about was that if 30 of their clients were sitting on GoDaddy, those 30 couldn't be onboarded to UDNS, and that's the whole platform falling short of what it's supposed to be, one dashboard for every client domain. They got it, there wasn't much I could do about it beyond monitoring those domains from a distance, but monitoring isn't managing, and that gap kept coming up in conversation after conversation.

The workaround never really changed either: move the domain's DNS somewhere else, then connect that somewhere else to UDNS. It worked, but it was still an extra step, and an extra migration, for every domain stuck behind one of these walls.

What MSPs Kept Telling Me

This pivot didn't start with me sitting down and staring at a whiteboard, it started with conversations. Once "move the DNS somewhere else, then connect that to UDNS" became the standard answer often enough, it got hard to ignore the obvious next question: why not cut out the middleman and just let UDNS be that somewhere else? Same result for the client, minus the extra hop.

That's UDNS Hosting. It's not replacing the multi-provider management the platform already does, it just means a client's domain can point its nameservers straight at UDNS and get managed in the same place as every other client domain, regardless of where it happened to get registered.

The Decision That Took Longer Than the Code

This has been the main thing I've been working on since the middle of May, and here's honestly where most of that time went. Someone asked me recently what the hardest part of building this was, and I told them:

"Honestly, the worst part was trying to decide where to host the nameservers. Do I put them in the same cloud provider? Even if in different regions, that still introduces a single provider outage. If I put them on different cloud providers, that introduces more complexity when it comes to management of the backend, especially with getting ns1 and ns2 to replicate DNS zones to each other."

That's basically the whole problem, and I sat with it a lot longer than I'd like to admit. Same cloud provider, different regions, is simpler to build and run, but if that provider has a bad day everywhere, both nameservers go down together and "geographically redundant" doesn't mean much anymore. Different providers actually solves that one, but then replication has to cross infrastructure that was never designed to talk to itself, and a database problem turns into a networking problem, which eventually turns into me getting paged at 2am.

Underneath all of that was the database question. Do I run my own Postgres and own the replication myself, or just lean on a managed DNS API from a cloud provider and not worry about owning that layer? What actually tipped me toward self-hosting was looking at what happens when someone else builds a DNS feature on top of a third party's API. SkyKick's DNS Manager is a good example of exactly that going wrong. It's a free tool for migration projects, built on top of a third-party DNS host. ConnectWise bought SkyKick last year, so the tool has the ConnectWise name on it now, but the problem predates the acquisition. By June 2023 that third-party API had gotten unreliable enough that ConnectWise made the whole tool read-only and told customers to go transfer their DNS hosting somewhere else, because they couldn't even guarantee changes made in the tool would reach the nameservers anymore, and there was nothing they could do to troubleshoot it. That's what happens when you build on an API you don't control, you can't fix reliability that isn't yours, and when it breaks you're the one telling customers to leave. A managed DNS API would've taken some of the operational weight off me short term, sure, but underneath it, it's basically the same song and dance I'd already decided wasn't good enough with GoDaddy and the rest, just with bigger consequences if that third-party API changed on me down the line. And underneath even that: is Anycast worth chasing right now, or is that a problem to solve later once there's enough traffic to justify it?

None of these had a clean right answer. Just trade-offs, and each one changed how much operational complexity I'd be stuck owning long-term.

Landing on an Answer

Here's what I landed on. ns1 and ns2 run as a redundant pair, split across separate regions, connected over private network peering so replication traffic stays on the private backbone the whole way. Same cloud provider, but the regional split is real, a regional outage doesn't take both nameservers down at once, and that peering solved the "different providers can't talk to each other" problem for me without me having to build that myself. Postgres runs underneath it, ns1 as the primary handling writes and the management API, ns2 as a streaming replica handling reads. Sub-second replication lag, independent backups on both nodes, and ns2 can get promoted to primary in a few minutes if ns1 has a bad day. DNS resolution doesn't even have to wait on that promotion, either, ns2 is already authoritative, so client domains keep resolving the whole time no matter what. Only the management API goes down until the promotion finishes.

I decided against chasing Anycast, at least for now. It's a real improvement and it's not off the table forever, but it's the kind of complexity that only earns its keep once there's enough zone volume to actually need it. Building it in before I had a reason to would've meant solving a problem I didn't have yet, instead of shipping the one I did.

Owning the database instead of leaning on a managed DNS service ended up being the call that mattered most, even with more infrastructure to run because of it. It's the whole reason quick restore and full audit logging exist at all, every record change is a row I actually control, not a response coming back from someone else's black box.

Locking It Down

Owning the infrastructure means owning the attack surface too. Before UDNS Hosting ever touched a real client zone, I spent a good chunk of time just trying to break my own setup.

I'm not going to lay out exactly how everything's locked down here, that's not something I want sitting in a public post as a map for anyone curious enough to go looking for the gaps. What I'll say instead: nothing sensitive on either node is reachable from the open internet, access is layered so no single control being wrong hands someone the whole system, credentials are unique per node and never shared between them, and every account involved only has the access it actually needs and nothing more.

I went through all of it trying to think like an attacker would, from the network side and from the portal side, forced browser console commands, session manipulation, and other injection attempts included. Nothing got through. I'm working with an MSP partner right now specifically on hardening these endpoints further and getting real monitoring in place across the nameserver infrastructure, because my own testing only gets me so far.

The Easier Parts

Compared to all that, everything else was just work. Building the three ways to bring a zone in (start blank, scan what's publicly resolvable, or import a BIND zone file) was mostly about being upfront with the user about what each path can and can't actually capture, so someone picks the right one instead of assuming a public scan caught everything it didn't. The BIND import gave me a few surprises once I started feeding it real exported zone files instead of the ones I'd hand-written to test against. Leftover artifacts from other providers' flattening behavior that aren't valid to import as-is, SPF and DMARC TXT records that needed more careful handling so a character inside the quoted value doesn't get read as the start of a comment. Nothing dramatic. Just the kind of stuff you only find by actually testing against what's out there in the real world.

DNSSEC actually came together faster than I expected once the signing infrastructure was sitting on both nodes. The DNS engine underneath had its own strong opinions about key types though, so the code had to work around that instead of fighting it. The only manual step left in the whole process is submitting the DS record at the registrar, and that one just isn't mine to automate away.

Where This Leaves Me

The gap I would've flagged here a few weeks ago is actually closed now. A lot of what MSPs do with DNS day to day isn't just records, it's domain forwarding too, the 301 or 302 redirect a client wants when a domain should just point somewhere else, with a valid SSL cert on it so browsers don't throw a warning at their customers. That meant building a dedicated proxy layer in front of the nameservers, with certs provisioned and renewed automatically through the same private validation path the rest of the platform already uses, so there's no manual cert babysitting involved. An MSP can move a redirect-only domain onto UDNS Hosting the same way they'd move a fully hosted one now. Every MSP has a handful of domains sitting around that only exist to redirect somewhere else, and those used to just be stuck wherever they already were.

Owning the authoritative layer also opens up something that didn't exist when Unified DNS was a pure management overlay: direct integrations with other tools in the MSP stack. If something else in that stack ever needs to trigger a DNS change as part of its own workflow, I can only build that cleanly when there's an API on the other end that I actually control. That's a next-phase idea, nothing live yet, but it wasn't even on the table before this pivot.

The part I'm still honestly working out is how to talk about all this. Partner preview is as much about figuring that out as it is about finding bugs, if I'm being real about it. UDNS Hosting is technically a subset of the platform, but it's also the biggest strategic pivot Unified DNS has gone through, period, the shift away from depending on whatever API access a registrar feels like granting, toward infrastructure I actually control end to end. It's not a white-label product, and it's not something I can announce with a screenshot and a line in the changelog. It's a change in what the platform fundamentally is, and the MSPs using it right now are the ones helping me figure out if the way I'd explain that actually lands before I say it to everyone else. It's also the part that quietly removes a dependency MSPs kept telling me was actually hurting them.

I built the infrastructure I'd trust with my own clients' zones. Watching real MSPs actually use it against real client domains is the next part of getting this right. If you've hit the same registrar walls I have, that's exactly the kind of feedback that got this built in the first place, and it's exactly what I need more of right now. Stay tuned.