In this article

This guide provides a step-by-step process for troubleshooting issues when a domain isn't filtering as expected. Follow these steps to check each Organization attribute and identify the cause of unexpected filtering behavior.

Prerequisites

Before beginning, ensure you have:

• Access to your DNSFilter dashboard
• Account permissions to view and modify Filtering Policy settings
• A clear understanding of the expected filtering behavior for the environment

Step one: Identify affected policies and expected outcomes

Use the DNS Query Log to pin point inaccuracies. The DNS Query Log is one of the most helpful tools for understanding how each policy level is being applied in real time.

• Clarify the Issue. Determine what isn’t filtering as expected. For example, is a blocked domain still accessible, or is an allowed site being blocked?
• Identify Policies. Note which policies should be allowing/blocking the domain
• Determine the Expected Filtering Behavior. This can help compare what is expected versus what is happening

Step two: Check where policies are applied

When Filtering Policies aren't being blocked by external configuration conflicts, the issue is almost always one of two scenarios:

• The policy you think applies to the user/device is actually being overridden by another, more specific policy
• Default settings were updated for one attribute but not another (e.g Inherit from Site / Inherit from Roaming Client was updated at the Collection level but not the User level) 

Filtering Policies do not layer, they instead take priority over one another. This means that if you want to apply a stricter policy to a group of users, that policy must block the same categories as the less restrictive policy plus the additional restrictive blocks. 

Examining where policies are applied, especially when some users report issues and other do not, typically surfaces the issue. 

Start at the most specific attribute—Users—and work your way down the hierarchy to the least specific, Sites. 

⚡️Pro Tip: If multiple users have the same issue, it’s more likely a Site or Collection-level policy is causing the conflict. 

Wanna get a little more technical? 

Use the nslookup command nslookup -type=txt debug.dnsfilter.com to display account details, but the ones that stand out for these purposes are policy_id  and policy_source.

These lines are the identifier of the policy and where the policy is coming from (e.g. Collection, Site, User)

Note the ID and cross reference by opening a Filtering Policy and checking the ID in the URL, e.g. app.dnsfilter.com/organizations/orgID/policies/filtering/policyID/edit/name. If the policy source and ID don't align as expected that signals the wrong policy is applied to the environment attribute.