Introduction

What Does Working Correctly Look Like?

Visual confirmation in the browser is not a reliable indicator on its own. Always use Query Logs or the Visibility Report to confirm enforcement.

DNS Filtering is working correctly when blocked domains appear in logs as blocked and websites do not load when restricted by policy. The browser result will vary depending on HTTPS behavior — both outcomes below are valid:

If the domain is not appearing in logs at all, do not focus on browser output — the issue is upstream of the browser. Proceed to Confirm the Domain is Blocked.

Before You Start

Not all unexpected browser behavior indicates a problem.

For HTTPS websites, it is normal for a block page to be replaced by a browser security warning due to HTTPS and HSTS enforcement. This does not mean DNS Filtering has failed.

Before proceeding, confirm whether the domain is being blocked.

Start here:

1. Confirm whether the domain is blocked in logs
2. If not blocked — check DNS path and DoH bypass
3. If blocked but no block page — check HTTPS/certificate behavior
4. If behavior differs by device — check deployment type (location vs roaming)

Confirm the Domain is Blocked

Use the Visibility Report or Query Logs to verify that the domain is being blocked by policy.

• If the domain is blocked in logs, DNS Filtering is working correctly 
• If the domain is not blocked, proceed with configuration troubleshooting 

Filtering should always be validated through logs or reports rather than browser behavior alone.

Site Loading When It Should Be Blocked? Check for DNS Bypass

If a website loads normally instead of being blocked, the most common cause is DNS bypass through Secure DNS (DoH) or incorrect network configuration.

• Chrome / Edge: Settings → Privacy and Security → Security → Use secure DNS → set Off or With your current service provider.
• Firefox: Settings → Network Settings → Enable DNS over HTTPS → Off (or about:config → network.trr.mode = 5).
• Safari (macOS): System Settings → Network → → Details → Advanced → remove DoH/DoT entries; confirm CyberFOX resolvers.
• OS‑level Secure DNS (Win11/Android/iOS): Disable or ensure it uses CyberFOX profiles.
• If the block page still doesn’t show, confirm the test hits CyberFOX (query logs), ensure VPN/agents aren’t hijacking DNS, and, if needed, capture packets (tcpdump/Wireshark) while reproducing.

Why this matters: Browsers that use DoH on port 443 make DNS look like normal HTTPS and bypass the router/OS DNS—turn it off to validate filtering.

 

Why is the browser not showing the Block Page?

If a block page is not displayed, this does not necessarily indicate a problem.

For HTTPS websites, modern browsers may prevent block pages from rendering and instead display a security warning. This behavior is expected and is controlled by browser security enforcement.

This section helps determine whether the domain is being successfully blocked, regardless of how the result is displayed.
 

Before testing

Expected vs Unexpected Behavior

• A block page is displayed for standard (non-HTTPS) websites
• A block page is displayed for HTTPS websites when the Root CA is installed and trusted
  • To verify Root CA installation, check that the CyberFOX certificate appears in the device's Trusted Root Certification Authorities store. See: [Installing the Root CA Certificate].
• A browser security warning appears for HTTPS or HSTS websites without certificate trust

• The website loads normally when it should be blocked
• The domain does not appear in Query Logs or Visibility Report
• Filtering behavior differs across devices unexpectedly, without a configuration explanation

Block Page Not Showing on HTTPS Sites

This is the most common scenario when testing HTTPS-based filtering behavior and is often expected rather than a configuration issue. If users report certificate warnings or “Connection is not private” errors, this may be expected behavior for HTTPS sites. Refer to: [Block Page Not Showing]

Using the Guided Assistance Wizard in the Portal

Use the (1) Troubleshooting page to launch the (2) Guided Assistance Wizard. Confirm that you have configured the location or installed the agent on the device before (3) Continuing to troubleshoot. Then you can filter by (4) Roaming devices or Locations that you need to troubleshoot, and follow the guided steps to check your settings.

Using Portal‑Driven Troubleshooting Flows

Using the troubleshooting page lets you see the status of devices or locations and provides you with information and troubleshooting guides:

Locations

Use the (1) Troubleshooting page to (2) search for the device, location, or Company you need to troubleshoot. When looking at the location, you can quickly find information on:

3. Current Status at a glance
4. The last time it checked in, status, configured IP address for the location, and the last IP address it checked in from.
5. If you need to make changes, you can click on the Configure Button  to access the configuration page, or the Troubleshooting Wizard to work through the troubleshooting wizard for this location

 

 

 

 

Roaming Devices 

Use the (1) Troubleshooting page to (2) search for the device, location, or Company you need to troubleshoot. When looking at the device, you can quickly find information on:

3. Current Status at a glance
4. The last time it checked in, status, assigned policy for the device, Fallback Mode configured, and the last IP address it checked in from.
5. If you need to make changes, you can click on the Configure Button  to access the configuration page, or the Troubleshooting Wizard to work through the troubleshooting wizard for this device

 

 

 

 

Advanced Diagnostics

Before using these steps, confirm that you have:

• Verified enforcement through Query Logs or Visibility Report
• Checked for DoH bypass if the site is loading
• Reviewed HTTPS/HSTS behavior if the block page is not showing

If all of the above are confirmed and the issue persists, continue and use the following diagnostics when standard troubleshooting does not resolve the issue or when behavior is inconsistent across devices, locations, or environments. These steps focus on validating deeper network behavior, DNS resolution paths, and browser-level interactions.

Environment Validation

