Integration of Infoblox with Cisco Umbrella

[#1]

I am seriously struggling with a task I have been handed by my organisation!

Sounded like a simple task: Set-up Infoblox to forward DNS to Cisco Umbrella. Easy right?

Wrong!

Well I tried, I added the forwarders to the Internal DNS view. Loads of DNS got forwarded, all looked OK. Until the service desk calls started pouring in.

We have a zone livad.liv.ac.uk which is a delegated zone of liv.ac.uk, delegated to our Windows AD world.

Turns out requests for this delegated zone were being forwarded to Umbrella, which had no idea what to do with them and returned NXDOMAIN. I assumed this was the case with the other delegated domains we have, but they are less used so I did not notice.

I have spoken to Infoblox (an SE), to an Infoblox and Cisco partner, to Cisco and nobody seems to have the first idea what is happening and how I fix it. The closest I have come to a resolution is "It should be possible", encouraging but not useful.

My thoughts at the moment are that it was forwarding at the DNS view level that was the problem? Should I configure the forwarders on the Appliance level for the two Internal DNS servers?

If anyone has the first idea about this stuff I am all ears.

The end of my tether is not far away!

We are running Infoblox 8.5.1

[#2]

Hi,

Just wants to clarify, can you share wether the option "Don't use forwarders to resolve queries in subzones" in zone liv.ac.uk was checked or not.

you can see this option in data management > DNS > Zones > edit liv.ac.uk zone. check on at the bottom settings section.

if its not checked, then you need to checked it. otherwise you queries will forward to global forwarders instead of AD

Thanks 

[#3]

When adding default forwarder it will change how subzones are resolved and if they are not manually configured they will be forwarded to the default forwarder, only records in the configured zone is resolved localy. NS records in the zone for subzones will not be used and the query will be forwarded.

As mentioned you can check the "Don't use forwarders to resolve queries in subzones", this will then mean that all subzones in liv.ac.uk will not be resolved by the default forwarder.

Depending if the zone liv.ac.uk have split subzones internal and external you should choose the option that fits your situation best.

If there are subzones externally that will be resolved by default forwarder configure additional zones manually for the internal zones.
If there are no external subzones and additional NS records in liv.ac.uk that should resolve internally check "Don't use forwarders to resolve queries in subzones".

This is my experience from a complex scenario that may not exactly match yours but should explain what is happening.

You can configure default forwarders at view or member level it should not matter for this question.
I recommend to do a stage configuration in a seperate lab to verify the logic works as intended before deploying in production.

I'll hope it helps you decide next steps.

[#4]

The "Don't use forwarders to resolve queires in subzones" option is not checked, so I think you have hit the nail right on the head!

I can check this, then configure the forwarders and we should be good to go.

[#5]

Very useful thanks.

We do have an External view that is hosted by different servers and has some of the same sub-zones under liv.ac.uk has in the Internal view does. The NS records in the External versions of these zones would point to the external servers and not back into the internal ones. So I am assuming no special config would be needed.

We are not planning on using forwarders for the external view at all, just the Internal view.

I had a feeling that there was a "Don't do this, do somethign else" button, I just did not know where it was!

I will start by auditing the authoratitive zones and their sub-zones to see what the effect of enabling "Don't use forwarders to resolve queries in subzones" will be, but I think it will in fact fix things for us.

[#6]

Hi,

glad to hear that.

Thanks

[#7]

Hi, this is a very simple problem to solve. Sorry, no one assisted. Any legitimate domain you want to resolve internally must be put on the internal domains list. By default Umbrella, VA's and AnyConnect clients will always send *.local domains to the local authoritative resolvers. Remember that Infoblox is an authoritative DNS, DHCP, and IPAM solution. Umbrella is a purpose-built DNS security and content provider.  It is purely are recursive resolver. Any public queries will resolve with the public IP's. Umbrella will not resolve any RFC 1918 hosts (10.x.x.x/8, 162.16.x.x/16, and 192.168.x.x/24) So if your topology is Virtual Appliance-->Infoblox-->Internet all Public domains will be sent directly encrypted, authenticated and internal IP embedded to Umbrella. Any internal domains (configured in the Umbrella Dashboard) such as *.intranet.mypubicdomain.com will be sent from the Virtual Appliance to the Infoblox Appliance for authoritative resolution. Umbrella and Infoblox coexist in 50% of my customers networks. 

[#8]

If you are using the CISCO AnyConnect Secure Client or other VPN solution, there are some basic configurations for the network DNS traffic. If you are not using "slit tunneling" (where users can use their own network for Internet access and the VPN tunnel is used for Intranet access to the private corporate apps and such) the AnyConnect client with the Umbrella module install will "proxy" all DNS request to the Umbrella DNS servers (On the intranet, your internet DNS servers would be set up as DNS forwarders to Umbrella DNS Servers). Even if the VPN client is connected or disabled, all DNS requests are forced to the Umbrella DNS Servers. This is done through a proxy process within the OS network setting. Umbrella uses a proprietary process on Windows and on Mac, they use the proxy process which is built in to the MacOS. Basically, all DNS requests get sent eventually to Umbrella DNS servers for final DNS resolution on the Internet. Even if you are not using split tunneling, then the overall process is the same. Since your VPN more than likely is using DHCP for IP/DNS entries, once the client connects to the VPN then the Intranet IP/DNS will be primary and all DNS calls will go to your Infoblox. If the VPN client is disconnected/off, the local LAN DHCP/Static IP/DNS entries are primary. But the Umbrella client or AnyConnect Client Umbrella module will push all DNS calls to the Umbrella servers, even if the DNS is cached locally or within a DNS Server. No calls are directly sent to WAN Root DNS Server or Primary DNS Server for that Domain. It is true that all Intranet Domains need to be entered into the Umbrella management GUI in the Child-Org if you have a Multi-Org system, or directly into your primary Org for a single Org system (wild cards are excepts so not need to put multiple URL entries). The entries are inputted via the left-hand menu list under "Deployment" --> "Domain Management" --> "add" (upper right corner of the main window). Once you have the popup window open, you can enter the Domain(s) as needed. Insure all internal Intranet Domains are entered. Make sure to use "Save" to close the window, or the entry will not necessarily be maintained. I hope this helps clarify the process.

[#9]

As a point of reference, Umbrella utilized DNSCrypt for secure DNS traffic. The Umbrella DNS server will except DNSSec and handle it just fine. TCP or UDP port 443 for protocol transfers.