ControlD does the SMB / router-agent story better than anyone. olladns does the agent-native API + transparent classifier story better than anyone. Pick by which fits your team.
Pick ControlD if you need their ctrld router agent to drop into pfSense / OpenWrt / Asus-Merlin and bring LAN-device topology + per-device policy with zero code on your side. Pick olladns if you want to configure DNS filtering from Claude/Cursor/Continue via MCP, mint per-task scoped agent tokens, or trust the classifier behind every block decision because you can read the source.
ControlD's API is solid and their MCP server work is on their roadmap. olladns ships an MCP server live at mcp.olladns.com today with 49 tools and 5 hand-curated workflow compositions (enable_strict_mode, set_kids_profile, security_brief, block_domain, allow_domain). Your scoped API tokens carry explicit resource:action grants; each token's actions show up in the audit log under its own actor id.
ControlD's product (like every other DNS-filter vendor) is dashboard-first with API as the advanced surface. We inverted that on purpose at v0.19: every config change goes through versionable, auditable, scriptable APIs. The dashboard is for inspection. The result: zero drift between environments, every change carries an actor, and "what changed and when" is always answerable from the audit log instead of forensic git-blame across the team's browser histories.
ControlD does per-device through their ctrld agent (which is excellent, see below). olladns does it through the DoH URL itself: dns.olladns.com/dns-query/<tenant>--<slug>. Every analytics endpoint slices by device slug. You don't need our agent on the box; you just point any DoH client (OS-native, your router, a browser, a script) at the per-device URL.
ControlD's rule engine is powerful but you have to track which kind of rule overrides which. olladns has five rule categories (block / allow / rewrite / TLD-block / catch-all) that each live behind their own endpoint and discriminate at storage so flipping one category never silently clobbers another. Setting up allowlist-only mode while keeping your existing block/allow lists and rewrites intact is one PUT.
ControlD's threat-intel comes via feeds — opaque, vendor-dependent, recurring cost. Our DGA classifier is ~280 lines of feature-based Rust you can read; our typosquat detector is Damerau-Levenshtein + a Unicode homoglyph map. Per-tenant protect-list is just a list of your own domains. Zero recurring cost, no vendor in the loop, and "why did this fire?" has a code-review-able answer.
Both products have webhooks but olladns ships HMAC-SHA256 signing per-row + a per-tenant signing secret out of the box, with the event subscription on per-action-pattern wildcards (policy.*, audit.*). Plug into Slack / PagerDuty / SIEM by URL in one POST.
ctrld router agentThis is ControlD's killer feature for SMB and home networks. One binary, drops into OpenWrt / pfSense / OPNsense / Asus-Merlin / Synology / GL.iNet / Firewalla / DD-WRT. Brings every LAN device into the dashboard with its hostname + MAC, applies per-device policy from a single config. olladns has nothing equivalent; we expect your router to do DoH/DoT upstream natively or you front it with your own forwarder.
ControlD inherits Windscribe's PoP footprint — 100+ PoPs across multiple continents. olladns runs in one US region with Mumbai on the roadmap. If your endpoints are globally distributed and latency matters more than agent-native config, ControlD is faster today.
ControlD's Redirect action proxies queries to their residential exit nodes for geo-unblock. We have DNS rewrites (CNAME / A / NXDOMAIN), but we don't operate residential proxy infra. If you need DNS-based geo-spoofing as part of the product, ControlD has it; we don't.
ControlD's p0-p3 free public resolvers on stable IPs are a brand-recognition play that puts them in every "best DNS provider" listicle. olladns doesn't run free public resolvers (single IP — can't park multiple presets on it).
p0-p3Their ctrld router agent is genuinely the right design for the SMB segment and we've called it out as the model in our internal notes. The reason we haven't shipped an equivalent is segment focus — we're targeting AI-native B2B startups and Indian mid-market enterprise first, where teams already configure their own routers / use OS-native DoH and want the agent-native config story instead. If our ICP shifts toward SMB, our roadmap is to fork ctrld directly (it's MIT-licensed) rather than re-implement — the open-source code is the right base; only the upstream URL and packaging need to change.