Tailscale Just Made Your Entire Network Un-Trackable (And Blocked All Ads)

An Enterprise Tool in a Developer's Trench Coat

Tailscale just announced built-in DNS filtering. The internet is already cheering about a magic button that blocks ads and trackers across your entire network. But let us draw a very clear line right at the start. If you run a homelab, a personal tailnet, or a small startup, you can put your wallet away. This release is not for you.

This is Tailscale quietly stepping into the enterprise Secure Web Gateway market. It is an IT compliance tool wearing a developer-friendly trench coat.

Tailscale built its reputation on being the mesh VPN that developers actually like. It moves packets between machines beautifully. But recently, the trajectory has shifted toward features that cater to the people who sign enterprise checks. The new integration with Control D is the clearest signal yet. They have integrated Control D directly into the Tailscale admin console as a nameserver.

You take your existing JSON Access Control Lists and map specific identity groups to specific Control D filtering profiles. All DNS queries from those mapped devices are routed through Control D over encrypted DNS.

Identity: The Core Difference

You might ask how this is functionally different from just running a NextDNS CLI or a Pi-hole on a Tailscale subnet router. Technically, the DNS resolution process is similar. You query a domain, the resolver checks a blocklist, and it either returns an IP or a black hole. But operationally, the difference is identity.

When you run a Pi-hole, it usually just sees the IP address of the node making the request. It does not know if that node belongs to an intern, the CEO, or a build server. This new integration binds your DNS filtering directly to your Tailscale identity provider.

You can write a rule that strictly filters the marketing department's traffic, blocks social media for the sales team, and leaves the site reliability engineers completely unrestricted. It abstracts the billing away from individual nodes and devices, charging a flat per-user fee handled directly through your Tailscale invoice.

The "Contact Sales" Catch

But we need to look past the marketing copy. The announcement promises you do not have to go through another procurement process to get this running. Yet, when you scroll to the bottom of the page to actually turn this on, there is no simple toggle. There is no transparent pricing tier. There is a button that says, "Contact Sales."

Hiding the cost behind a sales gate implies enterprise-tier pricing. You are absolutely going through a procurement and negotiation process. That answers the question for the hobbyists and the solo developers. Is this available for personal tailnets? No. It is strictly B2B. You cannot just click a button, pay five bucks a month, and start filtering malicious domains.

Operational Costs and Fragility

Beyond the pricing opacity, there is a real engineering cost to tying external SaaS platforms directly to your Tailscale ACLs. You are introducing a split-brain operational model. The identity and the mapping rules live inside your Tailscale JSON files. But the actual filtering policies—the blocklists, the custom redirects, the threat feeds—live entirely inside the Control D dashboard.

You are now splitting state across two separate control planes. When a developer complains that a critical internal staging server suddenly will not resolve, your networking team has to debug in two places. They have to verify the Tailscale ACL syntax is correct, and then cross-reference the Control D logs to see if a custom blocklist caught a false positive.

You also have to respect the fragility of the integration. Tying external platforms to your Tailscale JSON introduces tight coupling. Tailscale ACLs are notoriously unforgiving. A misconfigured tag in that JSON file does not just fail to apply a web filter. It could easily break DNS resolution for an entire department. Suddenly, your deployment pipelines cannot resolve internal package registries, and engineering grinds to a halt.

Unanswered Questions

We also lack answers on the failure modes. If Control D experiences a major outage, what happens to your tailnet? Does it fail open, falling back to unfiltered DNS so your team can keep working? Or does it fail closed, resulting in a complete loss of DNS resolution across your remote fleet?

The post touts a latency of under seven milliseconds in North America. For global distributed teams, North American metrics mean nothing. You need to know the P99 latency for engineers sitting in Singapore, Berlin, or Sydney before routing all corporate DNS traffic through a third party.

The DNS-over-HTTPS Blind Spot

Then there is the reality of DNS-level filtering itself. Picture this. It is Tuesday morning. Corporate IT has just mandated this new network-wide DNS filter. The policy is approved, the ACLs are merged, and the goal is to block distractions and known tracking domains across the company. The configuration deploys successfully. But by Tuesday afternoon, IT notices that half the engineering team is still casually browsing blocked domains.

How did they bypass the enterprise web gateway? They did not even try to. They simply opened Chrome or Firefox. Modern browsers increasingly default to Secure DNS, known as DNS-over-HTTPS.

