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: Section 2.1, "DNS server feature support matrix" Section 2.2, "DNS service software requirements" Section 2.3, "Configuring existing BIND servers for the DNS service" Section 2.4, "Recommended DNS service topology" Section 2.5, "About DNS service high availability" 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. Table 2.1. DNS service (designate) feature support matrix 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 Section 2.4, "Recommended DNS service topology" Setting up a project for DNS integration 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. Important 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 . Note 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.conf and /etc/rndc.key . Ensure that BIND is able to receive rndc utility messages from the RHOSP DNS service (designate). Procedure Log on to your BIND 9 server. Ensure that /etc/rndc.key is configured properly. The rndc-key must have a Hash-based Message Authentication Code (HMAC), SHA-256 algorithm and a Base64-encoded secret: If it is not already, enable BIND to create and delete zones remotely using the rndc utility. In /etc/named.conf , under options { , confirm that the following line is present. If it is not there, create a new line and add it: If it is not already, configure BIND to send minimal responses. Also in /etc/named.conf , under options { , confirm that the following line is present. If it is not there, create a new line and add it: By default, BIND 9 includes authority out-of-zone records and additional sections in the responses that it sends to clients. Setting minimal-responses to yes prevents the out-of-zone additionals from being processed, and removes susceptibility to a DNS cache poisoning attack. Additional resources Deploying the DNS service with pre-existing BIND 9 servers 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 DNS service components

Commands:
key "rndc-key" { algorithm hmac-sha256; secret "<base64-encoded string>"; };
allow-new-zones yes;
minimal-responses yes;