Blocking TikTok and YouTube at the DNS layer — and where it stops

Flip the toggle for "TikTok" or "YouTube" in a DNS resolver and something satisfying happens almost immediately: phones on the network stop loading the app, the browser tab spins and dies, and the help-desk ticket count climbs. It feels like a clean win. One switch, a whole service gone. And for a large share of casual users on a managed network, that is exactly the outcome you get.

Then a few of them figure out that the app still works on cellular, or that one particular game console keeps streaming video anyway, or that the corporate laptop with a VPN client sails straight through. The toggle was never a single switch — it was shorthand for "block this set of domains," and the gap between what the toggle promises and what it actually blocks is where the interesting engineering lives. This article is about that gap: how service blocking really works at the DNS layer, why it needs help from your firewall, and how to set honest expectations before you turn it on.

A "service" is really a domain set

There is no field in a DNS query that says service: tiktok. The resolver only ever sees a name and a query type — www.tiktok.com, A — and decides whether to answer it. So when a product offers a one-click "Block TikTok," what it ships behind that toggle is a curated set of rules: every domain the service is known to depend on, expressed in filter syntax.

A modern consumer app is not one domain. It is a constellation. The web front end lives on one name, the mobile API on another, the video CDN on several more, telemetry and crash reporting somewhere else, advertising and attribution on their own hosts, and regional variants for different markets. Miss any leg of that constellation and the app degrades gracefully instead of failing — which is worse, because "mostly works" is harder to diagnose than "doesn't work."

A realistic rule set for a single large video service looks less like one line and more like a category. Below is an illustrative shape (names are generic stand-ins, not a real block list):

Why one toggle hides dozens of rules

The reason a maintained service is worth more than a hand-written list is churn. App vendors rotate domains, add markets, and split traffic across new CDN edges on their own schedule — not yours. A service rule set that was complete six months ago will have leaks today.

There is also the matter of custom stragglers. Even a well-maintained base list can miss a domain that only shows up under specific conditions: a newly launched feature, a niche regional host, a fallback API that the app only reaches when the primary is unavailable. For those, UnveilDNS lets you attach per-service custom rules — extra domains pinned to an existing service so they count as "TikTok" or "YouTube" in your reporting and inherit the same on/off control. You watch your own query log, spot the host that's still resolving when the service is supposedly blocked, and pin it. The cat-and-mouse is real, but it's a manageable one when you can see the misses.

Rule of thumb: if a blocked service still partially works, the missing piece is almost always a CDN or fallback domain that resolved before you noticed it. Watch the query log of the device that's leaking, not the base list.

Where DNS blocking stops working

DNS filtering depends on one assumption: that the device asks your resolver for the name, and then trusts the answer. Every bypass technique is an attack on that assumption. Three matter in practice.

Hard-coded IP addresses

If an app ships with the IP of its API baked into the binary, it never sends a DNS query at all. It opens a socket straight to 203.0.113.10 and your resolver never gets a vote. Streaming devices, some game consoles, and a handful of mobile apps do exactly this for their most critical endpoints — precisely because the vendor knows DNS filtering exists. No DNS rule can block a connection that was never preceded by a lookup.

Embedded encrypted DNS

A growing number of apps and browsers ship their own DNS-over-HTTPS client and a hard-wired list of public encrypted resolvers. When that's active, the app tunnels its lookups inside HTTPS to a resolver you don't control, bypassing the network resolver entirely. Operating systems and browsers expose "secure DNS" settings that do the same thing system-wide. The mechanism is sound — encrypted DNS is good for privacy on hostile networks — but on a network you're trying to manage, it's a hole.

The standard defence is a network signal that tells well-behaved clients to fall back to the local resolver, combined with blocking the bootstrap names those clients use to reach their built-in encrypted endpoints. UnveilDNS can publish that signal and block the bypass bootstraps. It works against clients that honour the convention — and does nothing against an app that deliberately ignores it. That's the honest boundary.

Fallback domains and round-robin hosts

Resilient apps are designed to survive a flaky network, and that resilience reads, from the filter's point of view, like evasion. When the primary API name is blocked, a well-built client retries an alternate host, then another, then a regional mirror. Each fallback is a domain you may not have in the rule set yet — and the app only reveals it when the primary is already down, which is to say, only after you've turned blocking on.

Necessary, but not sufficient: pair it with egress control

The pattern across every row in that table is the same: the bypasses DNS can't see are bypasses the firewall can. DNS filtering and egress control are not competitors; they're layers, and each covers the other's blind spot.

DNS blocking is cheap, surgical, and reportable. It blocks at the granularity of a domain, it produces a clean query log of who tried to reach what, and it costs almost nothing to run at scale. What it cannot do is stop a connection that skipped the lookup. Egress control is the inverse: a firewall rule that drops outbound traffic to known service IP ranges, or to public encrypted-DNS resolvers on port 853 and 443, catches the hard-coded-IP and tunnelled-DNS cases that DNS is structurally blind to. It's blunter and higher-maintenance — IP ranges change too — but it sees packets DNS never will.

A concrete starting point for the firewall side is to deny outbound DNS to anything except your own resolver — drop UDP/TCP 53, DoT on 853, and DoQ on 853 to every destination but the box — so that a client which tries to reach an external resolver simply fails and falls back to you:

# Illustrative egress policy (pseudocode, replace with your firewall syntax)
allow  udp/tcp 53   dst = <your-resolver-ip>
allow  udp/tcp 853  dst = <your-resolver-ip>
deny   udp/tcp 53   dst = any        # external plain DNS
deny   udp/tcp 853  dst = any        # external DoT / DoQ
# DoH (443) cannot be port-blocked wholesale; rely on
# DNS-level blocking of the known encrypted-resolver names

Note the last line. You can't block DoH by port, because port 443 carries the entire web. The realistic control for DoH is to block the names of the well-known public encrypted resolvers at the DNS layer before the client can bootstrap to them — which is, neatly, a job DNS filtering does well. The layers reinforce each other.

Setting honest expectations

If you deploy service blocking and tell stakeholders "TikTok is gone," you will be wrong in a way that erodes trust the first time someone demonstrates it working on a console. Frame it accurately instead, and the same control becomes credible.

For the large majority of a managed fleet — the users who never change a setting and run stock apps — DNS service blocking is genuinely effective, and the per-service reporting is often as valuable as the block itself, because it tells you exactly which devices are still trying. For the determined minority, DNS is the trigger that exposes the bypass and the firewall is the wall that stops it. Sold as a complete solution, DNS blocking disappoints. Sold as the visible, reportable first layer of a two-layer egress policy, it does precisely what it's good at.

Block at the resolver because it's surgical and it shows you everything. Enforce at the firewall because some clients don't ask permission. Neither layer is the whole answer — and a product that pretends one of them is, is the one to distrust.