The Umbrella feature in detail

What is Umbrella?

Umbrella® is a service that has been offered by Cisco Systems since 2016 to provide domain level protection through active maintenance of a domain health database. That's putting it very simply! For more details please refer to Umbrella's own website

Paying customers can forward their DNS queries to the service, which replies with appropriate responses depending on the question that was asked. For example, queries for known phishing domains will be directed to a safe place rather than give the actual answers, which would be harmful to users.

The service uses the standard DNS protocol but with a custom extension, carried in EDNS. This extension enables communication of extra parameters with the Cisco Clod Security API, described here.

BIND and Umbrella

Firstly, please note that Umbrella integration is a feature only available in the subscription edition of BIND: that is, versions with a -S suffix. It is not available in the open source edition. Configuring a BIND resolver to talk to Umbrella services requires three steps:

1. List the Umbrella servers.

Declare the Umbrella-capable servers (by IP address) that your resolver will potentially be talking to. This is done using server blocks, e.g.

server 192.0.2.1 {send-umbrella yes;};
server 192.0.2.2 {send-umbrella yes;};
server 192.0.2.3 {send-umbrella yes;};

2. Configure the identifiers.

Define one or more identifiers to be sent to those servers using any or all of these configuration statements:

umbrella-virtual-appliance
umbrella-organization
umbrella-device

Which identifiers to use and what values they should take will have been supplied by the agents providing the Umbrella service. See the BIND subscription edition ARM for information on how to use these statements.

3. Forward queries.

Having set the framework, choose what queries to send to which servers through forwarding. Forwarding can be achieved in several ways:

a. Global forwarding

Outside or inside views, using configuration like this:

forwarders {192.0.2.1; 192.0.2.2; 192.0.2.3;};

b. Forward zones

For specific domains, like this:

zone "example.com" {
   type forward;
   forwarders {192.0.2.1; 192.0.2.2; 192.0.2.3;};
   };

c. In-zone forwarding

Declaration of forwarders in other zone types that support them; e.g. primary, secondary, stub and so on (see the ARM for details). Like this:

zone "example.com" {
   type primary;
   file "db.example.com";
   forwarders {192.0.2.1; 192.0.2.2; 192.0.2.3;};
   };

delegated   IN   NS   different-ns.somewhere.

Forward first or only?

If no servers in the forwarders list respond, BIND needs to know what, if anything, to do next. The default, unless disabled with forward only, is forward first, which means try forwarding first and if that fails, try recursing.

If this happens, no custom option will be included in the message and it will be a standard non-recursive query.

If forward only has been declared (which we usually recommend) then if all forwarders are unresponsive the resolver will respond to the client with SERVFAIL.

What about DNSSEC?

Since the Umbrella service is designed to provide tailored responses to clients of resolvers configured to use it, it is unlikely that the resolver will be able to validate responses coming back from an Umbrella service.

There are a couple of ways around this:

1. Disable validation globally (or inside a view, if views are in use) using dnssec-validation no;. This is an all-or-nothing approach, so if you forward everything to an Umbrella service consider whether this might be appropriate. However, if your resolver needs to obtain answers from non-Umbrella sources as well this is probably not a good way to go.
2. Disable validation for specific domains using validate-except {domain-1; domain-2; ...;};, which can also be used globally or inside views (if in use). This tells the resolver to not validate names at or below the specified domain(s) listed.

One suggested configuration would be to implement Umbrella forwarding inside a view dedicated for that purpose and to disable DNSSEC validation inside that view along with it, leaving other views to be configured differently, with validation still enabled and automatic.

Is there any logging specific to Umbrella?

There is no specific logging for this feature because, under the hood, it is just forwarding. The only difference being the addition of the custom EDNS option to a query. However, a patch is available on request that will enable a new statistics counter called PROTOSSOut, which displays the number of messages sent that contain the this option.