Central Register

DNS is normally one of the first services set up for new infrastructures in the data center; otherwise, it is hardly possible to use the other computers. Many people often only realize how crucial DNS is when it stops working, such as when a website cannot be accessed because the responsible DNS server has crashed. In short: DNS is a fundamental prerequisite for virtually all other services an admin sets up.

The topic of DNS has several dimensions: On the one hand, computers must be able to resolve hostnames to communicate with other computers within and outside the setup. On the other hand, the management of your own DNS entries is done in the appropriate DNS servers: A website that can only be accessed via IP address is rarely desirable; a web address of the expected structure is preferred (e.g., http://www.example.com). To that end, a corresponding A record (or AAAA quad-A record for IPv6) must be stored for a domain, and a corresponding PTR record (which refers to the A record) must be created in the DNS file for the respective address space.

DNS management for VMs in clouds must be deeply integrated into the cloud itself. The software used must create suitable DNS entries for A/AAAA and PTR records when creating virtual instances, as can be well demonstrated by using the concrete example of OpenStack. The OpenStack component that takes care of the management of DNS entries is called Designate. In this article, I explain what the Designate architecture looks like and at which points Designate becomes involved in setups to attain functioning DNS entries for virtual cloud instances. The goal is DNS as a Service (DNSaaS).

Conventional Is Simple

Classic setups planned from the beginning make DNS easy to address. In such setups it is possible to incorporate both the infrastructure required for DNS and the specific entries for individual hosts and IPs; therefore, it is obvious which servers are parts of the setup and via which address one must access them.

Another factor is that typical setups do not generally change during their service lives. A computer or two might be added, but that can be sorted out easily with a few new DNS entries. The DNS configuration doesn't pose a problem for virtualized setups either, because the only difference is usually that services run in VMs and not on real machines.

Everything Is Different in the Cloud

Virtual environments in clouds differ from their conventional counterparts in two ways. Because clouds increasingly focus on the topic of automation, a cloud setup can usually be rolled out automatically using the orchestration components of the cloud being used. You can specify in a template file that a certain number of application servers, databases, load balancers, or monitoring servers are needed, and the cloud sets up the environment accordingly.

However, clouds also increasingly focus on the on-demand factor; therefore, when installing the setup, you don't have to have already thought about how many servers the setup ultimately needs, because you can enhance any kind of service easily at a later date. The other way around isn't a problem either: The current setup can be reduced if fewer virtual instance are required for the individual server types in times of low load.

Two Worlds

Quickly it becomes self-evident: Classic, rigid DNS management and clouds do not go together. Anyone who starts a virtual machine in a typical cloud will initially receive a configuration without DNS entries, which means there aren't any A records for a specific domain or PTR records for the respective IP addresses. The problem with the A records could still be solved somehow; after all, you could enter A records for the public IP addresses in the DNS configuration of a domain after starting the virtual setup, but that's a lengthy process, and if the whole virtual environment can be conjured up out of nothing in just a few minutes, it doesn't make sense then to spend a load of time creating the DNS entries for the setup.

The principle doesn't work at all for the PTR records for domains, because public clouds assign public IPs dynamically from a predefined pool and authority over the domains lies with the provider. However, the provider is hardly going to allow its customers direct access to its DNS server. At worst in such cases, the customer is forced to create a support ticket with the desired DNS entries; yet, this doesn't have to do with automation or dynamic use – that's why this option drops out.

Although it might be of secondary importance for HTTP and HTTPS that a PTR record is missing, anyone wanting to send email from their systems will quickly stumble: Many email servers do not even accept email if the sending server does not have a PTR record, which is almost always a sure sign of spam.

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.

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.

The Janitor

The Zone Manager must not go unmentioned: This is basically Designate's built-in cron daemon, which performs various janitorial tasks for the DNS service on a regular basis. For example, the zone service periodically reports to Ceilometer that certain zones still exist in Designate. As a reminder: Ceilometer collects metrics in OpenStack and uses it to form the basis for the allocation of services.

Additionally, Designate Zone Manager makes sure that AXFR requests regularly start for domains for which the user specified in Designate that not Designate, but an external server, is the primary DNS service for that domain.

Overall it is clear: The Designate design has moved forward and is now recommended for use in production environments. How does it actually feel working with Designate in everyday life? What exactly does a setup based on Designate look like? The following example is taken from an actual installation and shows how Designate can be useful in OpenStack DNS.

The Servers

The basis for the setup is an OpenStack installation consisting of multiple computing nodes and a total of five controller nodes. While the OpenStack VMs are running on the computing nodes, the controllers accommodate the infrastructure components of the OpenStack cloud (i.e., the services that make up OpenStack).

Not all OpenStack services run on all controllers: Two of the five nodes are reserved for the name servers, which are later available for external requests, and the Designate components are located on the three nodes that are left.

The Designate configuration requires a lot of work compared with other OpenStack services. The configuration file (/etc/designate/designate.conf) becomes cluttered very quickly because all Designate components need to share this file; therefore, the configuration is here for all the previously described services, including the specification of which database Designate needs to use for its metadata, as well as the addresses for the RabbitMQ servers that Designate Sink engages with.

The configuration for the back ends belonging to the Pool Manager is also in designate.conf, because a Designate Pool Manager needs to communicate with DNS servers. The handlers also join: These are entries in designate.conf that reveal to Designate which domains it needs to use for new VMs, because it's the only way a new VM will definitely get at least one DNS entry and its IP.

Standard Entries for New VMs

This topic justifies a small digression. When using Designate, cloud providers usually have a key interest: One DNS entry must be made for each virtual machine, regardless of whether the user specifies it or not. If, for example, the user assigns a public floating IP to a VM but does not define a DNS entry for it, the provider defaults become effective, and entries for that VM are automatically created in the provider's default domain.

The term "domain" refers to Designate internals: Each zone that Designate manages is called the "service as a domain." This also includes the reverse zones for PTR records for IP addresses. Designate lets the user choose between the provider zone and user-specific domains that the user has previously created.

User's Cooperation

The user's cooperation is required as soon as the provider provides the Designate infrastructure for the cloud as described. This much is clear: For Designate to work for a domain, the domain needs to be configured with the responsible registry so that its NS records actually point to the Designate name servers. Designate therefore assumes control over the domain in this scenario. Anyone who wants to avoid this can, of course, also work using sub-delegations: DNS for the subdomain cloud.example.com could be delegated to Designate while the normal name servers take care of the rest of the domain, for example.

The setup of domains by users with the Designate command-line client provided is simple. Using

designate domain-create --name example. com. --email email@example.com

the user can create a domain (Figure 2). The tool output then displays an ID, which is important. The user needs this domain ID to create DNS entries for VMs:

designate record-create 5849251B-832E-4521-94ED-92EB3D191DC4 --name www.example.com. --type A --data 192.0.2.1

This example shows that the domain name http://www.example.com receives an A record for the address 192.168.2.1. To set the PTR record for a cloud floating IP, an ID is required – specifically, that of the floating IP. This ID is displayed on either the dashboard or the command line. The command is

openstack ptr record set <ID> <PTR record>

where <ID> and <PTR record> must be replaced with the appropriate values.

If necessary, the user can adjust the network to automate the process. When setting up the domain, the parameter for neutron can be used to define the DNS domain to which the network is to be connected.

Discover the Possibilities

Designate's scope of functions goes far beyond creating DNS and PTR records. One example is controlling zone transfers: Anyone who wants to execute an AXFR transfer for a specific domain can do so for the respective zone with:

designate zone axfr

The blacklist zones are also interesting. Using regular expressions, you can define strings that must not appear in domain names.

Anyone who wants to prevent their own cloud websites from having obscene words in the DNS name can enter them in the Designate blacklist. An attempt to create a domain that matches a pattern on the blacklist will fail with an HTTP 400 error, and the corresponding error message will appear. Only admins can create or manage blacklist domains.

A GUI for Designate

In this article, I have shown how to create entries both for host names and IP addresses from the command line using the Designate API. What hasn't been mentioned thus far is the plugin that Designate needs to integrate into the OpenStack dashboard, Horizon. Unfortunately, integrating Designate into the central OpenStack GUI is not a notable tale: The first work began in 2014, and an abandoned merge request in the OpenStack project review system [3] indicates that for more than two years Designate should have been familiar with Horizon.

However, the merge request was blocked because of various errors, and the original author probably hasn't found the time to start on it again. The good news is that work is continuing on the Designate dashboard, although it currently only exists as an out-of-tree development on GitHub [4].

The installation instructions that can be found there mention installing the plugin with the setup.py script. That is a level of tinkering that nobody wants to take responsibility for in production environments. However, anyone using Ubuntu has little choice: Canonical only packages those OpenStack items that are officially a part of OpenStack.

Annoyed admins have little choice but to build the package themselves. Nevertheless, the developers should see that the Designate plugin soon becomes part of Horizon to eliminate the need for this kind of tinkering (Figure 3).

Designate and Heat

OpenStack's orchestration service Heat is something of a front between the OpenStack services and the user: It accepts a template from the user, evaluates it, and then creates the described services with the relevant OpenStack components. In this context, DNS entries for VMs or IP addresses are ultimately only resources that Heat can manage.

As early as mid-2015, the Designate developers expanded Heat with a range of Designate functions that can be used to create or delete domains automatically. The assignment of DNS entries to IPs or hosts is also possible with Heat instructions. Unlike the dashboard integration, Heat integration is comprehensive.

Conclusions

DNS as a Service (DNSaaS) is rightly one of the first features customers want in a cloud: Manually managing DNS entries for cloud VMs is only possible for a while, and then it proves tedious. Because clouds are increasingly focusing on automation, this process must be handled by DNS services.

Designate fills the DNSaaS gap well for OpenStack: After an eventful history, the service can now be used productively and is essentially what the developers promised. A/AAAA records can be creating with Designate, and PTR records present no problems either.

If the developers can now manage to integrate it into the dashboard officially, the service will belong to the group of successful OpenStack components, although dashboard integration probably won't matter to many users: Anyone who uses Heat for OpenStack orchestration will have little interest in GUIs.

If you want to use Designate, an administrator with DNS experience should perform this work, because an appropriate design for your cloud's particular requirements is not a foregone conclusion.