Chapter 3. Installing and configuring the DNS service
You install and configure the DNS service (designate) by including the designate environment file when you deploy or redeploy the Red Hat OpenStack Platform (RHOSP). The toolset for deploying RHOSP, director, uses Orchestration service (heat) environment templates and environment files as a set of plans for how to install and configure the DNS service and the rest of your RHOSP deployment.
When deploying the DNS service, director automatically performs such actions as enabling the DNS service for active-active High Availability mode and activating automation for port and floating IP addresses. Director also configures the Networking service (neutron) to point to the Unbound resolvers included with DNS service.
You can explicitly disable the configuration of the Unbound resolvers by setting UnboundForwardResolvers
in a custom heat environment file.
You can also integrate the DNS service with a pre-existing DNS infrastructure by providing director with the necessary DNS server information.
In RHOSP 17.0, integrating the DNS service with a pre-existing DNS infrastructure is a technology preview feature.
The topics included in this section are:
3.1. Deploying the DNS service Copy linkLink copied to clipboard!
You use Red Hat OpenStack Platform (RHOSP) director to deploy the DNS service (designate). Director uses Orchestration service (heat) templates and environment files that are a set of plans for your RHOSP deployment. The undercloud imports these plans and follows their instructions to install and configure the DNS service and your RHOSP deployment.
Prerequisites
-
You must be the
stack
user with access to the RHOSP undercloud.
Procedure
- If you are integrating the DNS server with a pre-existing DNS infrastructure, go to the topic, Section 3.2, “Deploying the DNS service with pre-existing BIND 9 servers”.
- Log in to the undercloud host as the stack user.
Source the undercloud credentials file:
source ~/stackrc
$ source ~/stackrc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the deployment command and include the core heat templates, other environment files, and the
enable-designate.yaml
environment file.Example
openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml
$ openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteDirector updates the various DNS service components to the latest designate image during a stack update or upgrade.
Verification
Confirm that the DNS service has been installed and has an endpoint defined.
openstack endpoint list -c "Service Name" -c Enabled -c URL
$ openstack endpoint list -c "Service Name" -c Enabled -c URL
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Sample output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. Deploying the DNS service with pre-existing BIND 9 servers Copy linkLink copied to clipboard!
You use Red Hat OpenStack Platform (RHOSP) director to install and configure the DNS service (designate) and integrate it with a pre-existing BIND 9 DNS infrastructure. Director uses Orchestration service (heat) templates and environment files that are a set of plans for your RHOSP deployment. You add the specific information about your DNS servers to a heat environment file. The undercloud imports these plans and follows their instructions to install and configure RHOSP and the DNS service and integrate it with your DNS infrastructure.
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.
Prerequisites
- You have a pre-existing DNS infrastructure that relies on BIND 9 servers.
- Ensure that your BIND 9 servers meet the configuration that is described in Configuring existing BIND servers for the DNS service.
-
You must be the
stack
user with access to the RHOSP undercloud.
Procedure
- If you are not integrating the DNS server with a pre-existing DNS infrastructure, go to the topic, Section 3.1, “Deploying the DNS service”.
- Log in to the undercloud host as the stack user.
Source the undercloud credentials file:
source ~/stackrc
$ source ~/stackrc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a custom YAML environment file.
Example
vi /home/stack/templates/my-designate-environment.yaml
$ vi /home/stack/templates/my-designate-environment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Your environment file must contain the keywords
parameter_defaults
andDesignateExternalBindServers
. Add the IP address and the Remote Name Daemon Control (RNDC) key for each of your BIND 9 DNS servers on new lines beneathDesignateExternalBindServers
.Example
In this example, there are two pre-existing BIND 9 servers,
203.0.113.3
and203.0.113.4
, with an RNDC key, respectively:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the deployment command and include the core heat templates, other environment files, the
enable-designate.yaml
environment file, and this new custom environment file.ImportantThe order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence.
Example
openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml
$ openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteDirector updates the various DNS service components to the latest designate image during a stack update or upgrade.
3.3. Changing DNS service default settings Copy linkLink copied to clipboard!
You make configuration changes to the Red Hat OpenStack Platform (RHOSP) DNS service (designate) by modifying a YAML-formatted environment file and redeploying your RHOSP overcloud. The RHOSP director is a toolset that uses Orchestration service (heat) templates and environment files as a plan to configure the DNS service.
Prerequisites
-
You must be the
stack
user with access to the RHOSP undercloud. Decide which RHOSP DNS service parameters that you want to modify.
Here are a few examples:
DesignateRpcResponseTimeout
The RPC response timeout, in seconds, for the DNS service. The default is 60 seconds.
DesignateWorkers
The number of workers for Designate services. The default is zero (0), which means that the deployment script uses the RHOSP director value for operating system workers.
For more information, see Determining environment scale in the Director Installation and Usage guide.
DesignateMdnsProxyBasePort
The base port for the MiniDNS proxy endpoints on the external or public access network. The default port is 16000.
Procedure
-
Log in to the undercloud host as the
stack
user. Source the undercloud credentials file:
source ~/stackrc
$ source ~/stackrc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a custom YAML environment file.
Example
vi /home/stack/templates/my-designate-environment.yaml
$ vi /home/stack/templates/my-designate-environment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Your environment file must contain the keywords
parameter_defaults
. Put your parameter value pairs after theparameter_defaults
keyword.Example
In this example, the RPC response timeout is set to 120 seconds:
parameter_defaults: DesignateRpcResponseTimeout: '120'
parameter_defaults: DesignateRpcResponseTimeout: '120'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the deployment command and include the core heat templates, other environment files, the
enable-designate.yaml
environment file, and this new custom environment file.ImportantThe order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence.
Example
openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml \ -e /home/stack/templates/my-designate-environment.yaml
$ openstack overcloud deploy --templates \ -e <other_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/\ enable-designate.yaml \ -e /home/stack/templates/my-designate-environment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow