Best Practices for DNS Policies

Creating DNS policies, ordering them, and then having them protect your organization and systems exactly how you need them to takes planning and an understanding of how Umbrella's DNS policy work. We strongly recommend that you plan your DNS policies before you start adding them to Umbrella. Thus, to help you get started, we recommend that you first read through these DNS policy sections of our documentation in full. Decide before you start as to how to want Umbrella to protect your organization and systems.

DNS Policy behavior
Umbrella DNS policy enforcement works on the principle of implicit allow—meaning, if something is not explicitly blocked, such as a security category or a destination, Umbrella allows the transaction. Some transactions can be explicitly allowed; for example, destination or application requests. Explicitly allowed destinations cannot be explicitly blocked, except in the case of anti-virus (AV) or AMP file reputation matches. DNS policies are evaluated toward an identity starting at the top of the DNS policy list and moving downward until a match is made. Thus, the first identity to match a DNS policy is the DNS policy enforced. Therefore, always configure your DNS policies so that the first DNS policy listed that includes a particular identity also includes all configuration settings you want applied to that identity. Once a DNS policy is matched, Umbrella stops evaluating.

Build your DNS policies from the bottom-up—start with the Default DNS policy
The Default DNS policy applies to any identity that does not match any other DNS policy. If you have an identity that is not selected for a policy, the default policy is applied to that identity. Your default policy is the one that you rely on if an unknown or unexpected device or user attempts to access the internet from within your network. As such, we recommend that you always make the default policy your most restrictive policy. Also, consider making your default DNS policy the one through which the majority of your users and devices are governed.

Build additional policies as exceptions, from least specific to most specific
After configuring the default DNS policy, build DNS policies from least to most specific. For example, you might create an additional DNS policy for "All Roaming Computers," then layer another DNS policy on top of that for a small number of roaming computers that have slightly different requirements. By taking this "exception-based" approach you are less likely to encounter any unintended results.

Utilize the top-level groups of identities when possible
Top-level groups like "All networks" and "All Roaming Computers" are special because they dynamically inherit new identities. This means that if you create a DNS policy for "All Roaming Computers," and then, after the fact, provision several new mobile devices, they automatically have that DNS policy applied to them. As a best practice, these DNS policies should be lower in priority than more specific DNS policies or the top-level group DNS policies will take precedence over any DNS policies which include more specific identities, rendering those DNS policies useless.

Use tags for groups of roaming computers
A tag is a way to group roaming computer identities together. Use tags to manage large numbers of roaming computer identities when configuring DNS policies. If you expect to have hundreds or thousands of roaming computers in your Umbrella deployment, we suggest using tags when creating a DNS policy. For more information, see Group Roaming Computers with Tags.
Note: Tags are only available for roaming computer identity types.

Organize DNS policy settings for reuse
Various DNS policy settings can be reused across multiple DNS policies. Keep this in mind when you create, name, and update settings. For example, when creating destination lists, it is best to organize destination lists so that multiple DNS policies might use a general-use destination list; for example, "Block Social Networks." Create destination lists within the DNS policy wizard only for those unique destinations that are needed for a specific DNS policy—destinations you don't need to share.

Layer your DNS policies according to location
If you are using Cisco Umbrella with roaming or mobile features, you can create location-based DNS policies. The most common example is to first create a security-only DNS policy (for example, no content filtering) for all of your roaming laptops, then create a more restrictive DNS policy for your corporate network—ordered above the roaming laptop DNS policy. This is counter-intuitive to the idea of organizing your DNS policies from least to most specific, but in this case, it means that when your roaming laptops enter your corporate network, they must adhere to the more stringent DNS policies of the workplace. While outside of the network, however, users still have a layer of security wherever they go but are free to visit whatever websites they choose.

Configure the Intelligent Proxy
Configure the intelligent proxy with SSL decryption in a DNS policy. The intelligent proxy inspects web traffic for domains that Umbrella considers uncategorized or risky. For more information, see Manage the Intelligent Proxy.
We do not recommend that you apply the same deployed identities in both your DNS policies with the intelligent proxy configured and Web policy rules with SWG controls enabled. Choose the type of policy, deployments, and configuration components that best match the identities and traffic in your organization.

---

DNS Policy Precedence < Best Practices for DNS Policies > Enable SafeSearch for DNS Policies