Home > Blogs > OpenStack Blog for VMware > Monthly Archives: July 2018

Monthly Archives: July 2018

VMware Integrated OpenStack DNSaaS – Designate Deepdive

Written by Xiao Gao, with valuable feedbacks from Damon Li.

DNS is essential to nearly every cloud application, and it is almost unimaginable to launch any cloud service without a robust DNS implementation.  Booting a VM in OpenStack takes seconds.  However, for most OpenStack operators, once a VM is booted, the first step towards production is to manually create a ticket to register the IP address with the corporate DNS.  This registration process can often take few days.  Why give users the power to boot VM only to have them submit an IT support ticket for DNS entry?  Delegating the responsibility for maintaining DNS records to the application owners, entirely based on self-service(DNSaaS), reduces the load on IT teams and gives users the power to do what they want.   DNS is so fundamental to any application lifecycle, and it should just happen.

One of the most requested features from the VIO user community has been self-service for DNS records, and we are proud to deliver OpenStack Designate as part of VIO 5.0.  OpenStack Designate is the OpenStack equivalent of AWS route 53.  There are three ways to consume Designate in VIO 5.0:

Designate Architecture

Architecturally Designate consists of the following components:

  • API service – It is the consumption layer of Designate.  API service is also responsible for validation of API input.
  • Sink – Sink is a notification event listener.   It also generates simple DNS forward lookup A record based on Nova and Neutron notification events.
  • Central Process – Business logic handler.  Central Process is responsible for the user and permission validation.  It also manages access to the Designate database and request dispatch.
  • Pool Manager – Manages the states of the DNS servers. The Pool manager divides DNS servers into ‘Pools’ (PowerDNS, BIND9, etc.) so that zones within Designate can split across different sets of backend servers. The Pool Manager is also responsible for making sure that backend DNS servers are in sync with the Designate database.
  • Designate-zone-manager – A zone shard is a collection of zones allocated based on the first three characters of zone UUID.  The Zone Manager handles all tasks relating to the zone shard.
  • Backend – Software plugins for common DNS servers ((PowerDNS, BIND9, etc.).  Pool Manager will load corresponding plugins based on type of backends.
  • MiniDNS – Serves information from the database to DNS servers via notify and zone transfer.  Also, most importantly, do not expose MiniDNS to end user consumption.

Component Mapping in VIO

Below table highlights mapping of Designate services to VIO control VM(s):

Designate Consumption

VIO 5.0 supports Bind9, PowerDNS (version 4+) and Infoblox back-ends.  Since DNS is so foundational, there’s no such thing as greenfield for Designate.  Once Designate is enabled, there are few strategies to insert Designate into your private cloud.  Graham Hayes (OpenStack PTL) and a few others gave an excellent talk on this topic.  You can find their talk here:


General recommendations are to start small and expand.  One common multi-phase approach is:

  • Phase I – Delegate – Pick a subzone and delegate it to Designate. In the delegation phase, type of backend can be different from existing the production platform.
  • Phase II – Integrate – Deploy a second pool that mirrors the production DNS, and migrate a subset of users/projects.
  • Phase III – Converge – Migrate production zones into Designated owned DNS servers.

Configure Designate

To get started with Phase I is super simple.  At a high-level, follow below steps:

1). login vSphere UI, select Home > VMware Integrated OpenStack > Manage > Setting > Configure Designate 

Note: Backend DNS server must be accessible from VIO control plane.

2).  Configure your DNS server.  VIO QA team had certified BIND / PowerDNS / Infoblox

3). Consume – VIO currently does not support provider network based DNS registration, only floating IP.  A recordset is created during floating association of a VM and deleted after a disassociation.  Customer running BGPaaS / no-nat can leverage static records to insert entries into DNS:

openstack recordset create –records <IP> –type A <domain>

I have created a video recording to demonstrate basic consumption of Designate.


There is not a one size fits all solution to Phase II and III.  Each organization may adopt different implementation strategies based on operational processes and application availability unique to their organization.  Some organizations may never implement beyond phase I.  You are not alone.  We recommend you to consult with VMware PSO team to work out the most optimal implementation based on your unique requirements.  Also, we welcome your input.  Feel free to share your experience on our VIO community page, or leave a note at the end of this blog with your thoughts.