How We Built a Fully Independent DNS Cache Edge

Last month we completed a rearchitecture of our Authoritative DNS edge network, bringing the entire cache edge network onto infrastructure we operate ourselves. Before explaining why and how we made that change, it's worth understanding how the previous architecture came to be.

In 2014, we were running our own anycast network across 5 points of presence, with hardware-based DDoS defense in front of it. That defense held up against most attacks, but not every one. A major DDoS attack that year took our entire system down. Cloudflare was still a startup at the time, and one of their product engineers reached out to offer help. We placed their DNS Firewall in-line as a caching layer to defend against the next attack.

That arrangement worked well for years, and it bought us time to grow. As DNSimple matured, so did our expectations for what our own infrastructure should give us: visibility into queries and control over our routing decisions. Cloudflare's edge couldn't offer that. It became a black box to us. Some attacks slipped through and caused outages that were more difficult to diagnose without visibility into their edge. A proposed price increase made the arrangement even harder to justify. We decided it was time to build the edge we actually wanted, rather than keep renting someone else's. Our customers wanted the same thing: independence from Cloudflare, AWS, and the other hyperscalers, not another vendor lock-in. We were ready to give it to them.

A little over three years ago, the platform team began rearchitecting our authoritative DNS infrastructure around a cache edge we would build and operate ourselves. By late 2024, the cache edge powering NS2 and NS4 was on our own infrastructure, and we published a post explaining why we'd landed on a 50/50 split: half our cache edge on our own network, half on Cloudflare's. That post also said we planned to stay there. We operated that way for a couple of years, but last year we decided to complete the architecture by bringing all four nameservers onto infrastructure we own, instrument, and operate end to end. By the end of July, this migration was complete, with all four nameservers running on our internally operated cache edge network.

Now every DNS query for your zones travels exclusively across infrastructure we build, own, and operate ourselves. The remainder of this post is about why we made that call, what it took to get there, and the challenges we encountered along the way.

Why the 50/50 split was a ceiling, not a destination

The 50/50 architecture worked well in narrow technical terms: DNS cache performance was solid, we had meaningful point-of-presence diversity, and DDoS protection was functioning at our caching edge layer. The structural problem was routing control. Cloudflare owned the IP addresses behind NS1 and NS3, which meant we had no ability to influence how traffic was handled across half of our edge layer. We couldn't push mitigation rules, adjust BGP announcements, or inspect what was happening at the edge layer for that traffic. Bringing our own IP address space to run through the DNS Firewall had been part of the original plan, but this feature never materialized, and we were never able to announce our own IP prefixes through their infrastructure. If we'd ever needed to move away from the DNS Firewall, whether for pricing, a service disruption, or a strategic shift, we'd have faced a year or more of migration lead time, because the IP space belonged to them, not us.

The operational frustration was more immediate. As the platform team built out DDoS signature detection and query-level telemetry at our own cache layer, the Cloudflare side of our cache edge network became a gap we couldn't close. We could detect anomalous query patterns, build mitigation rules, and push them across our own infrastructure in real time. That only covered half the traffic. The other half flowed through an edge layer we couldn't see into or act on.

Those concerns proved to be more than theoretical. As we prepared to move NS1 and NS3 onto the new edge, we asked how the IP addresses serving the DNS Firewall would respond to queries when we removed the configuration. It took weeks and several follow-up emails to get an answer from an engineer. For infrastructure serving authoritative DNS for our customers, that response time on a seemingly simple operational question was a manifestation of the very problem we had anticipated.

The 50/50 split was never the destination. It was only as far as we could see from where we were standing. We now had the operational knowledge to complete the move, and we were ready to take it.

Finding infrastructure that could support what we needed

Expanding our anycast network meant finding bare metal providers capable of supporting a BGP-based anycast setup with global coverage. Our requirements were specific: bare metal (not virtualized), BGP-capable, a global footprint, and capacity available on demand.

That combination ruled out most of the market. Most cloud providers don't expose the BGP access anycast requires. Managed hosting providers rarely expose it either, since they don't own the routing layer themselves. Co-location at scale is expensive and slow to provision. Contract negotiations alone to deliver 16 points of presence would have exceeded our project timeline.

We approached this evaluation twice.

Our first attempt to qualify a new provider didn't go well. The vendor's networking team struggled to validate our BGP configuration within our PoC window, and we couldn't get clarity on the issues. The team made the call to walk away and restart with more structure.

The second evaluation was deliberate. We contacted eleven providers, documented our technical requirements formally, built a Terraform-based validation framework, and confirmed BGP session establishment and anycast prefix advertisement capability before making any commitment. We narrowed the field to two: Vultr, which was already powering the cache edge for NS2 and NS4, and Latitude.sh, which had the global footprint we needed and worked with us directly to confirm BGP support. Latitude.sh was willing to engage at the technical level the project required, and that mattered.

Splitting our cache edge across multiple independent providers instead of standardizing on one was intentional too. Provider diversity was a design requirement. Running the edge across two independent providers reduces the operational exposure that comes with concentrating infrastructure with a single company.

What you cannot test until you go live

Once infrastructure was in place and BGP sessions were established, we began bringing Latitude.sh PoPs online into the anycast setup. And then we ran into something no pre-deployment testing could have caught.

Anycast routing works by advertising the same IP prefix from multiple locations simultaneously, with BGP routing each incoming request to the nearest available node. What you can validate in advance: BGP session establishment, prefix advertisement, and local routing behavior. What you cannot validate in advance: how carriers on the other side of the internet will handle your traffic once it is actually flowing.

When traffic started arriving at Latitude.sh nodes, some of it was being silently dropped.

