Central Register

Eventful History

Designate is still not very old, but nevertheless, it already has an eventful history for OpenStack standards. The service appeared several years ago under the name of Moniker, but the community's interest in the solution soon fell away. No wonder: The developers were focused on far more important issues with a view to stability and reliability in OpenStack. The fact that Moniker never made it as a core component was further cause for interest in this solution to slow down.

However, as the stability of OpenStack increased, other issues came back to the fore again, including Moniker, which its developers quickly renamed Designate. The continuous feature development then began within the Big Tent initiative. Designate now follows the release cycle of OpenStack itself; the Designate version released at the same time as OpenStack Newton is version 3.0.0.

Now it is indeed possible to work meaningfully with Designate: The component communicates with various types of DNS servers in the back end, as desired, including as top dog BIND and PowerDNS. It is also possible to manage domains and individual DNS entries automatically or manually via an API. How exactly does it work?

Modular Setup

Like practically any OpenStack component, Designate is based on a modular design (Figure 1). The most important component is Designate Central, which manages Designate's metadata that includes the database of all existing DNS entries and those to be created by Designate. The Designate API is directly connected to Designate Central: Like every OpenStack components, the API is also based on the REST principle and accepts external commands entered by the user via the command line or the OpenStack dashboard.

Figure 1: In OpenStack, Designate comprises several components that conveniently take care of DNS management for the user [1].

Unlike other OpenStack components, Designate has another option for making configuration changes: The solution part called Designate Sink directly docks to the cloud's message queue. Every OpenStack environment uses this to exchange commands between the individual OpenStack components.

For example, when Nova (i.e., the service responsible for managing VMs) creates a new virtual machine, the service sends a message via the message queue that one of the other Nova compute instances then reads and processes. RabbitMQ messaging is usually used in OpenStack.

Designate Sink, in particular, picks off the notifications that Nova sends as a confirmation when creating and deleting VMs. The service uses this as a trigger to create DNS entries automatically after starting a VM. The principle is elegant: No further work is required in Nova to allow Nova and Designate to communicate, because Nova creates the notifications anyway and Designate can read them from RabbitMQ.

Communication with Name Servers

Speaking of services that communicate with each other, Designate has to communicate with DNS servers for several tasks at the same time in the back end. The responsibility for this lies with two components: Designate Pool Manager and Designate MiniDNS (MDNS). The only way to ensure the interaction of services is to have several notional DNS servers available for customer requests.

Designate Pool Manager is responsible for the overview of the DNS server that a Designate setup has. The DNS servers can be sorted into pools (i.e., organized into groups) using the Pool Manager. On the pool level, users can then define per domain which name server is responsible for precisely that domain, which means it's possible to distribute incoming requests for domains to many back ends.

Moreover, the pool manager is also responsible for synchronizing the configuration from the data in the database with the configuration of all the DNS servers. To this end, the pool manager supports the so-called back ends – a type of driver that allows communication between the pool manager and the name server. Designate supports a variety of back ends out of the box: BIND9, Microsoft DNS, PowerDNS, Knot DNS 2, and djbdns are just a few of the available examples.

However, Designate also has its own name server in the form of Designate MDNS that sends DNS Notify requests and answers AXFR requests from the real name servers in the setup. The construct seems redundant at first glance: If the DNS server setup can be processed directly via Designate Pool Manager, why do they receive via AXFR instead and DNS zone transfer from Designate MDNS?

The answer to this question is perpetuated in the blueprint for Designate MDNS [2]: A great deal of intelligence would be required in the back ends if they were responsible for the target DNS server being up to date.

Updating DNS entries on multiple DNS servers at the same time is certainly not a trivial task, but it's one that has already been solved. Update messages and AXFR requests are, after all, fixed components of the DNS standard, so it would have amounted to reinventing the wheel if people had wanted to implement the DNS update via Designate Pool Manager and its back ends instead of using existing mechanisms. OpenStack project developers consciously decided against doing so.