The Umbrella feature in detail

What is Umbrella?

Umbrella® is a service offered by Cisco Systems that provides policy-based DNS protection using a domain reputation database, and identity information from the source(s) of a DNS query. That's putting it very simply! For more details please refer to Umbrella's own website, including the non-DNS components of the Umbrella service, most notably the optional cloud proxy component Secure Internet Gateway (SIG).

Umbrella DNS provides free and subscription services. Any BIND user can configure their recursive servers to forward their DNS queries to the Umbrella recursive DNS service, which will provide the free tier of DNS security. No additional BIND configuration is required beyond forwarding queries to the Umbrella DNS recursive servers.

The subscription service uses the standard DNS protocol with custom Umbrella EDNS options. These options contain information which identifies the source of a query. When forwarding queries to the Umbrella recursive DNS servers, customers with an Umbrella subscription can configure BIND to send the custom Umbrella options. Umbrella compares this information to policies configured in the organization's Umbrella account.

For example, standard users' queries for a known phishing domain can receive responses which map the domain to the IP address of a safe service such as a web page with a warning or denial message, rather than provide the actual A or AAAA record mappings that would be harmful to users. Certain systems could be exempted from this policy based on their internal IP addresses or other criteria, such as those belonging to administrators who may wish to verify whether an Umbrella-blocked site is a phishing site. BIND forwards the IP addresses of the sources of queries (the users' systems) in the custom Umbrella EDNS options.

Umbrella integration

Devices which generate or pass DNS queries to Umbrella resolvers can integrate with the subscription Umbrella service by adding the custom Umbrella EDNS options into queries forwarded to the Umbrella recursive DNS service. Cisco's Network Devices with Umbrella (DNS) integration guide provides a description of the EDNS options format and the fields in the options.

BIND and Umbrella integration

An Umbrella integration is available for BIND which adds the custom Umbrella EDNS options to forwarded queries. Please note that the Umbrella integration is a feature only available in the subscription edition of BIND (that is, BIND versions with a -S suffix). The Umbrella integration is not available in the open source edition. For more information on the Umbrella integration, consult the Administrator's Reference Manual (ARM) for the subscription version of BIND.

In addition to installing the Umbrella integration, recursive queries must be forwarded from BIND to Umbrella's public resolvers both for DNS-only security and for Secure Internet Gateway (SIG) service. The DNS records for the SIG service are not meant to be resolved by normal recursion. Resolution of the SIG service domains such as proxy.sig.umbrella.com must be done by the Umbrella public resolvers.

Configuring BIND for Umbrella

Configuring a BIND resolver to use the Umbrella service requires three steps:

1. List the Umbrella servers

Declare the Umbrella-capable servers (by IP address) that your resolver uses as forwarders. This is done using server blocks, e.g.

server 208.67.222.222 {send-umbrella yes;};
server 208.67.220.220 {send-umbrella yes;};

2. Configure the identifiers

Define one or more identities 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 should be obtained from the account providing the Umbrella service. See the subscription version of the ARM for information on how to use these statements.

In addition to the information added by these statements, the source IP address of the client request is automatically sent in the custom Umbrella EDNS options.

3. Forward queries

Choose what queries to forwarding. Forwarding can be achieved in several ways:

a. Global forwarding

Forward for all queries, outside or inside a view, using configuration like:

forwarders {192.0.2.1; 192.0.2.2; 192.0.2.3;};

b. Forward zones

Forward for specific zones:

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):