Latitude.sh's upstream transit providers, Cogent and GTT, were applying Unicast Reverse Path Forwarding checks to traffic arriving at those nodes. uRPF is a routing security mechanism: a carrier receiving a packet checks whether the source address would be reachable via the interface the packet arrived on. If not, the packet is dropped. In an anycast deployment, this creates a specific failure mode. Traffic that originated via one routing path and arrived via another can fail the uRPF check at the transit layer, even though the routing is correct from the anycast operator's perspective. You have announced a prefix from multiple locations. BGP has done its job and directed traffic to the nearest node. But the carrier between the sender and that node doesn't know that, and its filtering logic rejects the packet.

This is not a niche failure mode. uRPF-related issues have caused significant outages at large network operators. It is a known-unknown of anycast deployments: you can validate your own routing in every detail, but you cannot know how a carrier on the other side of the internet will handle your traffic until it is live.

When we inherited Latitude.sh's upstream transit relationships, we also inherited their upstream routing topology, and the uRPF interaction that came with it. We worked directly with Latitude.sh and their upstream providers to resolve it, coordinating with Cogent and GTT on how uRPF was applied to our prefixes at their peering points.

It took real coordination across multiple parties to get right, but the affected traffic was a small fraction of the total, and our cache edge as a whole kept resolving normally throughout.

The experience exposed a visibility gap that went beyond that one case: BGP session state tells you what you've announced. It doesn't tell you what the internet actually sees. We've since expanded our monitoring footprint using RIPE Atlas and routing data from multiple vantage points distributed across the global routing table, giving us external visibility into how our prefix advertisements propagate from perspectives outside our own network. When a carrier is not routing our traffic as expected, we can now detect it from an external reference point before it surfaces as a customer complaint.

What the cache edge looks like now

With the cache edge powering all four nameservers on infrastructure we own, the capabilities the platform team has built over the past three years now apply across the entire cache edge.

We have edge-layer visibility across all nameserver traffic for the first time. When query patterns on a customer zone look anomalous, we can see it and act on it without routing a request through a third party. DDoS signature detection runs at the cache layer, before queries reach the resolver. We can now push configuration changes and mitigation rules across our entire infrastructure directly.

Our edge runs across two independent providers, Vultr and Latitude.sh, distributed across 16 points of presence. A failure or disruption at one provider would affect only a portion of our traffic, and DNS responses continue from the remaining nodes. The anycast routing layer handles traffic distribution automatically, without requiring changes at the customer level.

For customers and developers using DNSimple's DNS hosting and automation APIs, this means the infrastructure responding to queries for your zones is infrastructure we instrument and operate end to end, with no third-party black boxes in the path. DNSimple is now a reliable option with real human support that you can choose if you would like to be completely independent from the major hyperscalers like Amazon and Cloudflare for your DNS services.

What's next

The edge domains for NS1 and NS3 launched with DNSSEC enabled from the start. We've offered DNSSEC to customers for years and advocate for it as a meaningful security layer. It is long past time to apply that standard to our own infrastructure. Enabling DNSSEC on the dnsimple-edge.com and dnsimple-edge.io domains required the NS1 and NS3 migration to complete first, since those domains couldn't be signed while traffic was still flowing through Cloudflare's stack. Signing dnsimple-edge.net and dnsimple-edge.org is next, which will complete DNSSEC across all four nameserver domains.

We're approaching this deliberately. Each edge domain's annual key rotation is scheduled in a separate calendar quarter so no two rotation windows overlap. A missed KSK rotation on a nameserver infrastructure domain is not the same as missing one on a customer zone. If you can't resolve our nameservers, nothing else works. We use the same automation we provide to customers and apply the same care we'd expect from any large operator.

The uRPF experience also put a longer-term project on our roadmap: adding a secondary autonomous system. Operating under a single AS means our prefix announcements flow through a single set of upstream transit relationships. A secondary AS would let us announce prefixes through independent upstream paths, reducing exposure to uRPF filtering scenarios like the one we hit with Latitude.sh. It's a substantial undertaking, and we're still in the planning stages.

Sixteen points of presence is not the end. We'll continue qualifying new locations and providers and will share updates as the network expands.

Updating your nameserver configuration

If you're pointing to ns1.dnsimple.com or ns3.dnsimple.com: the IP addresses behind those records have already been updated to our new infrastructure, so you're already routing through our edge.

For now, those hostnames remain in place for legacy configurations. However, we strongly encourage everyone to migrate to the new edge hostnames to take advantage of DNSSEC support and a more diversified TLD distribution, further reducing the remaining single point of failure.

If you have those IPs hardcoded anywhere, you'll need to update them. The NS1 and NS3 IP discontinuation announcement has the full timeline.

The canonical hostnames for all four nameservers are now:

• ns1.dnsimple-edge.com
• ns2.dnsimple-edge.net
• ns3.dnsimple-edge.io
• ns4.dnsimple-edge.org

Each nameserver uses a separate domain across a different TLD to limit exposure to any single registry-level DNS outage.

Owning our entire authoritative DNS infrastructure is not only an operational win for us, it is a choice we can now offer you. A large share of the internet already routes its DNS through the same handful of companies that host half the web. If you would rather not concentrate your DNS in the same place as everyone else, DNSimple is now a fully independent alternative, instrumented and operated by a team you can actually reach.

If you have questions about how this affects your configuration, or you just want to talk DNS infrastructure, get in touch.

Not using DNSimple yet? Give us a try free for 30 days.

Share on Twitter and Facebook

Jonathan Temple

Adrenaline fueled bike nerd and constructive troublemaker.