Policy configuration best practices - BlueCat Edge - Service Point v3.x.x

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 www.facebook.com 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.

Domain lists

You can add domains to block, allow, or watch manually, or you can create a list of domains as a .csv or text file and upload it. If you upload a file, it should contain one domain per line, with no commas.

Policy definition example

Consider the example of a retail organization. Such an organization might be made up of corporate offices, and retail locations. Policies may treat corporate offices differently than retail locations. At a retail location, the organization may also have different classes of devices. For example, Point of Sale (PoS) systems, a Wi-Fi network for guest access, and a network for employees. In a scenario like this, you might want to define policies that reflect those different types of users and devices.

Imagine that your organization was arranged like this:

Policies would be defined for each type of the device or user class, and then grouped into sites and site groups. The result would be a policy structure like this:

• Managers Site Group
  • New York Site
    • Managers Service Point
• Paris Site
  • Managers Service Point
• Employees Site Group
  • New York Site
    • Employees Service Point
• Paris Site
  • Employees Service Point
• Point of Sale Site Group
  • New York Site
    • Point of Sale Service Point
• Paris Site
  • Point of Sale Service Point
• ...

With a policy arrangement like this, you can apply the same policy to all users or devices of a given class. You might configure policies to allow employees to only resolve names for work-related web sites, but allow managers access to a broader list. You might also restrict name resolution for PoS systems to only a handful of remote systems and only during business hours, and deny name resolution for anything else or at any other time of day.

BEST PRACTICE: Use site groups for the broadest policy enforcement.

For example, many organizations choose to implement block lists for known bad domains at the site group level across the organization so that the protection it offers covers the broadest range of devices. You can then use site-level policy to apply exceptions to the broad policy. For example, if a federal law in France prohibits corporations from blocking access to social media sites, but there is no such restriction in the United States, you could use the site-level policy (called “Paris Site” in the example above) to allow resolution of those sites in France.

More granular controls can be used by applying policies using subnets or individual IP addresses. As an example of IP level restrictions, consider an employee who is on a performance improvement plan where one of the parameters of their plan is that they will not browse personal sites during work hours. Using an IP-level policy, you could activate a policy that would monitor every query that employee makes so that you can later report on whether they met the terms of their plan. Likewise, assuming your M&A team could be contained within a single subnet, you could implement a subnet level policy that allows you to exclude the M&A Team from the policy blocking resolution of competitor sites, but block access to them from all other networks or locations.