Why Bunny DNS is Removing Core Network Fees

Most DNS providers treat basic connectivity as a profit center. They charge you for the privilege of your traffic actually reaching your server, adding layers of cost to a service that should be a utility. It's a frustrating way to run a business, and it makes the web slower for everyone. We've decided to treat connectivity as a prerequisite instead.

I've spent a lot of time looking at how the big players handle this, and the math rarely adds up for the developer. You end up paying for "premium" tiers just to get reasonable latency. We're trying something different by removing those friction points entirely.

It sounds simple, but moving the needle on global resolve times without breaking the bank is a messy engineering challenge. The question is whether we can actually maintain that performance at scale without eventually sliding back into the same pricing traps.

The Toll Booth Problem

Charging for basic DNS is a bad move. When you put a paywall in front of routing, you're essentially charging a toll for the road to your application. DNS is the most basic piece of infrastructure in the stack; it's a utility. Making developers pay for simple record management or basic health checks creates friction that doesn't add value to the product, it just adds a line item to the monthly bill.

The real frustration is that most "premium" DNS features are just basic automation wrapped in a UI. For example, updating an A record via an API shouldn't be a paid tier feature. It's a simple HTTP request to a nameserver. When companies gate this, they aren't selling a better technology; they're just taxing a common workflow.

This part is genuinely confusing because providers claim they're charging for "reliability" and "global distribution." But the reality is that any decent DNS provider uses anycast routing to ensure your records are available globally. If you're paying extra for "premium" propagation, you're paying for something that should be the baseline.

If you want to avoid these tolls, you can manage your own records using a simple tool like dig to verify changes or a basic script to automate updates.

dig @8.8.8.8 example.com A

Most developers just want a predictable way to point a domain to an IP address. It's not a complex problem, and treating it like a luxury service is a mistake.

Performance Over Profit

Removing the cost barrier for network access is the only way to actually increase network density. When you stop charging per-request or per-gigabyte for the edge, more developers deploy their logic closer to the user. This creates a virtuous cycle: more nodes mean shorter physical distances for data to travel, which is how you actually get low latency.

This part is genuinely confusing because most people think of "the cloud" as a few giant data centers. In reality, a global network is only as fast as its closest Point of Presence (PoP). If you have 100 PoPs instead of 10, the average distance to the user drops significantly.

To get a project running on a distributed edge network, you usually start with a simple deployment command. Here's how you'd push a function to a global edge using the Wrangler CLI for Cloudflare Workers:

npm install -g wrangler

wrangler deploy index.js

The result is that your code is mirrored across hundreds of locations. It's a bit unsettling how much we rely on this "magic" infrastructure, but the math is simple: speed is a function of geography. If the server is 10 miles away instead of 1,000, the latency is lower. Period.

How it Works

Migrating to Bunny DNS is a matter of updating your nameservers at your registrar. You aren't moving individual records one by one; you're handing over the authority of your domain to Bunny's infrastructure. This is the part that usually makes people nervous because a mistake here can take your site offline. It's a legitimate risk, but the process is straightforward if you verify your records before switching.

First, add your domain to the Bunny DNS dashboard and copy the assigned nameservers. Then, replace your current nameservers at your registrar with these two:

Once you've updated the records, the transition isn't instant. DNS propagation can take anywhere from a few minutes to 48 hours, though it's usually fast. I've seen it happen in ten minutes and I've seen it take a full day. You can check if the change is live using a tool like dig or a web-based DNS checker.

dig NS yourdomain.com

If the output matches the nameservers Bunny gave you, the migration is complete. If you're seeing old records, you're just waiting on the TTL (Time to Live) to expire. There's no way to speed that up once the change is made.

The Strategic Trade-off

The move to drop DNS query fees is a tactical win for bunny.net, but I think the broader "Cloudflare alternative" narrative is oversimplified. For a small project or a developer who just wants a reliable zone file without a monthly bill, this is a no-brainer. But for enterprises, the draw isn't just the price of a query; it's the integrated security stack and the sheer scale of the edge network. Bunny is carving out a specific niche for people who are tired of the "everything-store" approach to infrastructure and want a leaner, more transparent cost model.

I've seen a lot of noise on X and Reddit about this being a "Cloudflare killer," which is a stretch. Cloudflare has too much gravity in the enterprise space for a fee change to shift the needle on a macro level. That said, the EU-based positioning is a legitimate advantage. GDPR isn't just a checkbox anymore—it's a persistent headache—and having a provider that doesn't force everything through a US-centric pipeline is a practical relief for European devs.

The real question is whether bunny.net can maintain this aggressive pricing as they scale their own infrastructure. It's easy to be the affordable alternative when you're the challenger, but I'm curious if they'll eventually hit a ceiling where the margins on free or cheap DNS force them to monetize the edge in ways that make people miss the old pricing.

Conclusion

Bunny DNS is fast, and it's free. For most of us, that's the only metric that actually matters. The "Toll Booth" risk is a real strategic concern for a company, but for a developer just trying to shave 20ms off a request, it's a theoretical problem.

I'm still not convinced that the trade-off is a dealbreaker for everyone, but I do wonder: at what point does the convenience of a free, low-latency provider outweigh the desire to own your own infrastructure?