How the two lists work
An allowlist contains domains that should always resolve, even if a security filter or category would otherwise block them. A blocklist contains domains that should never resolve, even if no threat list has flagged them. Both are managed in the FirewallDNS dashboard and apply to every device on your registered network as soon as you save them.
Your own lists take priority over automatic filtering. That gives you the final say over what your network can reach.
When to use the allowlist
The allowlist exists for the rare cases where a filter is wrong for your situation.
- A legitimate supplier domain that is only a few days old and caught by newly registered domain filtering
- A business tool that loads through an advertising or analytics domain
- An educational resource that sits in a blocked category
- A shared-hosting site that was flagged because of a neighbour's behaviour
When to use the blocklist
The blocklist lets you act faster than any external list. If a colleague reports a suspicious email, add the domain from the link to your blocklist and nobody on your network can reach it. If a game or streaming service is causing problems at home but is not covered by a category, block it by name. If a device keeps contacting a telemetry domain you do not want, block that too.
Domain matching
When you add a domain such as example.com to a list, it is important to know whether subdomains like www.example.com or cdn.example.com are covered as well. [VERIFY: whether entries match subdomains automatically and whether wildcards are supported] Many services use several domains, so when you allow or block a service, check the query log to see every domain it uses and add each one.
Allowing safely
Every allowlist entry is a hole in your protection, so add entries deliberately. Before allowing a domain that was blocked for malware or phishing, check it with a second source and make sure you understand why it was flagged. Prefer allowing a specific subdomain rather than an entire domain when that is enough. Review the allowlist periodically and remove entries that are no longer needed.
Using lists with query logs
Lists and logs work best together. When a user reports a problem, open the query log, find the blocked request and add it to your allowlist. When the log shows repeated lookups to an unwanted domain, add it to your blocklist. Over time your lists capture the knowledge of your own network, making filtering more accurate for your users.
Practical examples
A design agency finds that a new font service, registered last week, is blocked by newly registered domain filtering. The administrator checks the vendor, adds the domain to the allowlist and the team carries on. A parent notices that a game keeps contacting a chat service late at night and adds the chat domain to the blocklist. An IT provider receives a phishing report from a customer, adds the domain to that customer's blocklist in seconds, and later sees it appear on the threat list too.
In each case the fix takes moments and applies to the whole network, without touching individual devices.
Keeping lists tidy
Lists grow over time. Schedule a short review every few months: remove allowlist entries for tools you no longer use, check that blocklist entries are still relevant, and make sure each entry has a reason someone can understand. A tidy list is easier to support and keeps your protection as strong as possible.
Lists versus categories
Categories cover large groups of sites maintained by list providers; custom lists cover the specific exceptions that matter to you. Use categories for broad policy, such as no gambling, and custom lists for precise decisions, such as allowing one school resource. Trying to replace categories with a hand-made blocklist rarely works, because there are far too many sites to list by hand.
Lists for organisations and MSPs
In a business or school, document why each list entry exists, for example in a shared ticket or a short comment in your own records. When you manage several customers as an MSP, each customer has their own settings and lists, so one customer's exception never affects another. [VERIFY: whether shared list templates across customers are available]