Internet (de)centralization

Since its “birth”, the Internet was decentralized like a well-organized chaos. Globalization and Cloud adoption lead us to a world where the same service can be provided from different locations aiming to be as close as possible to the service’s consumers. A couple of years ago this “ideal world” started falling apart with the centralization of DNS services among a small number of global DNS service providers. 

You may already know that DNS is a core Internet service and used in many ways, including traffic routing. Any DNS outage leads to broken communications and business impact. We already witnessed outages (not only for DNS) caused by attacks and misconfigurations where literally half of the Internet for some consumers was not accessible and these were just the first signs that one day we all can be “offline” for hours or even days. What can be considered as a minor disturbance for consumers, for enterprises may lead to huge losses and in extreme cases even bankruptcy. 

There was a lot of talk about how DoH pushed from Internet browsers would centralize the Internet but no one highlighted that all enterprise-grade, cloud DNS services actually do the same. Enterprises became dependent on provider’s points of presence (PoPs) and connectivity to them. Even if your DNS service provider has hundreds of PoPs (unlikely) the issue still exists. I do not mean that there will be an outage with the service itself but it is likely that there are multiple providers in between, and your business depends on the reliability of all of these 3rd party providers without you having any direct contract to support it (signed by you or your vendor). That just increases the number of possible failure points you may or may not need to take into account while choosing a vendor. 

Infoblox has more than 20 years of experience running DNS service for our customers with almost 50% of DDI market share and we were thinking of how to solve the DNS centralization problem and came up with a brilliant idea (honestly speaking it wasn’t my idea but I run it from the product management side), just let DNS do that which it is meant to do (just resolve DNS requests), and do it on customers’ premises (on-prem) with extended security from the cloud. 

Sounds good? Let’s see how we did it and what options our customers have.

Unconditional on-prem DNS resolution

You would ask how it works – lets take a look at the diagram below and follow it step by step.

1. A client wants to connect to “example.com” and a browser sends a request to DNS Forwarding Proxy (DFP) which is integrated with BloxOne DDI DNS service (B1DDI DNS).
2. DFP has an internal policy engine and validates if “example.com” is already a known domain which is used for DNS Exfiltration/Infiltration/Tunneling.
3. If the request was not blocked locally, B1DDI DNS resolves the domain by sending requests to root DNS servers and authoritative DNSs for “.com” and “example.com”.
4. Authoritative DNS responds back.
5. The request and the response are forwarded to BloxOne Cloud for security policy validation. 
6. If the request is identified as malicious or should be blocked by a policy, the response will be altered.
7. DFP will cache the results and respond back to the client.
8. The client can (or can not) connect to “example.com”.

So what are the major benefits?

1. Are you running a business in China, Russia, Zimbabwe or Argentina where your DNS service provider will unlikely deploy PoP? – No problem. Your employee will get the same experience as using local ISP DNS servers because all DNS requests are resolved on-prem and a client will be able to connect to a nearest data center, means that the SaaS application latency will be minimal and in some cases he or she will enjoy a localized version of an application (if the app enforces language settings per data center). 
2. A client doesn’t depend on communications to the DNS service provider and, with a fail open architecture with base protection on-prem, can be sure that multiple potential points of failure are eliminated. For customers who prefer a fail closed architecture – see below. 

You may think, what are the potential downsides of the approach? 

1. Obviously the first DNS request will be resolved a bit longer in comparison with cloud only resolution but keep in mind that it will be the first request only and all following requests will be responded from a local cache.
2. You will lose some privacy and your organization may be profiled due to un-encrypted communications with root and authoritative DNS servers (DNS over TLS and DNS over HTTPs for communications between DNS servers).
3. You may not like the fail open configuration. 

The first issue is addressed by a solid DNS design and we have you covered if you want to handle issues 2 and 3 – just don’t enable the local resolution at all or for locations/roaming clients you concerned about (the feature is enabled per security policy) or just enable it per application (described below).

The local resolution feature is disabled by default and there will be no changes to how the service works right now. To enable it there is a toggle button per security policy.

Prerequisites:

• Unconditional on-prem DNS resolution requires BloxOne Threat Defense and BloxOne DDI subscriptions
• DFP and B1DDI DNS services should run on the same on-prem host

On-prem DNS resolution per application

You should already get the idea of how unconditional on-prem DNS resolution works, so what is the difference with on-prem DNS resolution per application?

The idea is similar but instead of resolving all domains on-prem and potentially leaking a lot of information to 3rd party services you may enable on-prem DNS resolution only for applications which are relevant for your business.

Yes, you read this right, you can enable it per application. For example, if your company uses Microsoft Office 365, Microsoft Azure, Salesforce, Dropbox, Google suite etc, you can create a policy rule to enforce on-prem resolution for such applications. 

So how it works:

1. DFPs and BloxOne Endpoints receive list of application and associated domains from the Cloud
2. When a request is received for one of the domains:
   1. DFP will use configured 3rd party fallback DNS servers to resolve the request. Please be sure that such a DNS server is nearby.
   2. BloxOne Endpoint will forward the request to network provided DNS servers.
3. Other requests will be forwarded to BloxOne Cloud as usual.

You should trust the applications because in this case security validations are bypassed except if you are using a secure 3rd party DNS service (e.g. Infoblox NIOS with DNS Firewall feeds).

The feature works with standalone DFPs, DFPs running on NIOS and BloxOne Endpoints.

Prerequisites:

• On-prem DNS resolution per application requires a BloxOne Threat Defense subscription.
• a 3rd party fallback DNS server should be configured per DFP.

A few closing words

Internet centralization is an issue which may not only lead to disastrous outages but provides a few big DNS provider companies with monopolized access to users’ data. With Infoblox’s hybrid approach you can deploy services on-prem, in the cloud or “mix and match”, so you can choose what is most important for your company, deploy a relevant architecture and enjoy local DNS resolution even with a cloud only solution.