DNS-over-HTTPS encrypts DNS requests and routes them directly to a provider like Cloudflare or Google, completely bypassing the operating system's local DNS resolver. If a developer's browser is configured to use DoH, Tailscale's MagicDNS and the Control D nameserver never even see the query. The browser tunnels right past the enterprise filter.

To actually enforce this policy, your IT department now has to push mobile device management profiles to every corporate machine. They have to lock down the operating system and forcefully disable Secure DNS at the browser level. If you allow bring-your-own-device access on your tailnet, enforcing this becomes nearly impossible. DNS filtering is a perimeter defense in an era where the perimeter is highly porous.

The Verdict for Different Users

So where does this leave us? We have to separate what Tailscale is building from how they are selling it. The engineering behind routing encrypted DNS queries based on identity groups is genuinely useful for large fleets. It solves a massive headache for IT admins who want to apply basic web hygiene to fully remote workers.

If your organization is already heavily invested in Tailscale for your corporate overlay network, this makes sense. If you need to enforce compliance policies across a remote fleet and want to bind those DNS rules directly to your existing identity groups, you book the sales call. It is a much lighter lift than deploying a heavy secure web gateway like Zscaler or Cisco Umbrella.

Those legacy web gateways often perform deep packet inspection. They intercept all your traffic, break TLS, and require custom root certificates installed on every developer machine. That causes massive friction when developers are pulling packages or pushing code. This Tailscale and Control D integration only looks at DNS. It is vastly less invasive. But the strict tradeoff is that it can only block entire domains. It cannot inspect the payload. It cannot block a specific malicious URL on a shared host. It is a blunt instrument. You negotiate the per-user rate. You accept the split control plane. You deal with the MDM requirements.

But for the rest of us—the small teams, the solo developers, the infrastructure hobbyists—do not let the headline convince you that you are missing out. Setting up NextDNS as a custom nameserver works perfectly fine. Running Pi-hole on a small Linux box inside your tailnet remains a superior choice for small setups. It is highly transparent, it is practically free, and it keeps your network architecture simple.

Tailscale is building for the enterprise now. You just have to recognize when a feature is built to solve your technical problems, and when it is built to satisfy a corporate compliance checklist.

TAKEYOURPILLS.TECH. Go ship something.

Deconstructing the Integration: What Really Changed?

Before this week, DNS filtering inside a Tailscale network was a side project. You could point your tailnet at a filtering resolver. Maybe Control D. Maybe NextDNS. Maybe a Pi-hole running on a cheap VPS in a region your devices barely peer with. Whatever the choice, you were managing two dashboards, two vendor relationships, and a manual enrollment process to keep device identities in sync.

If your security team wanted a phishing domain blocked by Friday, you were editing DNS config by hand, pushing resolver changes to dozens of laptops and phones, and praying nobody had a stale cache when the weekend started. If you wanted different rules for different teams, you maintained separate profiles and hoped your spreadsheet matched reality.

Tailscale just shipped native integration with Control D. The mechanics are simple on paper. You add Control D as a nameserver in your Tailscale admin console. You build filtering rules inside Control D's dashboard or API. Then you map users, groups, or device tags to those rules inside your tailnet ACL. Your devices send encrypted DNS queries through Control D over HTTPS. Tailscale bills you per user. No counting serverless nodes. No counting IoT tags. No separate procurement. No second vendor invoice.

The Real Delta: ACL-Driven Policy

That last paragraph is doing a lot of marketing work. Let's separate what actually changed from what got repackaged. The real delta is ACL-driven policy. Before, if you wanted finance on a strict malware filter and engineering on a looser blocklist with custom redirects, you managed separate Control D profiles and manually assigned endpoints. If someone changed teams or you provisioned a new tagged server, you updated two systems and hoped they agreed.

Now you point a Tailscale tag or group identity directly at a Control D rule inside your tailnet policy file. That's concrete. That's new. For teams already paying for both platforms, it removes the busywork of keeping two identity systems aligned.

But the filtering itself lives exactly where it did. You still choose from over a thousand maintained services and apps inside Control D. You still write custom rules to block, allow, redirect, or reroute domains. You still manage categories like malware, phishing, gambling, or social media through Control D's interface. Tailscale did not absorb that UI. So if you were hoping to kill your second dashboard this week, you didn't. You eliminated the vendor procurement step and you gained ACL sync. Those are improvements. They are not a unified product.

The Importance of Encrypted DNS

