In every IT shop in the world, there’s a constant. Three letters that resonate in unison: DDI. This is the magical triplet that enables any modern computer network and contributes to the backbone of today’s Internet. They stand for DHCP, DNS and IPAM. The first two are major protocols that the IP (Internet Protocol) stack and applications rely on, while the latter represents a set of tools and processes for efficiently managing IP networks.
Back in the days of the first IP-based networks, DDI was mostly reduced to a single D: the DNS one. IP allocation was mostly manual, allocations were tracked (when they were!) with pencils and paper, or for the most brazen admins, with spreadsheets. When businesses’ needs increased, more complexity resulted, deployments grew and the need for more rigorous and efficient processes arose. IP allocation became dynamic with DHCP and the first IP Address Management tools were born, allowing IT teams to keep track of networks, ranges, names and hardware address mappings.
Infoblox has been a key player in the DDI world for more than 20 years. It has been delivering DDI solutions using hardware appliances since 1999. A few years later, with the virtualization revolution, DDI solutions could be distributed and deployed on the customer’s choice of hardware. Today, with the advent of technologies like Docker, containerd and Kubernetes, Infoblox delivers its latest DDI solution, BloxOne DDI, as modular containers that can run pretty much anywhere. This is the latest revolution: container-based architecture, a.k.a. cloud-native architecture.
Although the “run anywhere” concept is appealing to many, the reality is not as rosy. Delivering protocols is no easy task. Can anything be delivered from the cloud…? Probably not.
DHCP provides devices with IP addresses that enable IP connectivity, be it LAN, WAN or Internet (and thus to the cloud). Serving DHCP is thus best done on-premises, as it requires access to the network broadcast domain.
DNS, on the other hand, can be served almost anywhere once IP connectivity has been established. There are a number of reasons to serve DNS from specific locations, though, whether for performance, latency, security, or visibility. DNS may thus be run on-premises close to its clients, at the edge or in the cloud. No matter where, this is the exact same function running.
IPAM is a management application. It is primarily an administrative tool that serves a dual purpose by representing both the current and desired state of a network. It pulls data from various functions, such as passive or active discovery, to build the current state, which includes information reported by the DHCP and DNS functions. It also allows administrators to model the configurations that are pushed to these same functions, like DHCP pools and DNS zones. Some of them can be run purely in the cloud, while others like DHCP or discovery obviously require local access to the target networks.
Looking back at the DDI stack, we have enumerated a number of functions that can be implemented as separate, isolated and independent components that can be deployed on a cloud-native architecture. BloxOne DDI is the Infoblox solution that implements those and leverages many of the CNCF projects, directly or indirectly.
As we’ve seen, some of these functions, essentially the management ones, are run in the cloud. They leverage the Infoblox Atlas platform which runs them as containers on Kubernetes clusters, in public clouds such as AWS. The functions requiring an on-premises footprint are also run by the same platform, using the Atlas on-premises extension, which supports delivering protocols from any device capable of running a container, whether a BloxOne DDI appliance, a virtual machine, or a bare-metal system. It’s a matter of pushing the right container there and running it.
Under the hood, each function is implemented as a container or set of containers. Our philosophy is centered around using best-in-class implementations which more than often originate from the open source world, while sprinkling our magic dust on top: a thin management and orchestration layer.
Our DHCP function leverages Kea, which is the next-gen DHCP implementation by the well known ISC organization. This implementation supports a hook extension system that is particularly suitable to our cloud-native model.
Our DNS function is based on CoreDNS, a relatively recent and actively developed DNS server hosted by the CNCF. That function can be deployed anywhere as a stateless container and can be swapped by any other DNS container, implemented by a different vendor such as ISC BIND, for those cases where a feature is not available in one particular implementation. Even better, they can be chained together to implement complex pipelines, like we do in our BloxOne Threat Defense offering.
The IPAM functions are more complex and are mostly Infoblox’s own implementation. They implement the management plane of our DDI stack, adhering strictly to the microservice architecture paradigm. They rely heavily on cloud-native technologies such as Golang for the implementation language and gRPC for the communication channels.
The following diagram gives an overview of how those functions interact together.
A key attribute of cloud-native applications is that functions must be isolated from the system they run on. The deployment method matters, but the location is mostly irrelevant. BloxOne DDI functions may be deployed in a variety of environments: on our BloxOne appliance, of course, but in general on any system supporting the ability to run containers. This includes virtual machines and bare-metal systems, which opens the door to integration with many vendors. The deployment follows a simple and unique methodology, based on the Infoblox On-Premises Agent: a single container implementing the control plane functions and orchestrating the deployment, control and monitoring of each application’s functions.
Infoblox has embraced important industry revolutions, moving from hardware to virtual to cloud-based delivery. BloxOne DDI is the SaaS embodiment of our legacy NIOS application, which has been providing customers with DDI functions on-premises out of physical and virtual appliances. Thanks to the capabilities of the Infoblox Atlas platform, those two worlds will soon be reunited with the containerization of NIOS and the addition of bridging functions, closing the loop and achieving a full cloud-native transformation.
