Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 1. Overview of DNSaaS
Red Hat OpenStack Platform 8 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:
| designate-api | Provides an OpenStack-native REST API. |
| designate-central | Handles requests and coordinates storage in the mysql database. |
| designate-mdns | A small MiniDNS server used only to communicate with other DNS servers over standard DNS protocol. |
| designate-pool-manager | Manages the states of the DNS servers that DNSaaS manages. Ensures the backend DNS servers are in sync with DNSaaS. |
| designate-sink | An optional service that is used to listen to nova and neutron notification events to trigger automatic record creation/deletion. |
| designate-agent | 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:
1. 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.
2. designate-sink constructs the FQDN of the host from the VM name and the configured domain ID (see below).
3. designate-sink tells designate-central to add/delete the record with the given name and IP address.
4. designate-central adds/deletes the record in the DNSaaS database (shared between designate-central and designate-mdns).
5. designate-central tells 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.
7. designate-mdns reads the changes from the database and sends them to the backend DNS servers in the AXFR response.
