Dinio DNS · Marcel Bandić · · 5 min read
Why We're Building Another DNS
The internet keeps growing — more services, more devices, more traffic every year. What’s less talked about is that it’s also getting more fragile. A growing share of that traffic depends on a small number of providers. And DNS is involved in a remarkable share of internet interactions, often before the application layer can do anything useful. This post is about why that combination worried us enough to start building Dinio DNS, and what we think a healthier internet looks like instead.
DNS stopped being just a phone book
The textbook description of DNS — “it turns domain names into IP addresses” — undersells what it actually is today. Many website loads, app connections, IoT check-ins, and service-to-service requests depend on DNS at some point — often before the connection to the destination can even begin. It’s less a phone book and more a nervous system: a layer that nearly everything on the internet still routes through before anything else happens.
That position is exactly what makes DNS interesting to build on. If you can see a query before a connection exists, you can act on it — resolve it, redirect it, or refuse it — earlier and more cheaply than almost anywhere else in the stack.
The first line of defense
That early position is also why DNS has quietly become a security layer in its own right. When a client relies on a resolver that filters known-bad domains, blocking one at the DNS level can stop that client from ever obtaining the address it needs to reach that destination — many known phishing, malware, ransomware, and command-and-control domains can be blocked this way, before the client attempts the usual connection to them[5]. It’s a signal-based control, not a complete defense — plenty of traffic never touches such a resolver — but it matters most on exactly the devices that are hardest to protect any other way: IoT hardware, personal phones, guest networks, many of which can’t realistically run a conventional endpoint security agent, and all of which still make DNS queries.
None of this replaces a firewall or endpoint protection, and it isn’t the whole picture. DNSSEC lets resolvers validate the authenticity and integrity of signed DNS data; it doesn’t encrypt DNS traffic — DoH and DoT address the separate problem of protecting the connection between a client and its resolver. But as an early, cheap checkpoint, DNS is one of the better places to catch trouble before it becomes expensive. And there’s more trouble to catch: in the first half of 2026, DNS floods and amplification made up 34.3% of the network-layer DDoS activity Cloudflare tracked, and attacks exceeding 1 Tbps got more than six times more common from Q1 to Q2[3]. That makes an early defensive layer increasingly valuable, especially for devices and networks that lack deeper security controls.
A market that’s catching up to that reality
The technical argument above is the real motivation, but for what it’s worth, the market is catching up to it too. One estimate puts managed DNS at $1.35 billion in 2025, projected to reach $3.10 billion by 2030 — an 18.16% compound annual growth rate[4]. Estimates like this vary a lot by methodology and by how “managed DNS” gets defined, so we’d treat the number as directional, not definitive: a sign there’s real, growing demand, not the reason we’re doing this.
What happens when too much depends on too few
The part that actually worries us is concentration. When a large share of DNS, CDN, and edge traffic sits behind a small number of providers, a single configuration mistake can ripple across a meaningful fraction of the internet — not because anyone was attacked, but simply because one system changed.
Two recent examples make this concrete. On November 18, 2025, a bad configuration file, generated automatically and propagated across Cloudflare’s network, caused errors across a large share of their traffic for several hours[1]. Seventeen days later, on December 5, a separate change exposed a bug in their newer proxy code, causing failures for the subset of customers on that proxy version — about 28% of the HTTP traffic Cloudflare serves — for roughly 25 minutes[2]. Neither incident was an attack. Both were the kind of ordinary operational failure no infrastructure provider can honestly claim to be immune to — including us. The lesson isn’t that any one provider is doing a bad job. It’s that when enough of the internet’s plumbing runs through the same few pipes, an ordinary mistake in one place turns into a global one.
We’re not here to replace the giants
We’re not building Dinio DNS to dethrone anyone, and we don’t think that’s even the right goal. A healthier internet doesn’t need one giant swapped for another — it needs more independent, interoperable infrastructure that isn’t all one failure domain. More providers who can be a real secondary or failover, not just a logo on a comparison page. That’s a genuinely useful thing for a small, focused team to build well, without needing to boil the ocean.
Where we are, and what’s next
We’re still heads-down building — this isn’t a launch post, it’s an introduction. Over the coming months we’ll be writing a lot more about these topics, and about how we’re actually designing Dinio DNS and the trade-offs we’re making along the way. If any of this is a problem you think about too, we’d like to hear from you.
Sources
Get new posts by email
Technical notes on our DNS platform and engineering work, sent when we publish. No spam.