OllaDNS: DNS security you configure from code.

#The setup: DNS filtering is a category nobody loves, but every security team needs

DNS filtering is the security primitive almost every modern team has eventually decided they need, and the one almost nobody is happy with. The category exists for a real reason — blocking malicious domains at the resolver layer is one of the cheapest and most effective controls a security team has, because it stops the attack before the connection is even attempted — and the established vendors in it have built genuinely useful products over a decade and a half of incremental work. Cisco Umbrella, NextDNS, ControlD, Cloudflare Gateway, DNSFilter, Quad9 — they all do roughly the same set of things, they all do them at acceptable quality, and they all suffer from the same structural problem: they were designed for an operations model that does not match how a modern AI-native engineering team actually wants to work.

The structural problem is the dashboard. Every established vendor in the category treats the dashboard as the source of truth for configuration. You log in, you click through screens, you change settings, you save. The dashboard is well-designed, the UX is polished, the screens have improved across two decades of iteration. But the configuration that comes out of those screens is not versionable, not diffable, not reviewable, not rollback-able, not provisioned by Terraform, not changed by a CI pipeline on the same merge that ships the application change that needs it. The audit log records what was changed, sometimes records who changed it, rarely records why. The dashboard is the right interface for the operations model of 2008. It is the wrong interface for the operations model of 2026.

The other structural problem is the threat-intel layer. Every established vendor in the category runs an opaque classifier that decides whether a domain is malicious, with vendor-magic threat feeds the customer cannot inspect, score, or argue with. When the classifier blocks a domain the customer needs, the resolution path is to email vendor support and wait. When the classifier misses a domain the customer wanted blocked, the resolution path is to email vendor support and wait. The customer pays for the classifier and cannot read it, cannot tune it, cannot ship a fix against it. The accountability model is wrong for a discipline where the security team has to explain to an auditor exactly why a given DNS lookup was blocked at the perimeter.

OllaDNS exists because the founders watched their own engineering teams — and a growing crowd of AI-native B2B startups across India and the broader Asia-Pacific market — quietly give up on the established DNS filtering vendors for those two structural reasons, and either reluctantly accept the operational drag or build private DNS-blocking tooling from scratch. Both of those answers are worse than the answer the team chose: ship a DNS-filtering platform built for the operations model the buyer actually wants. API-first. MCP-native. Transparent classifiers. Dashboard read-only by design.

#What OllaDNS actually is, in one paragraph and then in detail

OllaDNS is a multi-tenant DNS filtering platform operated as a cloud service by Ollasoftware. Customers point their DoH, DoT or DoQ clients at `dns.olladns.com`, configure their policies through the REST API or through an AI editor connected to the MCP server, and DNS queries that match a malicious-domain rule, a custom block, a DGA classifier verdict, or a typosquat detector match are refused at the resolver — so the malicious connection is never attempted. There is nothing for the customer to install on the platform side; the resolvers, the classifiers, the policy store, the audit log, the analytics — all of it runs on Ollasoftware's own infrastructure under a standard cloud-SaaS model.

Inside the product there are 57 REST endpoints under `api.olladns.com/api/v1`, 54 MCP tools at `mcp.olladns.com` (49 auto-generated from the OpenAPI 3.1 spec, 5 hand-curated workflow tools), a Rust-based query engine, the inline classifier stack, a Postgres + ClickHouse persistence layer, a Caddy front, and a deliberately read-only Alpine.js SPA at `login.olladns.com` for reporting. The full stack is public on GitHub — Rust API, database migrations, FastMCP Python sidecar, Caddy config, dashboard, docker-compose — which is unusual for the category and is part of the team's posture toward transparent infrastructure.

Operationally, the platform is at v0.34 as of May 2026. The team is explicit on the homepage and across the docs that it is pre-customer, pre-revenue, bootstrapped, and looking for 3–5 design-partner teams to take it from working-product to production-validated-product over the next twelve months. That posture is unusual in a category where most vendors hide their maturity behind a wall of pedigree claims, and it is deliberate. The team would rather lose a deal at the top of the funnel than waste a procurement conversation at the bottom of one.