The encrypted DNS part matters more than it sounds. Before, if your devices left the office and connected from a coffee shop, your DNS queries might hit the local ISP resolver in plaintext. With Control D wired in through Tailscale, those queries travel encrypted between the client and the resolver by default. That closes a real eavesdropping vector. It is not unique to this integration — Control D supported encrypted DNS before — but having it enforced through Tailscale policy means your contractors don't need to configure DoH manually on every new laptop. That's a genuine operational win.

Speed, Security, and a Grain of Salt

Let's examine the speed and security claims. Control D is fast. Tailscale says under seven milliseconds in North America. That is genuinely quick for a filtering resolver that inspects every query against threat feeds, machine learning models, and category lists before it returns an answer.

Control D blends threat feeds, malicious domain detection, and machine learning to block malware and phishing, and it's consistently ranked as a top DNS malware blocker. That part of the pitch holds up. The catch is that machine learning in DNS filtering is mostly pattern matching against known bad domains. When it works, it's invisible. When it fails, you get a false positive on a legitimate CDN and your app breaks in ways that are hard to debug because the failure mode is a silent DNS drop. You need logging and override workflows, and those still live entirely inside Control D, not Tailscale.

The Problem with Per-User Billing

There's also the user-based billing pitch. Tailscale says you don't need to predict device counts or serverless nodes. You tell them your organization size and they bill per human. That sounds clean until you try to map it to a real tailnet. In practice, a single Tailscale user might have five devices. A tagged server might run automation under a service account. Control D's per-user billing is simple on a slide deck. It gets complicated when your infrastructure doesn't map cleanly to headcount. And since the only purchase path is a sales conversation, you won't know the exact unit price until you're already in the room.

A Staff Engineer's Skepticism

Here's where the Staff Engineer skepticism lands. Tailscale writes that this gives you:

the same kind of straightforward control over the public Internet that Tailscale gives you inside your tailnet.

That's a nice sentence, but it isn't accurate yet. Inside your tailnet, Tailscale gives you wire-level access control based on cryptographic node identity. Control D gives you categorical blocking based on domain lists and threat intelligence. Those are different primitives.

If you need to block social media for contractors but not full-time staff, or if you need a redirect rule for a specific SaaS tool, you're still writing ACLs in Tailscale and maintaining parallel profiles in Control D. The complexity didn't vanish. It moved into policy.

A Note on Privacy Claims

Then there's the privacy angle in the headline. DNS filtering stops your devices from resolving known ad networks, malware domains, and phishing sites. It does not make your traffic invisible to your ISP. It does not hide your source IP. It does not encrypt the SNI in your TLS handshake. It is not a VPN privacy layer. It is a domain blocklist with policy routing. That's genuinely useful for reducing attack surface and cutting ads at the network level. It is not magic. Don't let the marketing copy confuse the two.

The Final Migration Verdict

So who should actually adopt this now, and what's the real blocker? If you're already an enterprise Tailscale customer and you already pay for Control D, treat this as a maintenance win. The ACL integration cuts manual endpoint enrollment. The unified billing removes a vendor relationship. The encrypted DNS path is cleaner than whatever workaround you built last year. The migration friction is nearly zero. Move when your contract renews.

If you're running a small team, a startup, or a personal tailnet on Pi-hole, NextDNS, or a local AdGuard instance, wait. This integration does not replace your custom blocklists. It does not replace your local cache. And it introduces a cost model that currently has no public price. The blog post says Tailscale will bill per user, but the call to action is literally "come have a chat with us." There is no self-serve checkbox. There is no rate card. If you need to know your monthly burn before you ship config, this is a hard stop.

If you're on Tailscale's free tier or you're a solo developer, this isn't aimed at you. The sales gate makes that explicit.

The migration verdict is straightforward. The ACL integration is real. The encrypted DNS plumbing is solid. The billing simplification is honest, but only if you were already willing to pay enterprise rates for both tools and sit through a sales cycle. For everyone else, this is a promising connector waiting behind a pricing wall. Tailscale didn't make your network un-trackable this week. They made enterprise DNS filtering easier to procure through your existing vendor. That's worth knowing about. It's worth adopting if you're already in both pools. For the rest of us, the real blocker isn't the DNS cutover or the ACL syntax. It's the lack of a price tag.

Check back when there's a self-serve tier and a public rate card.

TAKEYOURPILLS.TECH. Go ship something.