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.