Chapter 1. Overview of DNSaaS
Red Hat OpenStack Platform 11 includes a Technology Preview of DNS-as-a-Service (DNSaaS), also known as Designate. DNSaaS includes a REST API for domain and record management, is multi-tenanted, and integrates with OpenStack Identity Service (keystone) for authentication. DNSaaS includes a framework for integration with Compute (nova) and OpenStack Networking (neutron) notifications, allowing auto-generated DNS records. In addition, DNSaaS includes integration support for Bind9.
DNS-as-a-Service (DNSaaS), also known as Designate, is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.
1.1. Topics covered in this guide
- Manual DNSaaS installation steps, as DNSaaS is not currently included in Director deployment.
- Managing and configuring DNSaaS from the command line interface.
- Integration with Bind9, including auto-creation of instance records.
1.2. DNSaaS prerequisites
- A fully functioning OpenStack Networking-based, non-HA OpenStack environment.
- An OpenStack Image Service (glance) image loaded, for testing auto-creation.
1.3. DNSaaS services
A deployment of DNSaaS includes the following components:
Provides an OpenStack-native REST API.
Handles requests and coordinates storage in the mysql database.
A small MiniDNS server used only to communicate with other DNS servers over standard DNS protocol.
Manages the states of the DNS servers that DNSaaS manages. Ensures the backend DNS servers are in sync with DNSaaS.
An optional service that is used to listen to nova and neutron notification events to trigger automatic record creation/deletion.
Used for DNS servers that cannot accept zone transfers (AXFR). Not needed for BIND backends.
The zone-manager service is expected to be added in the next major release. It will run periodic tasks on zones to provide a mechanism for identifying lost events.
1.4. DNSaaS integration with Compute and OpenStack Networking
DNSaaS record management begins when the
designate-sink service sends a message to
designate-central, which then triggers the workflow described below:
designate-sink receives an instance boot/delete event from Compute, or a floating IP add/remove event from OpenStack Networking. These events are sent using the OpenStack message bus.
designate-sink constructs the FQDN of the host from the VM name and the configured domain ID (see below).
designate-central to add/delete the record with the given name and IP address.
designate-central adds/deletes the record in the DNSaaS database (shared between
designate-pool-manager to send a
DNS NOTIFY to the backend DNS server (BIND9) for this domain.
6. The backend DNS servers receive the
DNS NOTIFY and send an
AXFR (zone transfer) request to
designate-mdns reads the changes from the database and sends them to the backend DNS servers in the