A beginner's perspective on OpenStack Designate

I'm at the OpenStack Summit this week in Barcelona.  Beautiful place, but a conference center is a conference center.

My first session today was an introduction and discussion of Designate, the OpenStack DNS control module.

I've been working with OpenStack for VM instances and with OpenShift to run container services in the cloud.  One major issues that always gets back burnered in discussions is DNS.  I refer to this as publication, an unusual term but I think the best one to describe a critical aspect of IaaS and PaaS cloud services.

The point of these services is self-serve computing resources, most often services you can offer to others.  If you have no way of telling others where to find your services... they cant.  DNS is the way you tell people where to find your stuff.

Historically the DNS service has been managed by an IT "priesthood" who are rightfully protective.  DNS is the first and most critical service on any modern network.  It's largely invisible and it works so well that most sysadmins don't actually understand how it works.  DNS is one of the last services to fall to the self-service mind-set of cloud computing and that's with good reason.

I was under the misconception that Designate would be solely a dynamic DNS service that would be used to publish new instances or containers within the service.  I also thought perhaps it had its own front end to respond to queries.  It quickly became clear that Designate is not very useful without those external front-line services.

Listening to the talk it became clear that the Designate developers also see this conservatism as a barrier to adoption.  A significant portion of the talk was dedicated to creating roll-out plans that build confidence slowly, absorbing more and more of the wild barnyard of existing services.

Designate seems to be more of a control plane and database for DNS services than an actual front-line server responding to queries. You continue to run BIND or Active Directory/DNS or Infoblox to respond to queries, but the database is stored in the OpenStack service (with a back end DB?) and the database propagates to the caching or front end DNS services.

This leads to the idea of Designate eventually taking over control of all of the DNS services in an enterprise.  It has the capability to define roles for users, allowing fine grained control of what actions  user can take, while offering for the first time a true kiosk self-service IP naming mechanism.

I know how I plan to use Designate in my OpenShift and OpenStack service deployments.  It appears I may still need to create backing DNS servers, but I'll at least get WebUI and API change management for the masses.  I've used nsupdate to create dynamic DNS zones before, but it always seemed to scare other people off.  With Designate I'm going to be able to deploy both my new services and containers within them and publish them with the short turn-around a cloud service demands.

• OpenStack Designate