Introduction to Designate¶

What is DNS?¶

The Domain Name System (DNS) is a system for naming resources connected to a network, and works by storing various types of record, such as an IP address associated with a domain name. In practice, this is implemented by authoritative name servers which contain these records and resolvers which query name servers for records. Names are divided up into a hierarchy of zones, allowing different name servers to be responsible for separate groups of zones by delegating responsibility using records.

The root zone, which is simply “.”, is comprised entirely of records delegating various top level domains (TLDs) to other nameservers. The TLD name servers will contain records for domains within their TLD, such as the .com nameserver having an example.com record, as well as records that delegate zones to other nameservers, for example openstack.org might have their own nameserver so that they can then create cloud.openstack.org.

Resolvers are often formed in two parts: a stub resolver which is often merely a library on a user’s computer, and a recursive resolver that will perform queries against nameservers before returning the result to the user. When searching for a domain, the resolver will start at the end of the domain and work its way back to the beginning.

For example in the diagram below, when searching for cloud.openstack.org, it will start with the root nameserver “.”, which will reply with the location of the “.org” nameserver. The resolver can then contact the “.org” nameserver to get the “openstack.org” nameserver and from there finally get the “cloud.openstack.org” record and return it to the user.

In order to make this more efficient, the results are cached on the resolver, so after the first user has requested “cloud.openstack.org”, the resolver can return the cached result for subsequent requests.

Further reading on DNS and how it works is available here:

• https://en.wikipedia.org/wiki/Domain_Name_System

While the system itself is defined via RFCs such as this:

• https://tools.ietf.org/html/rfc1034

Introducing Designate¶

Designate is an OpenStack service that allows users and operators to manage DNS records, names and zones via a REST API and can configure existing DNS name servers to contain those records. Designate can also be configured by an operator to integrate with both the OpenStack Network Service (Neutron) and the Compute Service (Nova) so that records are automatically created when floating IPs and compute instances are created respectively, and uses the OpenStack Identity Service (Keystone) for user management. Since there are a multitude of software implementations of the DNS name server, Designate has a pluggable backend that can be configured to manage many of them, most notably BIND9 and PowerDNS.

Designate Architecture¶

Designate is comprised of several different services: the API, Producer, Central, Worker and Mini DNS. It uses an oslo.db compatible database to store state and data, and an oslo.messaging compatible message queue to facilitate communication between services. Multiple copies of all Designate services can be run in tandem to facilitate high availability deployments, with the API process often sitting behind load balancers.

Neutron and other users of Designate only need to be able to access the API server, while administrators should ensure the DNS Nameservers to be configured are able to access Mini DNS from which to request updates.

Below we can see a common deployment scenario:

A user has created two zones in Designate: zone1.cloud.openstack.org and zone2.cloud.openstack.org. This will result in two new zones being created on the Designate-managed nameserver with SOA records.

The user then created two networks in Neutron: one private network with zone1.cloud.openstack.org assigned to it, and one public network with zone2.cloud.openstack.org.

They have then created virtual machine vm1 in Nova, connected to the private network in Neutron and attached to a floating IP, and the virtual machine vm2 attached directly to the public network. Each of these actions triggers a chain of events that will cause Neutron to request Designate create records on behalf of the user, with the end result being that records are created in the authoritative nameserver mapping the vm names to domains along with PTR records to allow reverse lookups.

More information about configuring Neutron to work with Designate can be found in the Neutron documentation at https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html

Using Designate¶

Designate provides a REST API and that is commonly used by one of three methods. The most common is to use the OpenStack client, a python command-line tool with commands for interacting with OpenStack services. The documentation for the OpenStack client is available at https://docs.openstack.org/python-openstackclient/. The designate plugin https://docs.openstack.org/python-designateclient/latest/ for the OpenStack client needs to be installed as well:

pip install python-openstackclient
pip install python-designateclient

Another popular way to use Designate is via the OpenStack Dashboard, Horizon. Administrators will need to add the Designate Horizon plugin https://opendev.org/openstack/designate-dashboard to the dashboard in order to enable Designate features.

Finally, for python developers the aforementioned Designate plugin for the OpenStack client which can be used as a python library. Other languages may have bindings available from one of the third party SDKs https://wiki.openstack.org/wiki/SDKs for OpenStack.