# Custom 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](rebind-protection.md), which has its own allowlist, and [blocked answer ranges](network-rules.md)), 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](block-types.md); without one it uses the configuration's default. Blocks from custom rules are reported as "custom" in [query logs](query-logs.md) 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](../limitations.md).

Back to [features](index.md).