At this stage, confirm that the environment itself is behaving as expected rather than focusing on individual symptoms.

Validate whether the issue is isolated or systemic by testing:

• Multiple devices within the same location 
• Different networks (internal vs external) 
• Both roaming devices and location-based filtering 

If behavior changes across environments, this typically indicates a configuration or policy scope issue rather than a platform failure.

Also, confirm that the correct policy is applied to the affected device or location. Misapplied policies or inherited configurations can produce results that appear inconsistent but are functioning as designed.

DNS Path and Resolution Validation

DNS filtering relies on controlling how queries are resolved. If websites are loading when they should be blocked, confirm that DNS traffic is not bypassing CyberFOX.

Validate the DNS path by checking:

• The configured DNS servers at the device or network level  
• Whether any secondary DNS providers are configured (which may allow round-robin bypass)  
• Firewall or router rules that may redirect or override DNS traffic  

If Secure DNS (DoH) is enabled at the browser level, DNS queries may bypass the configured network path entirely. This is one of the most common causes of unexpected behavior.

If needed, use basic DNS lookup tools (such as `nslookup` or `dig`) to confirm which DNS resolver is responding to queries and whether responses match expected behavior.
 

Browser / Device-Specific Issues

Browsers enforce their own security controls independently of DNS filtering. HTTPS enforcement, certificate validation, and caching all impact how results are displayed to the user.

Validate browser behavior by:

• Testing in multiple browsers (Chrome, Edge, Firefox, Safari) 
• Testing in a private/incognito session to eliminate cached data 
• Clearing HSTS settings or browser cache where applicable 

If a browser displays a security warning instead of a block page, this is often expected behavior for HTTPS or HSTS-protected sites. In these cases, confirm blocking through logs rather than visual output.

Also verify whether the Root CA certificate is installed and trusted on the device. Lack of certificate trust will prevent block pages from displaying correctly over HTTPS.

Device vs Location Behavior

• Location-based filtering (router, firewall, DHCP deployment) 
• Roaming device filtering (agent or DoH-based) 

• Validate agent status and last check-in time 
• Confirm that the agent is applying the correct policy 
• Check for conflicts with local DNS settings or VPN clients 

• Verify that the correct public IP is configured 
• Confirm that DNS traffic from the network is being forwarded properly 
• Ensure no local DNS servers are bypassing filtering logic 

Network Interference and Edge Cases

• VPN clients that override DNS settings 
• Endpoint security tools that intercept or redirect traffic 
• Split DNS configurations (internal vs external resolution paths) 
• Proxy services or inspection tools that alter request flow 

Agent Fails to Start — Port 53 Conflict (Hyper-V / Virtualized Environments

Symptom: The CyberFOX DNS Filtering agent installs but the CyberFOX DNS over HTTPS Service fails to start, or DNS filtering is not active after installation. This is most commonly reported on virtual machines running inside a Hyper-V environment.

Cause: The agent listens for DNS queries on port 53 of the local machine (127.0.0.1:53). In Hyper-V environments, the host's DNS service already holds port 53, and this binding conflict prevents the agent service from starting.

Resolution:

Installing the agent on a Hyper-V virtual machine is not a supported configuration. The correct deployment for these environments is a Static Location at the perimeter firewall:

1. Remove the agent from any affected VMs.
2. Log in to the CyberFOX portal and add a Static Location for the client network.
3. Configure the perimeter firewall or router to forward all outbound DNS requests to the CyberFOX DNS IPs listed on the Location Configuration page.
4. All devices on the network — including Hyper-V VMs — will be filtered through the static location without requiring any per-machine agent.

Note on reporting granularity: A static location provides network-level filtering and reports at the location level, not per-device. If per-device reporting is required for machines on the Hyper-V network, consider deploying the DNS over HTTPS (DoH) roaming profile on individual VMs instead of the agent — DoH does not use port 53 and avoids the conflict entirely.

See also: Deployment Options | Using the DNS Filtering Agent (Windows)

FAQ

Q1: Why is my DNS filtering not working or the block page not appearing?
This is expected behavior for some HTTPS websites. See: [Why Block Pages Do Not Appear on Some Websites (HTTPS / HSTS)]

Q2: How do I disable DoH in Chrome, Edge, and Firefox?

• Chrome/Edge: Settings → Privacy and Security → Security → Use secure DNS → Off/Provider = current.
• Firefox: Settings → Network Settings → Enable DNS over HTTPS → Off (or network.trr.mode = 5).

Q3: Filtering works at the office but not for remote users. Where do I start?
This typically indicates a deployment scope issue. Confirm that the roaming client is installed and active on off-network devices. See: [Roaming Client Setup].

Q4: How can I prove a policy should block/allow a domain?
Use the Visibility Report to simulate per-company/location/device and compare it to the Query Log for real traffic.

Q5: Does DNS Filtering still work if the block page is not shown?
Yes. DNS Filtering blocks the request before the website loads. See: [Understanding DNS Filtering]

Q6: The agent is installed but DNS Filtering isn't working — the service won't start. The most common cause is a port 53 conflict. This is frequently seen on Hyper-V virtual machines, where the host's DNS service already holds port 53. The agent cannot start alongside another service on that port. Remove the agent and configure a Static Location at the firewall instead. See: Agent Fails to Start — Port 53 Conflict.

Still Need Help?

• A sample domain that is not behaving as expected
• Whether the issue affects a location or a roaming device
• A screenshot of the browser result
• Query Log or Visibility Report results for the domain