When implemented, policies define how a particular DNS query is responded to based on the query itself, a threat assessment of the query, and the response that is received from the DNS forwarders defined in the namespace handling the request. Queries or responses that match a defined policy may be always answered (TRUST), answered but logged (MONITOR), blocked (BLOCK), or the answer may be overwritten to re-direct a client to a different server (REDIRECT).
In many cases multiple policies will be associated with a Site configuration. In this instance policies are evaluated in the following order: 1) Trust, 2) Block with Redirect, 3) Block, and finally 4) Monitor.
A policy describes a DNS conversation and the outcome you want to create. For example, a policy might restrict successful DNS queries to business hours and return NXDOMAIN outside of normal business hours. A policy can also resolve a query to a policy enforcement site. For example, if your organization doesn’t want users logging into Facebook from corporate networks, the policy can redirect the name to an internal server that displays a reminder that social media sites aren't to be accessed.
Policies can be applied at the site level or site group level. You can also use subnets or individual IP addresses to further refine policies. Therefore, before you begin deploying service points, it makes sense to begin defining policies. The policy definition will ultimately define how many site groups, sites and service points you need and drive the implementation plan. The implementation plan then is focused on the deployment of service points and re-directing devices to use them instead of the legacy DNS servers in your environment.
When you deploy, remember that to achieve the desired policy outcomes and collect the data you want, service points need to be “close” to the client devices. A service point should always be the first hop resolver for devices querying DNS. This is the most effective place to make policy decisions, and knowing the IP address of the client that issued the query is important for later data analysis.
Policies can be defined in the way that suits your organizational structure and priorities. For example, a policy implementation might separate employees from visitors, or corporate devices and networks from BYOD devices. Policies could also reflect different requirements by geography (for example, US and EU policies), or could model an organizational hierarchy.
Like any policy-based system, the results you achieve depend in a very tangible way on the effort you put into defining your policies. Defining your policy allows you to consider what you want to detect, prevent, and what actions you want to take in reaction to incidents or events. This correlates directly with how effective the system is once it’s operational.
- BlueCat recommends defining a Trust policy that is applied to all sites that includes a Domain List containing, at a minimum, all internal zones. This will prevent any other policy or threat detection from inadvertently blocking trusted internal traffic.
- BlueCat recommends defining a Monitor or Block policy using the BlueCat Threat Protection High Domain List. This Domain List contains high-confidence threat intelligence from BlueCat’s OEM provider that should be blocked unless explicitly overridden by a Trust policy.
Policy matching
- If you are configuring a policy where multiple criteria are selected, the policy action is taken only when all of the conditions are met. For example, if you configure a block policy and you specify a Block List and Query Type, the policy action is only enacted on queries that are found in the block list and match the specified query type.
- If a DNS query matches all conditions for multiple policies with different redirect destinations, the query is answered with one of the redirected destinations in a random order, resulting in unexpected behavior. Configuring policies with overlapping conditions that can result in a query matching more than one policy is unsupported.