Changelog

Windows Client 2.2.8 improves compatibility with Microsoft Entra Global Secure Access (GSA) and other VPN environments, including more reliable reconnection on devices with complex network routes. ScoutDNS now keeps public DNS protection active when local network resolvers are temporarily unavailable.

GSA setup is unchanged from 2.2.6. Private Access coexists automatically, and GSA Internet Access still needs the ScoutDNS Block Page IPs in its Custom Bypass. See Microsoft Entra Global Secure Access (GSA) with ScoutDNS for the steps and VPN and ZTNA compatibility (Windows Client) for the full vendor matrix.

Windows Client 2.2.6, with driver 1.0.0.22, adds compatibility with Microsoft Entra Global Secure Access (GSA), so ScoutDNS and Entra Private Access can operate together without disrupting private DNS or tunnel startup. Validated in both split tunnel (GSA Private Access) and full tunnel modes.

How it works

• The client automatically detects an active GSA Private Access tunnel.
• While the tunnel is up, it permits only the required GSA bootstrap and synthetic DNS paths and continues enforcing ScoutDNS policy for ordinary public DNS.
• If GSA disconnects, the exception is withdrawn automatically and restored when GSA reconnects. No manual domain or IP exclusions are required.

Customer action required for GSA Internet Access

If you also use Microsoft Entra Internet Access, add the ScoutDNS Block Page IPs to the GSA Custom Bypass. Without this configuration, ScoutDNS can return the correct blocked response while GSA’s cloud proxy retrieves the original website. Steps and validation: Microsoft Entra Global Secure Access (GSA) with ScoutDNS.

See VPN and ZTNA compatibility (Windows Client) for the full vendor matrix and per-vendor notes.

The redesigned ScoutDNS console is now live for all accounts. This is a ground-up rework of the interface with improved operational flow in every tab, built around the workflows admins and MSPs actually run day to day.

The console

• All-new UI in every tab. Navigation, tables, drawers, and editors were rebuilt for faster scanning and fewer clicks between the things you check most.
• Dark mode. Choose light or dark from the console header.

Allow / block lists

• Major list rework with match and subtree entries. Every entry in a custom list now carries an explicit match or subtree option, so it is clear whether a rule covers one hostname or a domain and everything under it.
• Wildcards now cover both sides of the dot. A single wildcard entry covers the domain itself and all of its subdomains. You no longer need two entries to allow or block an entire domain and its subdomains. See working with allow and block lists.
• Comments on every entry. Any allow or block entry can carry a comment, so the reason a rule exists survives the person who added it.

Zero Trust TLD filtering

• Build from analytics. Zero Trust TLD filtering can now generate a TLD list from your last 30 days of real usage, for any organization, so a trusted-TLD baseline takes minutes instead of guesswork.

Policies

• Secure Score for every policy. Each policy now carries a 0 to 100 Secure Score that rewards defense in depth, with a breakdown showing exactly what to enable to raise it and clear guidance on balancing protection against accessibility.
• New Deployments view. The Policies page gains a Deployments subtab that shows every policy assignment across sites, profiles, and personas in one list, with quick changes right from that view. Assignment still lives on the objects themselves; this is the account-wide roll-up.

Visibility and MSPs

• Stateful site health. Sites now report up or down statefully based on the WANs and relays in each site, so the sites list reflects what is actually reachable rather than just recent query volume.
• MSP dashboard. A new dashboard under the Organizations tab gives MSPs a cross-tenant view of the accounts they manage.

Help site

• Rebuilt documentation. The help site was rebuilt alongside the console, with articles covering every tab and function of the new UI, current screenshots throughout, and full-text search.

In environments where the device runs alongside a VPN or ZTNA tool, the right resolver for an internal namespace is often whichever resolver the tunnel itself provides, not a single static address. This update lets the v2 Windows Client honor that.

What’s new