The product is competitively positioned in a specific place. It is not trying to replace Cisco Umbrella at the Fortune-500 security-operations-centre tier (that is a market where vendor pedigree, anycast PoP count, and SOC 2 Type II reports are non-negotiable and OllaDNS will not be the right answer for several quarters). It is not trying to beat NextDNS on consumer ergonomics (NextDNS has spent years on that surface and is genuinely good at it). It is trying to be the right answer for the specific intersection of buyer that no existing vendor serves well: AI-native engineering and security teams who want to operate DNS filtering through code and through their AI agents rather than through a console.

#The "dashboard is read-only" philosophy

The single most important architectural decision the team made was the one they inverted at version 0.19: the dashboard is read-only by design. Not "the dashboard has an API too." Not "the API has dashboard parity." The dashboard cannot change configuration. It shows you what is happening in your tenancy — query logs, threat detections, AI tool usage, device inventory, audit log — but every actual configuration change has to flow through the API or the MCP server. Click a screen, you cannot save a setting. There is no save button.

The reason this matters is that it forces every configuration change to be versionable, attributable, and scriptable from day one. There is no accidental console change at 2am by an on-call engineer that nobody can find later. There is no "I think Sarah turned that off, let me ask her" three months after Sarah left the company. Every mutation in the system carries an actor — either a `user_id` for a human invocation or a specific `api_key_id` for an agent or CI invocation — and that actor is recorded in the audit log alongside the timestamp, the endpoint, the before-state and the after-state of the affected object.

For teams that have grown up on Terraform, GitOps, CI-driven configuration management, and the principle that "the source of truth is what is in the repository, not what is in the console," this model is the obvious correct one and the existing dashboard-first vendors are the legacy outlier. The platform's posture is to treat configuration drift as a category error rather than as an inevitable cost. Every policy change is a commit. Every rollback is a `git revert` and a CI run.

For teams that have not yet made that transition, the model is genuinely the wrong product. The team is explicit about this on the homepage in the "self-disqualify gracefully" section, which is worth quoting verbatim because it is the kind of honesty the category does not usually ship: "Your only operators are non-technical. The dashboard is read-only; config is API/MCP. If your humans don't write code or use AI editors, our product model is wrong for you." Pointing out who the product is not for is, paradoxically, one of the strongest signals that the team has thought hard about who it is for.

#MCP-native from day one, not as a retrofit

Every endpoint on the platform is also an MCP tool. The MCP server at `mcp.olladns.com` exposes 54 tools today — 49 auto-generated from the OpenAPI 3.1 specification using FastMCP, plus 5 hand-curated workflow tools that compose multiple primitives into common security-team operations. The same scoped tokens that gate the REST API gate the MCP surface. The same audit log records both human invocations through the API and agent invocations through MCP, with the calling identity attributed correctly to each.

For an AI-native security team, this changes the operating model. The traditional flow — when a SOC analyst suspects an emerging DGA campaign — is to log in to the dashboard, scan the recent suspicious-domain list, manually identify the cluster, click each suspect to block it, and then update the runbook for next time. The MCP flow is one paragraph in the agent's chat: "show every DGA suspect with score ≥ 0.85 in the last twenty-four hours, group by likely-family, and block the families with more than three suspects." Three tool calls, one human approval, one audit-log entry per mutation. The runbook does not need updating because the agent's prompt is the runbook, and it is versionable in the same repository as the rest of the team's tooling.

The tools available cover the full operational surface: policy management (custom rules, DNS rewrites, blocklist subscriptions, allowlist-only mode, per-tenant protect-list), device management (register, rotate, deactivate, query), threat-intel surface (top DGA suspects, top typosquats against a protect-list, blocked-by-reason rollups, time-series analytics), audit-log query, token management (mint scoped, expire, list, attribute), and event subscription. The five hand-curated workflow tools are the ones that compose those primitives into the operations a security team actually runs as a recurring task — block a list of domains across all tenant policies, rotate a compromised API key set, summarise the past twenty-four hours of threat detections, audit which agent has touched which policy in the past week, and pre-deploy a CI-driven policy change as a dry-run before committing it.

