During 2012, Software Defined Networking (SDN) seemed to be all the rage. The VMware acquisition of Nicira during the summer doldrums for US $1.26 billion validated the fact that the SDN paradigm is expected to have some serious legs over the coming years. I guess the same applies to virtualized network services in general, although the acquisitions in that space were not quite as high-profile as the ones in SDN.

SDN environments consist of a virtualized controller layer containing software-based intelligence required to dynamically formulate and provision routing rules into x86-based commodity networking equipment, leveraging open APIs and protocols such as OpenFlow. In VMware’s vision of Software Defined Data Centre, their vCloud orchestator becomes the source of the data pushed out to the SDN controller, bridging Layer 2-4 network equipment and the dynamic workloads coming and going from the cloud.

The problem I have with VMware’s Software Defined Data Centre (SDDC) stack is that it sort of ignores the biggest concession in networking made to us humans. That is, the DNS. In order for people to be able to connect to the virtual server instances running in the Software Defined Data Centre, they probably expect to use names as opposed to IP addresses, particularly in IPv6 enabled environments.

And of course from the data centre elasticity perspective, using names as opposed to IP addresses is more administrator-friendly too. After all, it is a lot easier to change the IP address of a hostname, than it is to change an IP address in all the clients and equipment that need to connect to a given machine. Bearing this in mind, I think we can rest assured that DNS will continue to have a bright future also in connection with SDN and SDDC. The more dynamic the data centers become, the more utility the good old DNS offers.

With that said, I do believe that standard DNS architectures will have to evolve as the Software Defined Data Centre marches on. To this end, here’s a two-point checklist to all the data centers out there:

1) Dynamic DNS Provisioning. As data center workflows are being automated, there will be very little room for command-line prompt or home-grown scripts. Rather, the DNS platform must have an open API that can be used to provision changes, in real-time. Forget the manual management of static DNS entries, that’s not for the 10s.

2) DNS Management Automations. To make sure that the integration is kept simple, the DNS platform to which the changes are provisioned must include automation features such as creation of slave zone files (when master is created) and reverse mappings; automated allocation of next available IP address; automated generation of names based on user policies; and data validation to make sure an invalid entry does not take down the DNS service. In other words, the whole nine yards.

In many ways, this architecture is actually quite similar to SDN. The DNS primary becomes a virtualized, intelligent controller used to provision changes in real-time to the virtualized DNS secondaries serving out traffic on Layer 5. So in case you happen to work for VMware, please tell your colleagues that without a virtualized DNS architecture such as this, your SDDC stack is not complete.

What remains debatable is the part of the Software Defined Data Centre stack that triggers the changes provisioned to DNS. I will discuss this in my next blog, so stay tuned.