• Adapter-aware resolver selection in Local Forwarders. For configured internal namespaces, the client can select DNS resolvers associated with the adapter that owns that namespace, including tunnel-provided DNS from VPN or ZTNA clients such as SonicWall CSE, Enclave, and similar tools.
• Configured split-DNS namespaces can resolve through the intended local, domain-controller, or tunnel-provided resolver path while other DNS traffic continues through ScoutDNS encrypted DNS for policy and visibility when the client is healthy.

Beta status

This update is part of the ongoing Windows Client (v2) public beta. The v1 Scout360 agent remains the recommended default until V2 reaches general availability.

For configuration details, see the Windows Client (v2) deployment guide.

The next-generation ScoutDNS Windows Client is now available as a public beta, open to all customers and MSPs who want to try it.

What it changes

• System-level enforcement, not adapter-level. A Microsoft-attested Windows Filtering Platform (WFP) kernel driver intercepts outbound DNS at the network stack. Adapter DNS settings, NRPT entries, GPO-pushed DNS policy, and ZTNA-supplied namespace routing all stay as the customer’s network configured them.
• Better fit with VPN and ZTNA. Because the client does not compete for adapter ownership, it sits cleanly alongside VPN and ZTNA tools such as SonicWall CSE, Enclave, and similar.
• Encrypted-DNS bypass paths. Blocks known public DoH provider IPs and standard DoT/DoQ ports so browsers and apps have fewer ways to route DNS around policy.
• Rust-based system service for predictable long-running behavior on every endpoint.

What stays the same

Control Plane management, profile-based local forwarding, Remote Disable / Forget / Uninstall, automatic updates with rollback, and reporting all work the way customers expect from the v1 agent.

Beta status

The v1 Scout360 agent remains the recommended default until V2 reaches general availability. The two clients can coexist in a tenant during rollout, but a single device should run only one. We are actively taking feedback during the beta.

See the Windows Client (v2) deployment guide for prerequisites, install, and verification.

We launched a complete product documentation site at scoutdns.com/docs, replacing the legacy help knowledge base.

What’s in it

• Getting Started, quickstart for WAN forwarding, dynamic IP setup, setup guide for MSPs.
• Admin Console, walkthroughs of users and roles, MFA, notifications, and how objects (sites, networks, policies) relate.
• Deployment & Agents, roaming client setup, relay setup, VPN considerations, browser HTTPS errors, agent diagnostics.
• Policies & Filtering, working with policies, allow/block lists, Safe Search, YouTube Restricted Mode, custom block pages, category reference.
• Integrations & SSO, Entra ID, generic SSO, SIEM data export.
• API & Reference, API access and authentication.

What’s new about it

• Fast in-page search powered by Pagefind.
• Three-column article layout with section nav and scroll-spy table of contents.
• GitHub-style callouts, numbered procedures, copy-to-clipboard on every code block, image lightbox.
• Mobile-friendly with a collapsible section nav.
• Direct deep-link support from inside the Admin Console.

The legacy help.scoutdns.com knowledge base will be retired in a future release; all article URLs will 301-redirect to their new home.

This is the new home for everything we ship to ScoutDNS, our product, our admin console, our agents, our docs, and our integrations.

What you’ll find here

• New features when we add them ([Added]).
• Behavior changes when we adjust how something works ([Changed]).
• Bug fixes when we resolve issues ([Fixed]).
• Deprecations and removals with as much advance notice as we can give ([Deprecated], [Removed]).
• Security advisories for anything customers should act on ([Security]).

Entries are listed newest-first. Each one has a permalink so the Admin Console (and you) can deep-link straight to a specific update.

Subscribe

There’s an RSS feed at /changelog/rss.xml for anyone who’d rather read changes in their feed reader.

Why now

We’ve outgrown the “tucked in a blog post” approach to release notes. A dedicated changelog gives admins a single, scannable place to see what’s changed since they last logged in, and it gives our team a clean contract to commit to: if it ships, it gets an entry here.