zone "example.com" {
   type primary;
   file "db.example.com";
    {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 is forward first, which means try forwarding first and if that fails, try recursing. Recursing can be disabled by using the forward only statement.

Cisco requires the forward only configuration to use Umbrella. When forward only is configured and no forwarders respond then the BIND resolver will respond to clients with SERVFAIL. Caching is disabled for all resource records obtained from Umbrella servers (TTL is modified to 0 seconds) so records cannot be served from BIND's cache.

If forward first is configured and no Umbrella forwarders respond, or if other failure conditions exist, then the next server/IP address queried will likely be one which BIND has learned through normal recursion processing. This server almost certainly will not be one of the servers declared with the send-umbrella statement. When querying a server that is not configured with the send-umbrella statement, no custom Umbrella EDNS options will be sent in the message, and the intended Umbrella policies likely will not be applied.

If employing a security service such as Umbrella, an organization will generally prefer the SERVFAIL result rather than allowing users to circumvent the security service.

What about DNSSEC?

Cisco states that Umbrella public DNS resolvers support DNSSEC. When BIND forwards DNS queries to Umbrella, the Umbrella resolvers will perform DNSSEC validation. Umbrella returns a SERVFAIL response if a requested domain fails validation.

Per the Umbrella Knowledge Base article, Cisco recommends disabling validation done by a resolver for queries forwarded to Umbrella's resolvers. Typically, the additional validation is redundant. Additionally, the Umbrella service can tailor or modify DNS responses to clients, so a DNS query may receive an answer based on Umbrella policy which is different than answers from querying authoritative DNS servers or other recursive resolvers. Disabling BIND's validation on queries forwarded to Umbrella will avoid DNSSEC issues caused by Umbrella modifications.

Among the issues that can arise if validation is not disabled, the most notable occurs when Umbrella policy returns a DNS record with the IP address of an Umbrella block page rather than the actual record. The actual DNS record for the domain may be DNSSEC-signed, but the record returned by Umbrella servers for an Umbrella-hosted block page will not be signed. Umbrella-hosted block pages are the default method of block page configuration.

If BIND is configured to validate DNSSEC for the domain which resulted in the Umbrella-hosted block page, then BIND will request the relevant DS and DNSKEY records from the Umbrella DNS servers and attempt to perform the validation, which will fail. When configured to forward only BIND will return a SERVFAIL response to the client. If BIND is configured to forward first then DNSSEC validation failure will cause BIND to perform recursion. As noted in the previous section, queries will be sent to non-Umbrella authoritative DNS servers, likely resulting in bypassing Umbrella's block page.

Encryption and Umbrella

An additional issue arises from turning off DNSSEC validation when forwarding to Umbrella. Because Umbrella's responses are not validated by BIND in this configuration, the possibility exists of a malicious party tampering with the responses in transit between Umbrella and BIND. Per the Umbrella Knowledge Base article above, the recommended solution to encrypt the forwarded traffic, either using DoT (supported by BIND) or using DNSCrypt (requires 3rd-party software, such as dnscrypt-proxy). This tutorial for building and using dnscrypt-proxy with BIND may be helpful.

Mitigating DNSSEC issues

If DNSSEC errors occur, we recommend first ensuring that your forwarding configuration has the recommended forward only setting. When using a forward first configuration, DNSSEC validation errors are expected in some scenarios.

If a problem still exists after ensuring that BIND is configured with forward only, the ways to mitigate DNSSEC validation issues:

1. Disable validation globally (or inside a view, if views are in use) using dnssec-validation no;. However, if your resolver needs to obtain answers from non-Umbrella sources as well then a per-domain approach may be needed.
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.
3. For block page validation failure, an alternative to the previous two options is to use the custom block page option in Umbrella. The address record for a custom block page's domain name may be signed by DNSSEC without a validation issue because no modification of the address record by the Umbrella resolver occurs.

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

Is there any logging specific to Umbrella?

A statistics counter called PROTOSSOut displays the number of messages sent that contain the custom Umbrella EDNS options option. As the subscription version of BIND is required to generate these messages, this counter is also only available in the subscription version of BIND.

Additionally, Umbrella resolvers support certain Extended DNS error codes, which are useful for troubleshooting DNSSEC issues. As of this writing BIND does not implement EDE options for DNSSEC, so we recommend directly querying Umbrella resolvers with a tool such as dig or delv when troubleshooting DNSSEC issues.

For general debugging of forwarding configurations, this ISC video tutorial contains a segment entitled Instrumenting BIND 9 in which the debugging example is done using a forwarding configuration.