GraceDNSCustom rules#
Custom rules are your own domain lists on top of the shared protections: a denylist for domains you never want resolved, and an allowlist for domains that must always work. They apply per configuration, so blocking a domain for the kids' devices does not block it at the office.
Suffix semantics: entries cover subdomains#
One entry covers the domain and everything under it. Denying example.com also blocks ads.example.com and cdn.tracker.example.com; you do not need wildcards. The same applies to allow entries. To be precise, list the most specific name you mean: denying games.example.com leaves the rest of example.com untouched.
Whole top-level domains and other public suffixes (like com or co.uk) cannot be listed; an entry that broad would take out half the internet by accident. International domain names are accepted in their punycode (xn--) form.
Allow always wins#
The allowlist beats every name-based block: your own denylist and every shared threat list. If a shared list ever overblocks a site you rely on, one allow entry fixes it immediately for that configuration. Only address-based checks still apply afterwards (rebind protection, which has its own allowlist, and blocked answer ranges), so an allow entry can never turn into a tunnel to a known-bad address. Because allow wins with suffix semantics too, a deny entry underneath an allow entry can never fire; the API warns you when you create such a shadowed rule instead of letting it silently do nothing.
Per-rule block type#
Each deny entry can carry its own block type; without one it uses the configuration's default. Blocks from custom rules are reported as "custom" in query logs and in REFUSED responses.
Changes go live on the resolvers within about a minute; devices may briefly keep cached answers, see what DNS filtering cannot do.
Back to features.