No other vendor in the DNS filtering category ships an MCP server today. Adding one is on the roadmap for several of them; the established vendors will catch up over the next year or two. The advantage the platform has from being MCP-native rather than MCP-retrofitted is structural: the tools are kept in lockstep with the API because they are auto-generated from the same specification, the scope model was designed for agent invocation from the start, and the audit log was designed for the case where the calling actor is an agent rather than a human.

#The threat-intel stack: classifiers you can read

The threat-intel layer is the other place the platform inverts the category default. Established vendors run opaque classifiers backed by proprietary threat feeds the customer cannot inspect; OllaDNS runs feature-based classifiers in Rust whose source code is in the public repository, with confidence scores exposed in the API, and stacks them on top of 67 community blocklists across fourteen categories so the customer can compose whichever combination of signal fits their environment.

The DGA classifier — the one that detects domain-generation-algorithm malware before its callback domain is known to threat-feed vendors — is approximately 280 lines of Rust. It computes feature vectors against each queried domain (Shannon entropy of the labels, n-gram frequency distribution against an English corpus, vowel-consonant ratio, character-class transitions) and produces a score between zero and one. The threshold is tunable per tenant — the default is conservative enough to avoid blocking legitimate randomised CDN domains, and the per-tenant override lets a security team that has acceptable false-positive tolerance push the threshold lower for tighter coverage. Critically, the code is readable: a security engineer can audit the classifier in an hour and either accept it, suggest a fix against it, or fork it.

