Chapter 2. Planning a DNS service deployment
This section discusses topics that are important to consider when planning your DNS service (designate) deployment with Red Hat OpenStack Platform.
The topics included in this section are:
2.1. DNS server feature support matrix
The following table lists features in the DNS service (designate) that Red Hat OpenStack Platform (RHOSP) 17 supports.
| Feature | Supported in RHOSP 17? |
| x86_64 hardware architecture | Yes |
| All other hardware architectures | No |
| BIND 9 back end | Yes |
| All other back ends | No |
| Denylists (blacklists) | Yes |
| Designate v1 API | No |
| Designate v2 API | Yes |
| Designate admin API | No |
| Designate Central service | Yes |
| Designate Producer service | Yes |
| Designate Worker service | Yes |
| Designate miniDNS service | Yes |
| Designate Agent service | No |
| Designate Zone Manager service | No |
| Designate Pool Manager service | No |
| Designate OpenStack client plug-in (CLI) | Yes |
| Designate client (CLI) | No |
| OpenStack Python SDK (designate) | Yes |
| Designate client (SDK) | No |
| Designate horizon dashboard | Yes |
| Designate tempest plug-in | Yes |
| Designate database MariaDB/Galera | Yes |
| All other databases | No |
| Distributed lock manager (Redis) | Yes |
| All other distributed lock manager options | No |
| Designate sinks | No |
| Designate notifications | Yes |
| High availability deployments | Yes |
| IPv4 | Yes |
| IPv6 | Yes |
| Monasca integration | No |
| Default pool scheduler | Yes |
| All other pool schedulers | No |
| A single pool | Yes |
| Multiple pools | No |
| Quotas | Yes |
| Role-based access control (RBAC) | Yes |
| Record type A | Yes |
| Record type AAAA | Yes |
| Record type CNAME | Yes |
| Record type MX | Yes |
| Record type SRV | Yes |
| Record type TXT | Yes |
| Record type SPF | Yes |
| Record type NS | Yes |
| Record type PTR | Yes |
| Record type SSHFP | Yes |
| Record type SOA | Yes |
| Record type NAPTR | Yes |
| Record type CAA | Yes |
| All other record types | No |
| Top-level domains (TLDs) | Yes |
| TSIG keys | Yes |
| Unbound recursive resolver | Yes |
| All other recursive resolvers | No |
| Primary zones | Yes |
| Secondary zones | No |
| Zone import and export | Yes |
| Zone abandon | No |
| Zone ownership transfer | Yes |
2.2. DNS service software requirements
The Red Hat OpenStack Platform (RHOSP) DNS service (designate) depends on the following RHOSP core components:
- Identity service (keystone)
- RabbitMQ
- MariaDB
- Redis
The RHOSP installation and configuration toolset, director, configures these components for the DNS service automatically.
If you are using VLANs or overlay networks that you want the DNS service to automatically create DNS records for, then set aside some network segmentation IDs for these networks. The DNS service does not create DNS records for networks whose segmentation IDs fall within the ranges specified in the Networking service (neutron) ml2_conf.ini file.
Additional resources
2.3. Configuring existing BIND servers for the DNS service
If you are integrating the Red Hat OpenStack Platform (RHOSP) DNS service (designate) with an existing BIND infrastructure, there are several actions that you must take to ensure that BIND 9 is configured correctly.
This feature 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.
If you do not have an existing BIND infrastructure, RHOSP director automatically configures BIND for you.
Prerequisites
- You must be a user that has adequate permissions to make changes to your BIND 9 server.
-
Ensure that BIND can access the files,
/etc/rndc.confand/etc/rndc.key. -
Ensure that BIND is able to receive
rndcutility messages from the RHOSP DNS service (designate).
Procedure
- Log on to your BIND 9 server.
Ensure that
/etc/rndc.keyis configured properly.The
rndc-keymust have a Hash-based Message Authentication Code (HMAC), SHA-256 algorithm and a Base64-encoded secret:key "rndc-key" { algorithm hmac-sha256; secret "<base64-encoded string>"; };If it is not already, enable BIND to create and delete zones remotely using the
rndcutility.In
/etc/named.conf, underoptions {, confirm that the following line is present. If it is not there, create a new line and add it:allow-new-zones yes;
If it is not already, configure BIND to send minimal responses.
Also in
/etc/named.conf, underoptions {, confirm that the following line is present. If it is not there, create a new line and add it:minimal-responses yes;
By default, BIND 9 includes authority out-of-zone records and additional sections in the responses that it sends to clients. Setting
minimal-responsestoyesprevents the out-of-zone additionals from being processed, and removes susceptibility to a DNS cache poisoning attack.
Additional resources
2.4. Recommended DNS service topology
The recommended topology consists of deploying the DNS service on the Red Hat OpenStack Platform (RHOSP) Controller host. If your RHOSP deployment is highly available, then you have a minimum of three RHOSP Controllers, each containing the DNS service.
Figure 2.1. Recommended DNS service topology
In Figure 2.1, the DNS service components are running in their respective containers. The containers that are darker in color are the resources that the DNS service shares with the other RHOSP services.
The dotted lined containers represent an optional placement for BIND and Unbound. If your site has a heavy data traffic footprint, you might want to use a dedicated host to contain BIND and Unbound, respectively.
2.5. About DNS service high availability
The Red Hat OpenStack Platform (RHOSP) DNS service (designate) combines load balancing of data traffic and fault tolerance in a high availability mode known as active-active High Availability mode. In active-active mode, the DNS service simultaneously runs its component services on three or more nodes. If one of the nodes fail, the remaining nodes continue to run and to avoid interruptions and declines in performance. The DNS service attempts to load balance work across all of the service instances.
The DNS service components are categorized as services that are deployed with the RHOSP Controller role. This means that the RHOSP installation and configuration toolset, director, automatically deploys the DNS service on all Controller hosts. Therefore, if you have three or more Controllers deployed on three or more different hosts, the DNS service is highly available.
Additional resources
