Webroot now offers a “DNS Protection” service which is designed to prevent DNS poison attacks. Two elements of this service are worth noting:
- How DNS queries are made when Secure DNS is enabled: Rather than UDP/TCP port
53being used for DNS queries, Windows computers that use Webroot will instead use UDP port
7777as a first priority, thereby bypassing the standard DNS services (if outgoing UDP port
7777traffic isn’t blocked)*.
- If a DNS response mismatches a publicly-resolved entry, the browser’s connection is blocked.
The result of the above is that ADAM’s services are impacted as follows:
- Forced DNS responses are bypassed: The standard DNS service (UDP/TCP port
53) is re-directed to the local resolver, by default, on all of our platforms in order for all DNS queries to be forced to your desired policy/rule set. But since Webroot uses an alternate channel, Webroot disables forced filtering at the gateway.
- Blacklisted domains (or non-whitelisted domains) are allowed through, effectively disabling DNS firewall/blocking altogether.
- Internal tools such as mytools.management disallow the Windows browser from connecting.
For static workstations that will stay behind ADAM gateway, disable Secure DNS roaming agent service. Instead, use Webroot’s Secure DNS servers (
188.8.131.52) in the ADAM dashboard under Advanced Settings and use them as a resolver of last resort. That way you can take advantage of what ADAM policy-based filtering offers together with the protection that Webroot has to offer.
By the way, we think Webroot’s Secure DNS service is a fantastic feature, but the implementation has created a conflict that disregards the subscriber’s intent.
*Some subscribers have blocked outbound UDP port
7777 traffic, which achieves the result of ADAM’s policies being enforced, but that creates a very slow experience as Webroot takes some time to fall back to using port
53. The experience makes it less than ideal.
Also, it’s worth noting that with DTTS (Don’t Talk To Strangers), the DNS protection (or any other alternate type service) never impact your applied policies/rule sets.