The typosquat detector is approximately 230 lines of Rust implementing Damerau-Levenshtein distance with Cyrillic homoglyph normalisation. The tenant supplies a "protect-list" of brand domains the team cares about (the company's own domain, the SSO provider, the cloud-console hostnames, the major payment vendor domains, the key SaaS dependencies). The detector scores every queried domain against that list and flags candidates that are within configurable edit distance, especially when the candidate uses Cyrillic glyphs that visually resemble Latin characters. For brand-protection use cases this is the primitive that established vendors charge a separate premium for; the platform ships it as part of the core surface.

Both classifiers run inline at the resolver — meaning the verdict is computed during the DNS query itself, not in a delayed background pass — and both have zero marginal per-query vendor cost because they are CPU work on the platform's own infrastructure rather than calls out to a third-party threat-feed API. The economic effect at scale is meaningful: a vendor whose threat-intel layer is opaque is also a vendor whose threat-intel layer has a per-query cost the customer cannot see; the transparent classifier substantially reduces the cost-per-query the platform has to charge to be sustainable.

Stacked on the inline classifiers are 67 community blocklists across fourteen categories — malware, phishing, advertising, tracking, cryptomining, social-media, gambling, and so on — each of which can be subscribed to or unsubscribed from per tenant, with the lists reconciled every five minutes. The catalogue mirrors the union of the most-respected community-maintained blocklist projects, kept fresh, deduplicated, and exposed through the same API as the rest of the policy surface.

“ The DGA classifier is ~280 lines of Rust you can read in an hour. The accountability model that makes possible — for the customer, the auditor, and the SRE who pages at 3am — is the category change.

#Scoped tokens, audit trail, and the compliance story

For any security tool that ends up in front of an auditor, the question that determines whether it is fit for purpose is not "does it work" but "can you prove what it did." The platform's token model and audit-log discipline are built around that question.

Authentication has two paths. Humans authenticate with JWTs and are assigned one of two roles — `admin` or `viewer`. Agents and CI workloads authenticate with scoped API keys, where each key carries a subset of sixteen permission scopes (`analytics:read`, `policies:write`, `devices:read`, `devices:write`, `threat-intel:read`, `audit:read`, and so on), an explicit expiry timestamp, and a recorded last-used timestamp. The pattern the team encourages is one key per workload — one for the CI pipeline that updates custom rules, one for the SOC tooling that reads the audit log, one for the AI agent that triages threats, one for the partner integration that fans events to a SIEM, one for the read-only dashboard the executive team looks at — each scoped to exactly the operations its workload needs.

Every mutation across the system writes an audit-log row. The row records the actor (the `user_id` for a JWT-authenticated human or the specific `api_key_id` for a scoped-token caller), the timestamp, the endpoint, the request payload after redaction of secrets, the response status, and the before/after state of the affected object. The log is queryable through the API with the same scoped-token model that gates the rest of the platform, and it is exportable in NDJSON or CSV for archival in the customer's SIEM. The `audit:read` scope can be granted to a workload that needs to consume the log without the workload being able to mutate anything else.

For SOC 2 controls that require evidence of change-tracking, segregation of duties, and least-privilege provisioning, this model is what an auditor is actually looking for. The team is currently in observation for SOC 2 Type II, with the full Type II report targeted for Q3 2026. ISO 27001 is not pursued today. HIPAA BAA is not offered today and the team is explicit that this is by choice rather than oversight — a brand-protection-driven DNS platform is the wrong shape for a HIPAA workload regardless of paperwork. The honest framing on the homepage about each of these — "ISO 27001 not pursued yet. HIPAA BAA not offered today — ask if it's a requirement" — is the kind of disclosure most vendors avoid and the kind that procurement teams find unusually easy to evaluate.

For change-tracking automation, every audit event also fires an outbound webhook, signed with HMAC-SHA256, carrying the event name and a replay-protection timestamp. The webhook subscription supports wildcard event matching (`policy.*` for everything in the policy domain, `threat.*` for everything in the threat-detection domain, `*` for everything), which means a security team can wire the platform into the same event substrate it already runs Slack alerts and SIEM ingestion against, with a small receiver instead of a polling integration.

#Privacy posture: per-tenant anonymisation, configurable retention, bypass-bypass

A DNS filtering platform sees the most sensitive data in any organisation: every domain its operators have ever queried. The privacy posture of the platform is what determines whether a security team's trust in it is justified or naive.

OllaDNS handles three privacy primitives explicitly. First, client-IP anonymisation at ingest is configurable per tenant — a team that needs the source IP for forensic reconstruction of a specific incident can keep it; a team that prefers the operator-only-anonymous posture for compliance reasons can drop the last octet, hash with a salt, or omit it entirely. Second, retention is configurable per tenant in a one-to-three-hundred-and-sixty-five-day window, meaning the team that wants ninety-day forensic depth and the team that wants seven-day minimum can both be served by the same product without the platform forcing one operating model on the other.

Third, and most distinctive, the platform offers "bypass-bypass" blocklists — opt-in lists that block Tor exit nodes and the public DoH-over-HTTPS resolvers that a sophisticated user might use to evade DNS filtering on a managed endpoint. The bypass-bypass primitive is the one most established vendors quietly omit because it is operationally awkward and ideologically uncomfortable; for the security teams who need it (regulated environments, public-sector deployments, child-safety configurations), the omission is a real gap and the platform's explicit inclusion of it is a real differentiator.

The team has been explicit about what the platform does NOT do on the privacy side: no behavioural profiling, no cross-tenant analytics, no advertising-driven data use, no third-party data resale. The data the platform holds is the data the customer puts in, and the data the customer puts in is held under the privacy primitives the customer configures. The posture is the one that comes naturally to a small, well-engineered, bootstrapped team and is the one that compounds badly at the established venture-backed vendors as the pressure to monetise telemetry grows.

#Resolvers, protocols, and the network surface

On the network side, OllaDNS runs resolvers at `dns.olladns.com` supporting DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC. Tenant routing uses a path UUID so that the customer's DoH URL is unique per tenancy; per-device routing extends the path with a slug (`--`) so that one team can have separate routing and per-device analytics across a fleet of endpoints without needing separate tenancies for each.

The current infrastructure runs from a single US region, which the team is explicit about as a latency limitation for customers outside North America. The next infrastructure workstream is an EU-West region — already locked into the roadmap, on track for shipping over the next two to three months — and an APAC region beyond that. There is no anycast deployment today. For customers whose threshold for adoption is sub-twenty-millisecond P99 latency from Singapore, the team is direct that the product is not the right answer for them yet, and recommends NextDNS or Cloudflare Gateway for that specific requirement.

For the customers who can tolerate the current latency profile — which, in practice, means customers in North America today, in Europe within the next quarter, and in APAC over the medium term — the protocol surface is current. DoH and DoT are the well-trodden modern paths; DoQ is the newer protocol that the platform supports as a first-class peer because the team believes the protocol will be the dominant resolver protocol over the next five years and wanted to ship support before the demand became universal.

Native desktop, mobile and router clients are not shipped today. The roadmap is a fork of the MIT-licensed `ctrld` Go agent — a decision the team made after evaluating the alternatives and committing to a three-week implementation window. Until the fork ships, the operational pattern is to point any DoH-capable client (which today means every modern browser, every modern operating system, and every modern router worth shipping in 2026) at the tenant's DoH URL directly. The interim friction is real and the team does not pretend otherwise.

#The honest current state: pre-customer, design-partner phase

The single most unusual aspect of the brand site is the section called "Honest current state — the thing every other vendor's homepage hides." The team has chosen to publish, on the marketing surface itself, the maturity facts most procurement teams have to extract by force from a vendor that does not want to disclose them. v0.34 shipped May 2026. Pre-customer, pre-revenue, bootstrapped. SOC 2 Type II observation in progress, Type II report Q3 2026. ISO 27001 not pursued yet. HIPAA BAA not offered today. Single US region, no anycast, EU-West region next. No native desktop/mobile/router clients yet — `ctrld` fork on the roadmap.

For a procurement-savvy reader, that section is the most reassuring piece of the site. Every vendor in the security category has roughly that same set of facts at some stage of its lifecycle; what changes is whether the vendor is honest about them. The platform's posture is that early customers are best served by knowing exactly what they are buying — including the gaps — so that the procurement conversation can be about whether the product fits the customer's constraints rather than about whether the vendor has been honest about its constraints.

In practical terms, this means the customers the team is looking for today are not the Fortune-500 SOC procuring its next decade of DNS infrastructure. The customers the team is looking for are AI-native B2B startups (three to fifty engineers) who want the API + MCP operating model and can tolerate the early-stage gaps because the operating model is more valuable to them than the maturity. And Indian mid-market security teams (typically thirty- to two-hundred-employee companies) whose DPDP and data-residency constraints align with the platform's posture and whose buying preference for transparent, technically-deep vendors over pedigreed vendors is stronger than the average global market.

The design-partner programme is the front door for both of those buyer profiles. Three to five spots, free Pro tier through 2026 in exchange for aggressive product feedback and influence over the roadmap, applied for at the brand site. The programme is a real commitment — the customers who join it will shape what the v1.0 product looks like, and the team is explicit that the programme is a strategic relationship rather than a discount.

#Who OllaDNS is for, and the honesty about who it is not for

The brand site's "self-disqualify gracefully" section is the cleanest summary of fit that any security vendor has ever shipped. It is worth reading in full, and the substance of it is the basis of the buyer-segmentation discussion below.

The platform is the right choice for the engineering and security teams whose operators live in AI editors and would rather ask their editor to change a policy than open another dashboard. It is the right choice for teams that want to mint a scoped token per workload — CI, SOC tooling, AI agent, partner integration — with explicit grants. It is the right choice for teams that need to explain to an auditor exactly why a given lookup was blocked, and where "the vendor said so" is not an acceptable answer. It is the right choice for teams that have a brand worth protecting and want a typosquat detector scored against their specific protect-list rather than a generic feed. It is the right choice for small and mid-market security teams that value transparency and control over vendor pedigree. And it is the right choice for the teams operating in India and the broader APAC market where DPDP, data-residency, and Indian-vendor preference are near-term commercial constraints.

The platform is the wrong choice for the teams whose CISO requires a tier-1 vendor name with multi-decade brand recognition (the team is explicit: "Wait twelve months or pick NextDNS"). It is the wrong choice for the teams whose primary requirement is anycast from a hundred-plus PoPs (Cloudflare Gateway or NextDNS are the right answer for that specific gap). It is the wrong choice for the teams whose procurement gate is a current SOC 2 Type II report (the Type II observation is in progress; the report is Q3 2026). It is the wrong choice for the teams that need a native installer for macOS, Windows, iOS or Android in production today (the ctrld fork is the answer but it has not shipped). And it is the wrong choice for the teams whose only operators are non-technical (the read-only dashboard is the operating model and is not changing).

The clarity of the disqualification list is the clarity of a team that knows exactly what it is building. Most vendors at this stage hide the gaps; the platform publishes them on the homepage above the call to action. The buyer who matches the fit profile is the one the team can deliver to. The buyer who does not match is better served knowing now than three months into a procurement cycle.

#How OllaDNS compares to the established vendors

The DNS filtering category has a clear set of incumbents and the differences between them are well-understood by buyers who have evaluated more than one. It is worth being direct about how the platform sits against each.

NextDNS is the closest peer for the small-team and individual-developer use case. NextDNS is genuinely well-built, has spent years on consumer-grade ergonomics, has native client apps across every major platform, and runs from a meaningful global anycast footprint. Where NextDNS is the better choice today is exactly where the platform self-disqualifies: anycast latency, native installers, established consumer trust. Where the platform extends past NextDNS is the API-and-MCP operating model (NextDNS has an API but treats it as a secondary surface; the dashboard is the primary), the transparent classifier story (NextDNS uses opaque threat feeds), and the scoped-token discipline. For a small AI-native team where the operating model matters more than the network footprint, the platform is the right fit; for a small team that just wants a polished consumer-grade DNS filter, NextDNS remains the default.

Cisco Umbrella is the Fortune-500 incumbent. It is the safe choice for enterprises whose security organisation is large enough to have a dedicated DNS-filtering operator, whose procurement requires Type II reports and named vendor pedigree, and whose budget can absorb the per-seat cost. The platform is not trying to be Umbrella and the team is direct about that. The buyer who picks the platform over Umbrella today is the buyer who has explicitly traded vendor pedigree for operating-model fit, and the team's posture is that the buyer who would not make that trade is better served picking Umbrella.

Cloudflare Gateway is the at-scale alternative for the Cloudflare-ecosystem buyer. Gateway runs on Cloudflare's own enormous anycast footprint, integrates with the broader Zero Trust stack, and offers DNS filtering as one slice of a much larger product surface. For teams that are already deep in Cloudflare and want their DNS filtering to come from the same vendor as their tunnel, their CDN, and their identity proxy, Gateway is the obvious answer. For teams that want a focused DNS-filtering platform with the API-first and MCP-native posture, the platform is the differentiated answer. The competitive question is rarely "Cloudflare Gateway vs OllaDNS" head-to-head; it is "do I want DNS filtering as part of a bundled Zero Trust stack or as a focused best-of-breed product."

ControlD is the closest peer on operating-model fit for the small-team segment. ControlD has invested meaningfully in a developer-friendly surface, is more API-forward than NextDNS, and serves a similar buyer. Where the platform extends past ControlD is in the MCP-native posture, the read-only-dashboard discipline, and the transparent-classifier story. For buyers actively evaluating ControlD, the platform is the alternative that compares most directly and is the one whose differentiation is most legible in the same evaluation framework.

DNSFilter, Quad9, AdGuard DNS, and the various open-source self-hosted alternatives (Pi-hole, Adguard Home, Blocky) are different shapes of bet. They serve specific markets — MSP-channel-focused (DNSFilter), privacy-and-public-good (Quad9), advertising-focused (AdGuard DNS), or self-hosted-tinkerer (the open-source projects) — and the platform is not trying to compete with them on those specific markets. For the buyer who fits one of those profiles, the right answer is the right answer; for the buyer who does not, the platform is in the conversation.

#The team, the parent group, and the sibling Rust products

OllaDNS is built and operated by Ollasoftware, the AI software development company headquartered in Bengaluru that has shipped more than forty AI brands in production over the last four years. The team behind the DNS platform specifically is the Rust engineering group inside Ollasoftware — the same group that ships 24observe (logs observability) and Qcrawl (distributed crawl scheduler), with all three sitting on a shared internal substrate of async-Rust, Postgres + ClickHouse for hot/warm storage, and Caddy for the public-facing edge. The shared substrate is the reason the team can ship a DNS platform of this depth with the headcount it has; the architectural patterns and the operational tooling carry across.

The parent group, Networkers Home, is the cybersecurity and networking training institute that has placed more than forty-five thousand alumni across eight hundred hiring partners since 2007. The connection matters here more than for any other brand in the portfolio because the security primitives the platform ships — DNS-layer threat detection, brand-protection typosquat scoring, the wire-level discipline behind DoH/DoT/DoQ implementation — are exactly the primitives the institute has been teaching its alumni for the better part of two decades. The platform is, in a real sense, the product the parent group's alumni network has been asking for as their own engineering organisations have matured.

For procurement teams evaluating the platform, the parent-group connection is a useful signal in two directions. It means the team behind the product has institutional context for the security primitives the platform ships, beyond what a typical startup security team would have. And it means the platform has a parent organisation with a long operational track record — Networkers Home is in its eighteenth year of operation as of 2026 — backing a venture that is otherwise young. The combination is unusual in the category and the team treats it as one of the small structural advantages worth being clear about.

#What is on the roadmap

The team publishes the roadmap on the docs site and updates it as work ships. The visible near-term threads are concrete: the EU-West region (next infrastructure workstream, on track for the next quarter), the `ctrld` Go agent fork (three weeks of locked-in work, currently in implementation), an expanded MCP workflow catalogue beyond the current five hand-curated tools, deeper analytics around AI-agent activity patterns, and continued work toward the SOC 2 Type II report targeted for Q3 2026.

Underneath those visible features is steady investment in the classifier stack. The DGA classifier and the typosquat detector ship today at acceptable accuracy and the roadmap is to push both further with additional feature dimensions — autoencoder-shaped anomaly scoring layered on top of the current feature vectors for DGA, expanded homoglyph dictionaries for typosquat — without losing the transparency property that the source code is short, readable, and auditable. The team has been explicit that the classifiers will stay in the public repository even as they grow.

On the protocol side, the team is watching the discussions around oblivious DNS-over-HTTPS (ODoH) and is likely to ship support before the protocol is universal. DoQ remains the bet on the medium-term resolver protocol; the team's view is that the protocol's combination of TLS 1.3 cryptography, QUIC multiplexing, and connection migration makes it the right substrate for the next decade of resolver work.

Pricing during the design-partner phase is the published free Pro tier through 2026 for the three to five design-partner teams. Pricing beyond that has not been announced and the team has signalled that the post-design-partner pricing will be structured to fit the buyer profile the platform is designed for — predictable monthly tiers with bundled query volume and policy capacity, rather than per-query metering that surprises teams at scale. The principle is consistent with the rest of the Ollasoftware portfolio: a platform whose pricing only goes up over time loses customers as fast as it adds them.

#How to start

If you fit the buyer profile described in the disqualification section — an AI-native engineering or security team that wants the API-and-MCP operating model and can tolerate the early-stage gaps — the right next move is to apply for the design-partner programme. The application surface is on the brand site, the slots are limited to three to five teams, and the offer is free Pro tier through 2026 in exchange for aggressive product feedback and roadmap influence.

If you are not ready to commit to the design-partner relationship but want to evaluate the platform on your own terms, the published documentation, the OpenAPI specification, the MCP tool catalogue, and the public GitHub repository are all open. You can read the classifier source. You can read the full OpenAPI spec. You can read the MCP server implementation. You can read the docker-compose that runs the whole stack. The platform's posture is that the case for adoption is most legible when measured against the published artifacts rather than against the marketing pitch.

For the security teams whose primary concern is whether the platform fits their specific compliance environment — DPDP, GDPR, sector-specific regulations — the Ollasoftware contact page reaches the engineers who built the platform directly. The team has been explicit that the compliance conversation is the conversation to have first, before any technical evaluation, because the answer determines whether the rest of the evaluation is even relevant.

And if you are not yet sure DNS filtering is the right priority for your security programme this quarter — if you are evaluating where the next budget dollar should go and DNS is one of several options — the team's recommendation is the same one any honest vendor in the category should make: DNS filtering is a high-leverage, low-effort security control once it is in place, and any team without it today is leaving meaningful risk on the table. Whether the platform is the right vendor for that control depends on the operating-model fit. Whether the control itself is worth implementing this quarter rarely depends on the vendor at all.