DNS Pre-Check for Windows Agent
now
Kate Trojanowski
Classic DNS filtering on roaming devices often depended on changing DNS settings. On networks the user doesn’t own—such as hotels, public Wi-Fi, or shared corporate environments—this could cause conflicts with other software and reduce reliability.
The new DNS Pre-Check capability modernizes protection by introducing a transparent DNS proxy that validates and filters queries locally before they leave the device. This eliminates the need to modify DNS settings, ensures filtering works across untrusted networks, and helps preserve connectivity wherever users connect.
To support this capability, the Windows Agent will include a Filtering & Connection Mode framework. Instead of the agent deciding behavior automatically, administrators can configure three dimensions directly from the Dashboard:
- Connection Mode: Transparent Proxy or DNS Loopback (how queries are intercepted).
- Filtering Mode: Classic DNS or DNS Pre-Check (how queries are evaluated).
- Failover Mode: Fail Open or Fail Closed (what happens if filtering cannot be reached).
For ease of deployment, these are also available as presets:
- Standard (Recommended): Balanced filtering and connectivity.
- Strict (High Security): Always enforce filtering, blocking access if filtering is unavailable.
- Custom (Advanced): Mix and match connection, filtering, and failover modes as needed.
Kate Trojanowski
Merged in a post:
Improve the Captive Portal Experience for Windows Roaming Client
Vincent
Create a list of all hotel, airline, restaurant, free wifi hotspots to bypass and use localDNS resolver so that we don't need to turn off the app
The list should be accessible within the UI so admins can select what can be bypassed
Kate Trojanowski
now
Graham, Joe
We are currently rolling out the Windows Roaming Client to 6000+ highly mobile employees. They travel all over the world and not just the U.S. Having something automated and happens in the background would be ideal. A tool in the portal to somehow identify these or a RC that just can handle Captive Portals all togehter. Or at the very least, the Windows RC needs the same ability as the MAC OS RC. just right-click and choose Access Captive Portal. having to manually maintan a list is not a way an admin wants to go about this.
Nick Saunders
Merged in a post:
Captive Portal / Traveling Exemption
Jim Luttinen
We have several clients who travel quite a bit and captive portals have been the bane of our existence. Administrators should be able to place a device into "travel mode" or some type of "learning mode" to pull captive portals into a database so we do not have to add these to each site. The roaming client is useless if they can't roam with it.
Alex Perrot
We should also have an option, as the tenant admin, to have the client fail-open completely if it's unable to reach DNSFilter's servers and utilize whatever DNS is available via DHCP. I know this isn't ideal for all situations, but it completely resolves the captive portal issue.
Something where the roaming client fails-open upon a connection issue, then continually tries to regain connection, should be a good balance of ease of access and security.
Of course, this should be optional.
Evan Mandel
I would also like this feature..not sure if it should be a separate request?
S
Steve Staden
Evan Mandel: I do consider it separate and we're discussing a fail-open option that admins could configure. I believe this request is for that - https://dnsfilter.canny.io/known-issues/p/roaming-client-failover. I think I'll should adjust the title just to it's more clear.
Justin Esgar
I don't want just a list, I want the system to be able to detect and allow it automatically. The amount of tickets we are seeing from clients recently is on the rise. Sending clients to captive.apple.com has stopped working also. There needs to be a holistic fix to this issue.
Preston Mainard
I think the client needs to be able to determine if a captive portal is present, and then divert to local DNS or provide some sort of way to passthrough the queries.
A master list of captive portals will always be one step behind as there is no way to ever know every single CP address that exists.
S
Steve Staden
Merged in a post:
Hotspot failure for roaming clients
Sean Ardizzone
When joining hotspot's like Mariott's wifi for example, the roaming client can't reach the internet to resolve DNS so ultimately the wifi network can't be joined. Is there a way to solve this? Similarly when traveling on airplane wifi, same issue. roaming client had to be uninstalled so service could be joined