# What DNS filtering cannot do

We would rather you know the limits of DNS filtering before you rely on it than discover them later. DNS filtering is a powerful, cheap, network-wide protection layer, and it is exactly that: one layer. Here is what it structurally cannot do.

## Blocking works per domain, not per page

A DNS resolver sees only the domain being looked up (`example.com`), never the full page URL or its content. GraceDNS can block or allow whole domains (and their subdomains), but it cannot block one article on a news site, one video on a platform, or one image on a social network. If part of a domain is harmful and part is not, the choice is all or nothing. Services that need page-level decisions require a browser extension or an inspecting proxy, which is a different product with different privacy trade-offs.

## In-app content and same-domain ads

Many apps serve ads and content from the same domains as their core functionality. YouTube is the canonical example: video ads come from the same infrastructure as the videos, so no DNS filter can block YouTube ads without blocking YouTube. The same applies to ads inside Facebook, Instagram or TikTok feeds. DNS blocking is very effective against third-party ad and tracker domains and much less effective against first-party ads.

## Determined users can bypass it

DNS filtering controls devices that use your resolver. It cannot stop:

- **VPNs**: a VPN tunnels all traffic, including DNS, to another network entirely.
- **Hardcoded DNS**: apps and devices can ship their own DNS-over-HTTPS client and ignore system DNS. Some smart TVs, IoT devices and browsers do this by default. A router-level firewall rule blocking outbound port 53 and known DoH endpoints raises the bar, but cannot close it completely.
- **Direct IP connections**: software that already knows a server's IP address never asks DNS at all.

For parental control, this means DNS filtering is friction and protection for everyday use, not a technical guarantee against a motivated teenager. Combine it with device-level restrictions if you need stronger enforcement.

## Shared infrastructure causes collateral effects

Modern websites share hosting: thousands of unrelated sites can sit behind a single CDN domain or wildcard certificate. Two consequences:

- Blocking a domain used by shared infrastructure can break unrelated sites that depend on it.
- Malicious content hosted on big shared platforms (public cloud storage buckets, hosting subdomains, URL shorteners) often cannot be blocked at the domain level without breaking the legitimate majority.

We curate our lists with this in mind and your allowlist always wins, but the trade-off is inherent to domain-level filtering.

## Changes are fast, not instant

Two propagation delays exist by design:

- **Our side**: configuration changes reach all resolvers within about 60 seconds.
- **Your side**: DNS answers carry a time-to-live (TTL) and devices cache them. A domain resolved moments before you blocked it may keep working on that device until its cached answer expires, which can take minutes to hours depending on the record. Flushing the device's DNS cache (or rebooting) applies the change immediately.

## Blocked is not the same as safe

An allowed answer means the domain was not on any enabled blocklist at query time, not that the destination is trustworthy. New threats appear constantly and feeds always lag reality by some margin. Keep the other layers: TLS certificate checks, up-to-date software, spam filtering, and healthy skepticism.

## One more honest note: HTTPS block pages

If you choose the "block page" response type, browsers will show a certificate warning when the blocked site was requested over HTTPS. That is TLS working as intended: we cannot (and should not be able to) impersonate the blocked domain. The zero-IP and NXDOMAIN block types avoid the warning by failing the connection cleanly instead.

Questions about whether DNS filtering fits your threat model? Ask us: support@gracedns.eu.