The case for cloud-managed, but on-premises protocol service for DNS and DHCP
Introduction
There is a shift from centralized to distributed architectures, from data center-centric design to cloud-centric design. The best practice for the DNS and DHCP is to deliver the protocols as close to the client (or server) as possible.
In the case of a data center or public cloud, deploy DNS and DHCP where the servers reside. In the case of distributed locations, branch offices and remote sites, install DNS and DHCP at these locations for optimal performance and security. Since the Infoblox solution is cloud-managed, it offers central administration, it is light weight with a flexible form factor, and offers a SaaS consumption model across all locations, providing scale and simplicity.
Direct Internet access for all changes your network architecture
Figure 1: The Benefit of Proximity
DNS requests were traditionally backhauled from distributed business locations to a central data center either for consistency in both configuration and security policies, or to minimize administrative overhead. The shift towards direct Internet access for all locations has broken this tradition. It is well known that local network services provide a faster response to users. What may be less obvious is that local services also provide geo-local responses. For DNS this means finding the closest ingress point on the Internet for cloud applications. In today’s distributed business environment, enterprise DNS servers should be deployed at locations where servers and clients are present.
This raises the question of best practices for locating DHCP services. One might ask, why not serve DHCP queries from public cloud PoPs close to enterprise branches or distributed locations?
Sending DHCP requests to the Internet is a security issue
Since DHCP is an open protocol that does not need authentication, deploying services in the cloud means raw, unencrypted queries go out on the public network. This is a security problem. No encryption solutions are available for DHCP and request/response traffic can be snooped, spoofed or otherwise altered. Standard troubleshooting tools and processes may not be sufficient to identify and resolve issues. Additionally, DHCP is based on UDP, so queries may be dropped or deprioritized. Hence DHCP must be locally served.
Let’s look at some public cloud options. AWS currently supports third-party DHCP in the cloud but requires a dedicated VPN for security. GCP does not support third-party DHCP. Microsoft Azure doesn’t fully support running DHCP services in the cloud. Given that multi-cloud deployment is the trend for cloud computing, customers are needlessly constrained when deploying a common set of enterprise-grade core network services across multiple environments.
DNS and DHCP are core network services that should be as close to the users as possible to provide maximum performance and air-tight security. The right network architecture is to place the protocol servers close to the devices or end users, and manage them from the cloud. This enables local survivability, guarantees reliable performance when accessing cloud applications and provides consistency in configuration and security policy across sites. The protocol server is flexible and lightweight, available as a container, a virtual machine, or a physical appliance. Cloud-managed DNS, DHCP and IPAM is scalable, and delivers several benefits of SaaS-based models such as automatic updates and patches as well as subscription-based pricing.
Visit www.infoblox.com for details.
