DNS Documentation

v.recipes DNS started as an internal experiment — a DNS-over-HTTPS proxy built on Cloudflare Workers to see how far we could push edge-computed DNS. The project grew out of frustration with traditional resolvers that either logged queries, lacked modern transport support, or buckled under bursty traffic.

We released it publicly in 2024 under the domain 0ms.dev, and later transitioned to v.recipes as the service expanded. What began as a single unfiltered endpoint now spans eight variants, each tuned for a different use case.

Most users rely on whatever DNS resolver their ISP assigns by default. These resolvers are often unencrypted, may log queries, and can inject or redirect results. Even popular public resolvers like Google DNS or Cloudflare 1.1.1.1 have trade-offs — rate limits, lack of ECS support in certain configurations, or suboptimal routing for some regions.

v.recipes addresses these gaps with a layered caching architecture, per-request pacing to prevent upstream congestion, and a strict no-logging policy. If you care about DNS privacy, performance under load, or need a resolver that works well from regions with restrictive networks, v.recipes is designed for you.

v.recipes does not log DNS queries. We do not record the domains you resolve, the IP addresses you connect from, or any metadata that could be used to reconstruct your browsing history.

Aggregate, anonymised metrics (total query counts, cache hit ratios, latency percentiles) are collected for operational monitoring. These metrics contain no personally identifiable information and cannot be tied back to individual users or sessions.

Our full privacy practices are described in the Privacy Policy.

v.recipes is deployed on Cloudflare's global anycast network, spanning 300+ data centres across 100+ countries. When you send a DNS query to v.recipes, it is routed by BGP to the nearest Cloudflare PoP — typically within a few milliseconds of your location.

This means there is no single point of failure and no need to "choose a server." The network handles failover and load-balancing automatically. Whether you are in Jakarta, Berlin, or Sao Paulo, your query hits a nearby edge.

See the Anycast vs Non-Anycast illustration →

v.recipes uses a multi-layer caching strategy to minimise upstream queries and deliver the fastest possible response times.

• L1 Cache (Edge) — Each Cloudflare Worker maintains an in-memory cache scoped to the individual isolate. Hot queries are answered directly from memory with sub-millisecond overhead.
• L2 Cache (Regional) — Backed by Cloudflare's Cache API, the L2 layer shares cached responses across all Workers in the same data centre. This dramatically reduces upstream lookups for popular domains.
• Upstream DNS — On a cache miss at both layers, the query is forwarded to the configured upstream resolver (e.g., Cloudflare 1.1.1.1, Google DNS). The response is then stored in both L1 and L2 for subsequent requests.

This architecture achieves cache hit rates above 90% for most deployments, meaning the vast majority of queries never leave the edge.

See the Cache Efficiency illustration →

v.recipes integrates lightweight machine-learning models at the edge to improve DNS outcomes without adding latency. Current applications include:

• Malicious Domain Detection — A compact classifier trained on known-bad domain patterns identifies suspicious queries in real time. This supplements upstream blocklists with heuristic detection of newly-registered or algorithmically-generated domains (DGAs).
• Predictive Prefetching — By analysing aggregate query patterns, the system can proactively refresh cache entries for domains likely to be requested soon, reducing cold-cache latency for popular sites.
• Adaptive Pacing Tuning — The per-request pacing parameters are periodically adjusted based on observed upstream latency and error rates, ensuring optimal throughput without triggering provider rate limits.

All inference runs within the Cloudflare Worker — no data leaves the edge for ML processing.

See the AI/ML illustration →

DNS providers like Google Public DNS impose rate limits — typically around 1,500 queries per second per source IP. When multiple users share the same proxy or resolver, it is easy to exceed these limits, resulting in dropped queries and degraded reliability for everyone.

v.recipes solves this with per-request pacing: a token-bucket rate limiter applied at the individual request level before any query is forwarded upstream. The default ceiling is 1,000 requests per second per upstream provider.

The result is a consistent, predictable query rate that stays well within upstream provider limits — even under heavy load. Individual users experience minimal or no added latency because the vast majority of queries are served from cache before pacing is even relevant.

The ECS Optimized variant is a practical example: Google Public DNS enforces a 1,500 QPS cap, but v.recipes' caching layer absorbs the bulk of traffic, and pacing ensures the remaining upstream queries never trip the limit.

See the Per-Request Pacing illustration →

Whether you are configuring DNS for a single device, a home network, a small business, or a large enterprise deployment, v.recipes scales automatically. The anycast network, multi-layer cache, and per-request pacing work together to deliver consistent performance regardless of query volume.

• Single device — Point your system DNS to v.recipes via DoH for encrypted, private resolution.
• Home network — Configure your router to use v.recipes as the upstream resolver for all connected devices.
• Enterprise / ISP — Use the Accelerator or Multiqueue variants for high-throughput deployments with custom upstream selection.