Feature Requests

Can we have a policy page to enact the following platform specific blocks of DNS over HTTPS, preventing the use of this technology to bypass DNS Filter. Disable / Lock the use of DNS over HTTPS in -Chrome -Edge -Firefox -Brave -Windows 11 (native DNS client) All of the browser can be done by inserting the relevant registry key to enact the browser control policy. Windows 11, can be done by running the following command netsh dns set global doh=no # DNS over HTTPS netsh dns set global dot=no # DNS over TLS We are implementing these controls ourselves, but it would be helpful to have this packaged into the DNS Filter platform and maintained here, to form a complete solution.

We have issues where CNAME's that don't display a website, such as a redirect for email services like Sendgrid, have a category of 'landing page' which we block. This results in inacurate blocks, as the underlying service is legitimate, but the CNAME has a different category.

We have issues where CNAME's that don't display a website, such as a redirect for email services like Sendgrid, have a category of 'landing page' which we block. This results in inacurate blocks, as the underlying service is legitimate, but the CNAME has a different category.

We have issues where CNAME's that don't display a website, such as a redirect for email services like Sendgrid, have a category of 'landing page' which we block. This results in inacurate blocks, as the underlying service is legitimate, but the CNAME has a different category.

DDNS resolvers are inadequate for certain deployments involving double NAT (such as satellite connections) or very fast-changing WAN IPs (as with trains or other high-speed travel). Fail-Open Relay DNSFilter needs develop a fail open relay service for when DDNS resolvers don't work. This solution would work similar to ScoutDNS's relay solution pasted below. "When enabled, the ScoutDNS relay will no longer depend on any known WAN IP interface after its initial cloud-based adoption. Instead, the relay will use a unique identifier, similar to our roaming clients, to track usage. This usage remains linked to the site or location for logging purposes, so no site or query visibility is lost. Relay deployments on mission-critical networks can now enable the fail-open state on their relays. This allows you to configure up to four third-party DNS resolvers as fail-open upstream services, providing maximum uptime protection against localized and regional peering issues."

Fabio and the team at Tivly have expressed interest in a dynamic, auto-maintained list of airline and captive portal domains that can be applied across DNSFilter deployments to reduce manual overhead and improve reliability when traveling. Tivly has experienced issues where DNS resolution fails in environments such as airports or airplanes, primarily due to the need to manually maintain a local domains list for captive portals. These disruptions are particularly problematic for users who travel frequently and rely on seamless connectivity in transit. Requested Feature: A built-in, dynamic list of known captive portal domains, particularly for airlines, airports, and public Wi-Fi providers DNSFilter should maintain and update this list centrally (similar to threat feeds or content categories). Option for customers to opt-in to apply this list globally or per-policy Ideally complements or integrates with the existing Local Domains functionality Customer Value: Reduces administrative burden and reliance on guesswork for domain inclusion Prevents common DNS resolution failures for traveling users Improves user experience and confidence in DNSFilter coverage during travel

Ninjarmm Integration

Essentially, do the same as Amazon S3: "Push DNSFilter logs in near real-time batches to an Amazon S3 bucket provided and managed by your organization." Just push to Azure Blob Container instead of Amazon S3 bucket. This would be very helpful for companies with Microsoft-based environments!

As an admin, I would like the ability to stop users from uninstalling the DNSFilter macOS RC. This would be for users who have admin accounts on the computer.

I don't know if that would be technically possible, but it would be a great features to get the Hostname or the Username of the Roaming Client in the block page notice email.