Most “decentralized” projects still trust Cloudflare to resolve their domains. We did too — until we realized that defeats the entire point.
This is the story of how DeBros moved away from Cloudflare and built a fully self-hosted DNS system into the Orama Network — and how AnChat’s backend infrastructure already runs on it.
The Problem With Cloudflare
Cloudflare is great. It’s fast, reliable, and free for most use cases. But it’s also a single company sitting between your users and your infrastructure.
When you put your domain behind Cloudflare, you’re trusting them to:
- Resolve your domain correctly
- Not censor your content
- Not go down (they have — multiple times)
- Not comply with a takedown request that kills your project overnight
For a privacy-first messaging app, this is a non-starter. If one company can flip a switch and make your app unreachable, you’re not decentralized. You’re just using a different centralized provider.
We needed DNS that works like the rest of Orama Network: distributed, self-healing, and under nobody’s control but ours.
What We Built
Every Orama Network node can run as an authoritative nameserver. When you install a node with the — nameserver flag, it spins up CoreDNS — the same DNS server that powers Kubernetes clusters worldwide — backed by our distributed SQL database (RQLite).
Here’s the architecture:
CoreDNS handles the DNS protocol — receiving queries, responding with records, caching responses.
RQLite stores all DNS records in a distributed SQL database replicated across every node via Raft consensus. When you add a DNS record on one node, every other node sees it within seconds.
Self-healing heartbeats ensure the system stays accurate. Every 30 seconds, each node:
- Confirms its own DNS records exist (and recreates them if they don’t)
- Checks if other nodes are still alive
- Removes DNS records for dead nodes automatically
No manual intervention. No stale records pointing to servers that went offline three weeks ago.
How It Actually Works
When AnChat’s backend needs to resolve its namespace — ns-anchat.debros-orama.network — here’s what happens:
- The query hits our authoritative nameservers: ns1.debros-orama.network — ns2.debros-orama.network — ns3.debros-orama.network — three independent Orama Network nodes with glue records set at the registrar
- CoreDNS on that node queries RQLite, finds the A record, and responds
- If that node is down, the query automatically falls through to ns2 or ns3
Three nameservers on three independent VPS nodes. No single point of failure. No Cloudflare in the middle.
Wildcard DNS & Automatic SSL
The system supports wildcard DNS out of the box. Every node gets its own subdomain pattern — like *.node1.dbrs.space — so deployed apps automatically get DNS without anyone manually creating records.
SSL certificates are handled through ACME DNS-01 challenges. When Caddy (our HTTPS server) needs a certificate for a new subdomain, it writes a TXT record directly into CoreDNS via the gateway API, Let’s Encrypt verifies it, and the certificate is issued. No Cloudflare API tokens. No external DNS provider. The whole chain is internal.
The Self-Healing Part
This is where it gets interesting. Traditional DNS is static — someone sets records, and if they break, someone has to fix them.
Orama DNS is alive. Every node continuously ensures its own records are correct:
- Node comes online? It registers itself in the dns_nodes table, creates its A records, and claims an NS slot (ns1, ns2, or ns3) if one is available.
- Node goes offline? Other nodes detect the missing heartbeat after 2 minutes, mark it inactive, and remove its A records from the round-robin pool. Dead IPs never get served to users.
- Database gets reset? The SOA and NS records are regenerated automatically on the next heartbeat cycle.
- Bad records from old code? A cleanup routine scrubs private IPs (10.0.0.x, 192.168.x.x) on every heartbeat — leftovers from an earlier bug we fixed.
The DNS system heals itself the same way the rest of Orama Network does. No ops team babysitting it at 3am.
AnChat Already Runs On This
AnChat’s backend namespace — ns-anchat.debros-orama.network — is resolved entirely by our own nameservers. The gateway, the messaging infrastructure, the deployment routing — all served through DNS that we operate on Orama Network nodes.
The public-facing anchat.io domain still uses traditional DNS for now. But the actual infrastructure underneath — the part that routes your messages, handles authentication, and runs the decentralized backend — that’s already on our DNS. No Cloudflare in the chain.
When we say AnChat is decentralized, we mean the full stack:
- Messaging: Decentralized — routed through independent Orama Network nodes, no central servers
- Identity: Wallet-based, no email or phone
- Metadata shielding: ANyONe Protocol onion routing
- Infrastructure: Orama Network distributed nodes
- DNS: Our own nameservers resolving the backend namespace
Most projects claiming decentralization still have a Cloudflare dependency hiding in their infrastructure. We’re removing ours — layer by layer.
Why This Matters
DNS is the most overlooked single point of failure in the decentralization stack. Your app can run on decentralized infrastructure, your data can be encrypted end-to-end, your code can be open source — but if Cloudflare resolves your domain, one compliance email can take you offline.
Running your own DNS isn’t easy. You need multiple nodes for redundancy, proper glue records at the registrar level, health monitoring, and automatic cleanup of stale records. We built all of that into Orama Network so that any project running on our infrastructure gets sovereign DNS by default.
No middlemen. No kill switches. No asking permission to exist on the internet.
That’s what infrastructure sovereignty actually looks like.
DeBros builds privacy-first infrastructure. AnChat is our first app — decentralized messaging with zero metadata collection. Try the beta at anchat.io
Top comments (0)