Configuring DNS as a service

Procedure

1. Log on to your BIND 9 server.

2. 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:

   key "rndc-key" {
       algorithm hmac-sha256;
       secret "<base64-encoded string>";
   };

3. 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:

   allow-new-zones yes;

4. 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:

   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-responses to yes prevents the out-of-zone additionals from being processed, and removes susceptibility to a DNS cache poisoning attack.

Procedure

1. 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”.
2. Log in to the undercloud host as the stack user.

3. Source the undercloud credentials file:

   $ source ~/stackrc

4. Create a custom environment YAML file that includes a declaration for the DesignateBindNSRecords parameter whose values are the name server records (NS records) for the child zones that reside in the DNS server (designate) pool:

   parameter_defaults:
     DesignateBindNSRecords: ['<NS_record_child-zone-1>', '<NS_record_child-zone-2>', '...']

   Example

   In this example, the DNS pool contains the child zones: ns1.sales.example.org., ns2.sales.example.org., and ns3.sales.example.org. for the parent zone example.org.:

   parameter_defaults:
     DesignateBindNSRecords: ['ns1.sales.example.org.', 'ns2.sales.example.org.', 'ns3.sales.example.org.']

5. Run the deployment command and include the core heat templates, other environment files, the designate.yaml environment file, and the file that contains your pool NS records.

   Example

   $ openstack overcloud deploy --templates \
   -e <other_environment_files> \
   -e /usr/share/openstack-tripleo-heat-templates/environments/\
   services/designate.yaml \
   -e /home/stack/my_pool_ns_records.yaml

   Note

   Director updates the various DNS service components to the latest designate image during a stack update or upgrade.

Procedure

1. 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”.
2. Log in to the undercloud host as the stack user.

3. Source the undercloud credentials file:

   $ source ~/stackrc

4. Create a custom environment YAML file.

   Example

   $ vi /home/stack/templates/my-designate-environment.yaml

5. Your environment file must contain the keywords parameter_defaults and DesignateExternalBindServers. Add the IP address and the Remote Name Daemon Control (RNDC) key for each of your BIND 9 DNS servers on new lines beneath DesignateExternalBindServers.

   Example

   In this example, there are two pre-existing BIND 9 servers, 203.0.113.3 and 203.0.113.4, with an RNDC key, respectively:

   parameter_defaults:
     DesignateExternalBindServers:
       - host: 203.0.113.3
         rndc_key: "FJOdVqZr5gVXbU9kIagY0IJVDq7CV/mDVb/M7mlLMgY="
       - host; 203.0.113.4
         rndc_key: "QAAACCdIV3KXPJh6U71ImVH0+j4uKRpVV49zVU7A8uvm"

6. Add a declaration for the DesignateBindNSRecords parameter whose values are the name server records (NS records) for the child zones that reside in the DNS server (designate) pool:

   parameter_defaults:
   ...
     DesignateBindNSRecords: ['<NS_record_child-zone-1>', '<NS_record_child-zone-2>', '...']

   Example

   In this example, the DNS pool contains the child zones: ns1.sales.example.org., ns2.sales.example.org., and ns3.sales.example.org. for the parent zone example.org.:

   parameter_defaults:
   ...
     DesignateBindNSRecords: ['ns1.sales.example.org.', 'ns2.sales.example.org.', 'ns3.sales.example.org.']

7. Run the deployment command and include the core heat templates, other environment files, the designate.yaml environment file, and this new custom environment file.

   Important

   The 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/\
   services/designate.yaml

   Note

   Director updates the various DNS service components to the latest designate image during a stack update or upgrade.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the undercloud credentials file:

   $ source ~/stackrc

3. Create a custom YAML environment file.

   Example

   $ vi /home/stack/templates/my-designate-environment.yaml

   Your environment file must contain the keywords parameter_defaults. Put your parameter value pairs after the parameter_defaults keyword.

   Example

   In this example, the RPC response timeout is set to 120 seconds:

   parameter_defaults:
     DesignateRpcResponseTimeout: '120'

4. Run the deployment command and include the core heat templates, other environment files, the designate.yaml environment file, and this new custom environment file.

   Important

   The 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/\
   services/designate.yaml \
   -e /home/stack/templates/my-designate-environment.yaml

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create the zone that you want users in a particular project to create DNS entries with.

   Example

   In this example, the cloud administrator creates a zone called example.com. and specifies that users in the project ID, f75ec24a-d361-ab86-54c0-dfe6093245a3, have permission to add record sets to the zone:

   $ openstack zone create --email example@example.com example.com. --sudo-project-id f75ec24a-d361-ab86-54c0-dfe6093245a3

   Note

   The DNS domain must always be a fully qualified domain name (FQDN), meaning it will always end with a period.

3. Create the network that you want users in a particular project to create DNS entries with.

   Example

   In this example, the cloud administrator creates a network, example-network, that uses the earlier created zone, example.com., and a segmentation ID, 2017, that is outside of the range defined in ml2_conf.ini:

   $ openstack network create --dns-domain example.com. \
   --provider-segment 2017 --provider-network-type geneve \
   example-network

4. On the network, create a subnet.

   Example

   In this example, the cloud administrator creates a subnet, example-subnet, on the network, example-network:

   $ openstack subnet create \
     --allocation-pool start=192.0.2.10,end=192.0.2.200 \
     --network example-network \
     --subnet-range 192.0.2.0/24 \
     example-subnet

5. Instruct the cloud users in the project to use the zone and network you have created when they add instances, ports, and floating IPs.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Using the network that your cloud administrator has provided, create an instance.

   Example

   In this example, the cloud user creates an instance named my_vm:

   $ openstack server create --image cirros-0.5.2-x86_64-disk --flavor m1.micro --nic net-id=example-network my_vm

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Using the zone and network that your cloud administrator has provided, create a port.

   Example

   In this example, the cloud user creates a port, my-port, with a DNS name of example-port in the network, example-network:

   $ openstack port create --network example-network \
   --dns-name example-port \
   my-port

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Using the zone and the external network that your cloud administrator has provided, create a floating IP.

   Example

   In this example, the cloud user creates a floating IP with a DNS name, example-fip, in the network, public:

   $ openstack floating ip create --dns-name example-fip \
   --dns-domain example.com. \
   public

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. You create a TLD by running the openstack tld create command.

   Example

   For example, if you want to require that users create zones ending in .org, you can create a single .org TLD:

   $ openstack tld create --name org

   Sample output

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Use the following command to list all of the TLDs in the DNS service database:

   $ openstack tld list

3. Use the openstack tld show <TLD_NAME_or_ID> command to display the properties for a particular TLD.

   Example

   $ openstack tld show org

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. You can modify a TLD in various ways by using the following command options:

   openstack tld set [--name NAME] \
                     [--description DESCRIPTION | --no-description] \
                     [TLD_ID | TLD_NAME]

   Note

   The earlier syntax diagram does not show the various formatting options for the openstack tld set command. For the list of all the command options, see the link in "Additional resources," later.

   In this example, the openstack tld set command renames the org TLD to example.net:

   Example

   $ openstack tld set org --name example.net

   Sample output

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID or the name for the TLD that you want to delete, by running the following command:

   $ openstack tld list

3. Using either the name or the ID from the previous step, enter the following command:

   $ openstack tld delete <TLD_NAME_or_ID>

   There is no output when this command is successful.

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Use the openstack zone blacklist create command to create a denylist.

   In this example, the domain example.com. and all of its subdomains are added to a denylist.

   Example

   $ openstack zone blacklist create --pattern ".*example.com."

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | created_at  | 2021-10-20T16:15:18.000000           |
   | description | None                                 |
   | id          | 7622e241-8c3d-4c03-a692-8747e3cf2658 |
   | pattern     | .*example.com.                       |
   | updated_at  | None                                 |
   +-------------+--------------------------------------+

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Use the following command to list the denylists in the DNS service database:

   $ openstack zone blacklist list

   • With the denylist ID obtained in the previous step, use the openstack zone blacklist show <denylist_ID> command to display properties for a particular denylist.

     Example

     $ openstack zone blacklist show 7622e241-8c3d-4c03-a692-8747e3cf2658

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the denylist that you want to modify, by running the following command:

   $ openstack zone blacklist list

3. You can modify a denylist in various ways by using the following command options:

   $ openstack zone blacklist set \
            [--description DESCRIPTION | --no-description] denylist_ID

   Note

   The earlier syntax diagram does not show the various formatting options for the openstack zone blacklist set command. For the list of all the command options, see the link in "Additional resources," later.

   In this example, the regular expression (regex) is changed to allow the web.example.com domain:

   Example

   $ openstack zone blacklist set 81fbfe02-6bf9-4812-a40e-1522ab6862ca --pattern ".*web.example.com"

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | created_at  | 2022-01-08T09:11:43.000000           |
   | description | None                                 |
   | id          | 81fbfe02-6bf9-4812-a40e-1522ab6862ca |
   | pattern     | .*web.example.com                    |
   | updated_at  | 2022-01-15T14:26:18.000000           |
   +-------------+--------------------------------------+

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the denylist that you want to delete, by running the following command:

   $ openstack zone blacklist list

3. Using the ID from the previous step, enter the following command:

   $ openstack zone blacklist delete <denylist_ID>

   There is no output when this command is successful.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. View the DNS resource quotas set for your project:

   $ openstack dns quota list

   Sample output

   +-------------------+-------+
   | Field             | Value |
   +-------------------+-------+
   | api_export_size   | 1000  |
   | recordset_records | 20    |
   | zone_records      | 500   |
   | zone_recordsets   | 500   |
   | zones             | 10    |
   +-------------------+-------+

3. A RHOSP user with the admin role can query the quotas for other projects:

   1. Obtain the ID for the project whose quotas you want to modify.

      Remember the ID, because you need it for a later step.

      $ openstack project list

   2. Using the project ID, view the DNS resource quotas set for the project.

      Example

      In this example, the DNS quotas for project ID ecd4341280d645e5959d32a4b7659da1 are displayed:

      $ openstack dns quota list --project-id ecd4341280d645e5959d32a4b7659da1

      Sample output

      +-------------------+-------+
      | Field             | Value |
      +-------------------+-------+
      | api_export_size   | 2500  |
      | recordset_records | 25    |
      | zone_records      | 750   |
      | zone_recordsets   | 750   |
      | zones             | 25    |
      +-------------------+-------+

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the project whose quotas you want to modify.

   Remember the ID, because you need it for a later step.

   $ openstack project list

3. Using the project ID, modify a DNS resource quota for a project. For a list of available quotas, see Section 6.4, “DNS service quotas and their default values”.

   Example

   In this example, the zones quota has been modified. The total number of zones that project ID ecd4341280d645e5959d32a4b7659da1 can contain is 30:

   $ openstack dns quota set --project-id ecd4341280d645e5959d32a4b7659da1 --zones 30

   Sample output

   +-------------------+-------+
   | Field             | Value |
   +-------------------+-------+
   | api_export_size   | 1000  |
   | recordset_records | 20    |
   | zone_records      | 500   |
   | zone_recordsets   | 500   |
   | zones             | 30    |
   +-------------------+-------+

Procedure

1. As a cloud administrator, source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the project whose quotas you want to reset.

   Remember the ID, because you need it for a later step.

   $ openstack project list

3. Using the project ID, reset the DNS resource quotas for a project.

   Example

   In this example, the quotas for a project whose ID is ecd4341280d645e5959d32a4b7659da1 are being reset to the default values:

   $ openstack dns quota reset --project-id ecd4341280d645e5959d32a4b7659da1

   There is no output from a successful openstack dns quota reset command.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create a zone by specifying a name for the zone and an email address of the person responsible for the zone.

   Example

   $ openstack zone create --email dnsprimary@example.com example.com.

   When you create a zone, the DNS service automatically creates two record sets: an SOA record and an NS record.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Modify the zone by specifying the name of the zone and the zone attributes that you want to change:

   --email <email_address>

   a valid email address for the person responsible (owner) for the zone.

   --ttl <seconds>

   (Time To Live) the duration, in seconds, that a DNS client—​for example, a resolver, a web browser, an operating system—​can cache a record before checking to see if it has updated.

   --description <string> | --no-description

   a string that describes the purpose of the zone.

   --masters <dns-server> [<dns-server> ...]

   the fully qualified domain name for the DNS server that is the primary instance—​the instance that other DNS servers can sync from to become secondary servers.

   Example

   $ openstack zone set example.com. --ttl 3000

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Delete the zone.

   Example

   $ openstack zone delete example.com.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Export the zone.

   Example

   $ openstack zone export create example.com.

   Sample output

   +------------+--------------------------------------+
   | Field      | Value                                |
   +------------+--------------------------------------+
   | created_at | 2022-02-11T02:01:30.000000           |
   | id         | e75aef2c-b562-4cd9-a426-4a73f6cb82be |
   | location   | None                                 |
   | message    | None                                 |
   | project_id | cf5a8f5cc5834d2dacd1d54cd0a354b7     |
   | status     | PENDING                              |
   | updated_at | None                                 |
   | version    | 1                                    |
   | zone_id    | d8f81db6-937b-4388-bfb3-ba620e6c09fb |
   +------------+--------------------------------------+

   Important

   After you create a zone export resource, the DNS service continues to update the resource with any later changes that are made to the zone.

3. Record the zone export ID (e75aef2c-b562-4cd9-a426-4a73f6cb82be), because you must use it to verify your zone export, and to access the zone export data.

Verification

1. Confirm that the DNS service successfully created a zone export resource.

   Example

   $ openstack zone export show e75aef2c-b562-4cd9-a426-4a73f6cb82be

   Sample output

   +------------+--------------------------------------------------------------------------------+
   | Field      | Value                                                                          |
   +------------+--------------------------------------------------------------------------------+
   | created_at | 2022-02-11T02:01:30.000000                                                     |
   | id         | e75aef2c-b562-4cd9-a426-4a73f6cb82be                                           |
   | location   | designate://v2/zones/tasks/exports/e75aef2c-b562-4cd9-a426-4a73f6cb82be/export |
   | message    | None                                                                           |
   | project_id | cf5a8f5cc5834d2dacd1d54cd0a354b7                                               |
   | status     | COMPLETE                                                                       |
   | updated_at | 2022-02-11T02:01:30.000000                                                     |
   | version    | 2                                                                              |
   | zone_id    | d8f81db6-937b-4388-bfb3-ba620e6c09fb                                           |
   +------------+--------------------------------------------------------------------------------+

   The zone export create command creates a resource that the DNS service stores internally by default.

2. Access the contents of the zone export file, by using the zone export ID that you obtained earlier.

   Tip

   Using the -f value option prints the contents of the zone file without any tabulation. You can also redirect the contents to a local text file, which can be useful if you want to modify the exported zone file locally and then import it back into the DNS service to update the zone.

   Example

   $ openstack zone export showfile e75aef2c-b562-4cd9-a426-4a73f6cb82be -f value

   Sample output

   $ORIGIN example.com.
   $TTL 3600
   
   example.com.  IN NS ns1.example.com.
   example.com.  IN SOA ns1.example.com. admin.example.com. 1624414033 3583 600 86400 3600
   
   www.example.com.  IN A 192.0.2.2
   www.example.com.  IN A 192.0.2.1

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. List the zones on your system:

   $ openstack zone list

3. If a the zone that you want to import already exists, you must delete it first by running the openstack zone delete command.

   Example

   $ openstack zone delete example.com.

4. Confirm that your zone no longer exists by listing the zones on your system:

   $ openstack zone list

5. Confirm that the zone data you are planning to import contains a zone TTL value.

   Example

   $ cat /home/stack/zone_file

   Sample output

   $ORIGIN example.com.
   $TTL 3000
   
   example.com.  IN NS test.example.com.
   example.com.  IN SOA test.example.com. admin.example.com. 1624415706 9000 500 86000 5000
   www.example.com.  IN A 192.0.2.2
   test.example.com.  IN NS test.example.com.

6. Import a valid zone data file.

   Example

   $ openstack zone import create /home/stack/zone_file

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the project to which you want to transfer ownership of the zone.

   Example

   $ openstack project list

   Sample output

   +----------------------------------+--------------------+
   | ID                               | Name               |
   +----------------------------------+--------------------+
   | 7af0acba0486472da2447ff55df4a26d | Finance            |
   | 1d12e87fad0d437286c2873b36a12316 | Sales              |
   +----------------------------------+--------------------+

3. Using the project ID obtained in the previous step, create a zone transfer request for the zone that you want to transfer.

   Note

   When using a target project ID, no other project can accept the zone transfer. If you do not provide a target project ID, then any project that has the transfer request ID and its key can receive the zone transfer.

   Example

   To transfer the zone wow.example.com. to project 1d12e87fad0d437286c2873b36a12316, you run:

   $ openstack zone transfer request create --target-project-id 1d12e87fad0d437286c2873b36a12316 wow.example.com.

   Sample output

   +-------------------+-----------------------------------------------------+
   | Field             | Value                                               |
   +-------------------+-----------------------------------------------------+
   | created_at        | 2022-05-26T22:06:39.000000                          |
   | description       | None                                                |
   | id                | 63cab5e5-65fa-4480-b26c-c16c267c44b2                |
   | key               | BIFJIQWH                                            |
   | links             | {'self': 'http://127.0.0.1:60053/v2/zones/tasks/tra |
   |                   | nsfer_requests/63cab5e5-65fa-4480-b26c-c16c267c44b2 |
   |                   | '}                                                  |
   | project_id        | 6265985fc493465db6a978b318a01996                    |
   | status            | ACTIVE                                              |
   | target_project_id | 1d12e87fad0d437286c2873b36a12316                    |
   | updated_at        | None                                                |
   | zone_id           | 962f08b4-b671-4096-bf24-8908c9d4af0c                |
   | zone_name         | wow.example.com.                                    |
   +-------------------+-----------------------------------------------------+

4. Obtain the zone transfer request ID and its key.

   Example

   $ openstack zone transfer request list -c id -c zone_name -c key

   Sample output

   +--------------------------------------+------------------+----------+
   | id                                   | zone_name        | key      |
   +--------------------------------------+------------------+----------+
   | 63cab5e5-65fa-4480-b26c-c16c267c44b2 | wow.example.com. | BIFJIQWH |
   +--------------------------------------+------------------+----------+

5. Provide the zone transfer request ID and its key to a member of the receiving project.

6. A member of the receiving project logs in to the receiving project, and sources his or her credentials file.

   Example

   $ source ~/overcloudrc

7. Using the zone transfer request ID and its key, accept the zone transfer.

   Example

   $ openstack zone transfer accept request --transfer-id 63cab5e5-65fa-4480-b26c-c16c267c44b2 --key BIFJIQWH

   Sample output

   +--------------------------+----------------------------------------------+
   | Field                    | Value                                        |
   +--------------------------+----------------------------------------------+
   | created_at               | 2022-05-27T21:37:43.000000                   |
   | id                       | a4c4f872-c98c-411b-a787-58ed0e2dce11         |
   | key                      | BIFJIQWH                                     |
   | links                    | {'self': 'http://127.0.0.1:60053/v2/zones/ta |
   |                          | sks/transfer_accepts/a4c4f872-c98c-411b-a787 |
   |                          | -58ed0e2dce11', 'zone': 'http://127.0.0.1:60 |
   |                          | 053/v2/zones/962f08b4-b671-4096-bf24-8908c9d |
   |                          | 4af0c'}                                      |
   | project_id               | 1d12e87fad0d437286c2873b36a12316             |
   | status                   | COMPLETE                                     |
   | updated_at               | 2022-05-27T21:37:43.000000                   |
   | zone_id                  | 962f08b4-b671-4096-bf24-8908c9d4af0c         |
   | zone_transfer_request_id | 63cab5e5-65fa-4480-b26c-c16c267c44b2         |
   +--------------------------+----------------------------------------------+

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Obtain the ID for the zone transfer request you are modifying.

   Example

   $ openstack zone transfer request list -c id -c zone_name

   Sample output

   +--------------------------------------+------------------+
   | id                                   | zone_name        |
   +--------------------------------------+------------------+
   | 63cab5e5-65fa-4480-b26c-c16c267c44b2 | wow.example.com. |
   +--------------------------------------+------------------+

3. Using the zone transfer request ID obtained in the previous step, you can update a limited set of fields on zone transfer requests, such as the description and target project ID.

   Example

   $ openstack zone transfer request set --description "wow zone transfer" 63cab5e5-65fa-4480-b26c-c16c267c44b2

   Sample output

   +-------------------+-----------------------------------------------------+
   | Field             | Value                                               |
   +-------------------+-----------------------------------------------------+
   | created_at        | 2022-05-26T22:06:39.000000                          |
   | description       | wow zone transfer                                   |
   | id                | 63cab5e5-65fa-4480-b26c-c16c267c44b2                |
   | key               | BIFJIQWH                                            |
   | links             | {'self': 'http://127.0.0.1:60053/v2/zones/tasks/tra |
   |                   | nsfer_requests/63cab5e5-65fa-4480-b26c-c16c267c44b2 |
   |                   | '}                                                  |
   | project_id        | 6265985fc493465db6a978b318a01996                    |
   | status            | ACTIVE                                              |
   | target_project_id | 1d12e87fad0d437286c2873b36a12316                    |
   | updated_at        | 2022-05-27T20:52:08.000000                          |
   | zone_id           | 962f08b4-b671-4096-bf24-8908c9d4af0c                |
   | zone_name         | wow.example.com.                                    |
   +-------------------+-----------------------------------------------------+

4. Using the zone transfer request ID obtained in step 2, you can cancel a pending zone transfer, by deleting its zone transfer request.

   Example

   $ openstack zone transfer request delete 63cab5e5-65fa-4480-b26c-c16c267c44b2

   There is no output from the zone transfer request delete command. Confirm that the zone transfer request is removed by running the zone transfer request list command.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. You create record sets by using the openstack recordset create command. Record sets require a zone, name, type, and data.

   Example

   $ openstack recordset create --type A --record 192.0.2.1 example.com. www

   Note

   The trailing dot (.) is required when using fully qualified domain names (FQDN). If you omit the trailing dot, the zone name is duplicated in the resulting record name, for example www.example.com.example.com..

   In the earlier example, a user has created a zone named example.com.. Because the record set name www is not an FQDN, the DNS service prepends it to the zone name. You can achieve the same result by using the FQDN for the record set name argument:

   $ openstack recordset create --type A --record 192.0.2.1 example.com. www.example.com.

3. If you want to construct a TXT record set that exceeds the maximum length for a character string (255 characters), then you must split the string into multiple, smaller strings when you create the record set.

   In this example, a user creates a TXT record set (_domainkey.example.com) that contains one string of 410 characters by specifying two strings—​each less than the 255 character maximum:

   $ openstack recordset create --type TXT --record '"210 characters string" "200 characters string"' example.com. _domainkey

4. You can supply the --record argument multiple times to create multiple records within a record set. A typical use for multiple --record arguments is round-robin DNS.

   Example

   $ openstack recordset create --type A --record 192.0.2.1 --record 192.0.2.2 example.com. web

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. You modify record sets by using the openstack recordset set command.

   Example

   In this example, a user is updating the record set web.example.com. to contain two records:

   $ openstack recordset set example.com. web.example.com. --record 192.0.2.5 --record 192.0.2.6

   Note

   When updating a record set you can identify it by its ID or its name. If you use its name, you must use the fully qualified domain name (FQDN).

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. You delete record sets by using the openstack recordset delete command.

   Example

   In this example, a user is deleting the record set web.example.com. from the example.com. zone:

   $ openstack recordset delete example.com. web.example.com.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create a reverse lookup zone by using the openstack zone create command and specifying these required arguments:

   --email <email_address>

   a valid email address for the person responsible (owner) for the zone.

   <name>

   a name for the reverse lookup zone that conforms to the convention: <backward_IP_address>.in-addr.arpa for IPv4 addresses, and <backward_IP_address>.ip6.arpa for IPv6 addresses.

   Example

   In this example, the reverse lookup zone is designed for one PTR record, for the 198.51.100.42 address:

   $ openstack zone create --email admin@example.com \
     42.100.51.198.in-addr.arpa.

   Sample output

   +----------------+------------------------------------------+
   | Field          | Value                                    |
   +----------------+------------------------------------------+
   | action         | CREATE                                   |
   | attributes     |                                          |
   | created_at     | 2022-02-02T17:32:47.000000               |
   | description    | None                                     |
   | email          | admin@example.com                        |
   | id             | f5546034-b27e-4326-bf9d-c53ed879f7fa     |
   | masters        |                                          |
   | name           | 42.100.51.198.in-addr.arpa.              |
   | pool_id        | 794ccc2c-d751-44fe-b57f-8894c9f5c842     |
   | project_id     | 123d51544df443e790b8e95cce52c285         |
   | serial         | 1591119166                               |
   | status         | PENDING                                  |
   | transferred_at | None                                     |
   | ttl            | 3600                                     |
   | type           | PRIMARY                                  |
   | updated_at     | None                                     |
   | version        | 1                                        |
   +----------------+------------------------------------------+

   Example

   In another example for a reverse zone that is for a 198.51.100.0/24 subnet, you would create the zone:

   $ openstack zone create --email admin@example.com \
     100.51.198.in-addr.arpa.

   Sample output

   +----------------+------------------------------------------+
   | Field          | Value                                    |
   +----------------+------------------------------------------+
   | action         | CREATE                                   |
   | attributes     |                                          |
   | created_at     | 2022-02-02T17:40:23.000000               |
   | description    | None                                     |
   | email          | admin@example.com                        |
   | id             | 5669caad86a04256994cdf755df4d3c1         |
   | masters        |                                          |
   | name           | 100.51.198.in-addr.arpa.                 |
   | pool_id        | 794ccc2c-d751-44fe-b57f-8894c9f5c842     |
   | project_id     | 123d51544df443e790b8e95cce52c285         |
   | serial         | 1739276248                               |
   | status         | PENDING                                  |
   | transferred_at | None                                     |
   | ttl            | 3600                                     |
   | type           | PRIMARY                                  |
   | updated_at     | None                                     |
   | version        | 1                                        |
   +----------------+------------------------------------------+

Verification

1. Confirm that the reverse lookup zone that you created exists:

   $ openstack zone list -c id -c name -c status

   Sample output

   +--------------------------------------+-----------------------------+--------+
   | id                                   | name                        | status |
   +--------------------------------------+-----------------------------+--------+
   | f5546034-b27e-4326-bf9d-c53ed879f7fa | 42.100.51.198.in-addr.arpa. | ACTIVE |
   +--------------------------------------+-----------------------------+--------+

2. For the address-to-name mapping to be complete, the forward zone—​the zone that contains the IP address—​must exist. If the forward zone does not exist, create that now.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create a PTR record by using the openstack recordset create command and specifying these required arguments:

   --record <domain_name>

   the target, the domain name, that should be returned when a reverse lookup is performed.

   --type PTR

   the kind of record, PTR, that you are creating.

   <zone_name>

   the name of the zone, the reverse lookup zone, where the record resides.

   <record_name>

   the name of the PTR record.

   The record name must match the <zone_name> or be a member of the zone. For example, for the reverse lookup zone 100.51.198.in-addr.arpa., these are valid PTR record names: 1.100.51.198.in-addr.arpa., 2.100.51.198.in-addr.arpa., and any other reversed IP addresses in the 198.51.100.0/24 subnet.

   Example

   openstack recordset create --record www.example.com. --type PTR \
   42.100.51.198.in-addr.arpa. 42.100.51.198.in-addr.arpa.

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | action      | CREATE                               |
   | created_at  | 2022-02-02T19:55:50.000000           |
   | description | None                                 |
   | id          | ca604f72-83e6-421f-bf1c-bb4dc1df994a |
   | name        | 42.100.51.198.in-addr.arpa.          |
   | project_id  | 123d51544df443e790b8e95cce52c285     |
   | records     | www.example.com.                     |
   | status      | PENDING                              |
   | ttl         | 3600                                 |
   | type        | PTR                                  |
   | updated_at  | None                                 |
   | version     | 1                                    |
   | zone_id     | f5546034-b27e-4326-bf9d-c53ed879f7fa |
   | zone_name   | 42.100.51.198.in-addr.arpa.          |
   +-------------+--------------------------------------+

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create the PTR record by using the openstack recordset create command and specifying these required arguments:

   --record <domain_name>

   the domain name of the lookup.

   --type PTR

   the kind of record, PTR, that you are creating.

   <zone_name>

   the name of the reverse lookup zone where the record resides.

   <record_name>

   the name of the PTR record.

   The record name must match the <zone_name> or be a member of the zone. For example, for the reverse lookup zone 100.51.198.in-addr.arpa., these are valid PTR record names: 1.100.51.198.in-addr.arpa., 2.100.51.198.in-addr.arpa., and any other reversed IP addresses in the 198.51.100.0/24 subnet.

   Example

   In this example, the reverse lookup zone is more broadly defined, For example, a 100.51.198.0/24 reverse lookup zone, 100.51.198.in-addr-arpa:

   $ openstack recordset create --record cats.example.com. --type PTR \
   --ttl 3600 100.51.198.in-addr.arpa. 3.100.51.198.in-addr.arpa.

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | action      | CREATE                               |
   | created_at  | 2022-02-02T20:10:54.000000           |
   | description | None                                 |
   | id          | c843729b-7aaf-4f99-a40a-d9bf70edf271 |
   | name        | 3.100.51.198.in-addr.arpa.           |
   | project_id  | 123d51544df443e790b8e95cce52c285     |
   | records     | cats.example.com.                    |
   | status      | PENDING                              |
   | ttl         | 3600                                 |
   | type        | PTR                                  |
   | updated_at  | None                                 |
   | version     | 1                                    |
   | zone_id     | e9fd0ced-1d3e-43fa-b9aa-6d4b7a73988d |
   | zone_name   | 100.51.198.in-addr.arpa.             |
   +-------------+--------------------------------------+

Verification

1. Perform a reverse lookup to confirm that the IP address (198.51.100.3) is mapped to the domain name (cats.example.com).

   Example

   In this example, 203.0.113.5 is one of the DNS servers in the deployment:

   $ dig @203.0.113.5 -x 198.51.100.3 +short

   Sample output

   cats.example.com.

2. Perform a reverse lookup to confirm that any other IP address (198.51.100.0/24) is mapped to the domain name (example.com).

   Example

   In this example, 203.0.113.5 is one of the DNS servers in the deployment:

   $ dig @203.0.113.5 -x 198.51.100.10 +short

   Sample output

   example.com.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Determine the ID of the floating IP address for which you want to delete a PTR record. You need this information in a later step.

   $ openstack floating ip list -c ID -c "Floating IP Address"

   Sample output

   +--------------------------------------+---------------------+
   | ID                                   | Floating IP Address |
   +--------------------------------------+---------------------+
   | 5c02c519-4928-4a38-bd10-c748c200912f | 192.0.2.11          |
   | 89532684-13e1-4af3-bd79-f434c9920cc3 | 192.0.2.12          |
   | ea3ebc6d-a146-47cd-aaa8-35f06e1e8c3d | 192.0.2.13          |
   +--------------------------------------+---------------------+

3. Determine the RHOSP region name of the neutron instance that hosts the floating IP. You need this information in a later step.

   $ openstack endpoint list -c ID -c Region -c "Service Name"

   Sample output

   +----------------------------------+-----------+--------------+
   | ID                               | Region    | Service Name |
   +----------------------------------+-----------+--------------+
   | 16526452effd467a915155ceccf79dae | RegionOne | placement    |
   | 21bf826a62a14456a61bd8f39648e849 | RegionOne | keystone     |
   | 9cb1956999c54001a39d11ea14e037a1 | RegionOne | nova         |
   | bdeec4e2665d4605bb89e16a8b1bc50d | RegionOne | glance       |
   | ced05a1c03ab44caa1a351ace95429e6 | RegionOne | neutron      |
   | e79e3113ea544d039b3a6378e60bdf3f | RegionOne | nova         |
   | f91ee44123954b6c82162dcd2d4fc965 | RegionOne | designate    |
   +----------------------------------+-----------+--------------+

4. Create the PTR record by using the openstack ptr record set command and specifying these required arguments:

   <floating_IP_ID>

   the floating IP ID in the format: <region_name>:<floating_IP_ID>.

   <ptrd_name>

   the target, the domain name, that should be returned when a reverse lookup is performed.

   Example

   $ openstack ptr record set RegionOne:5c02c519-4928-4a38-bd10-c748c200912f ftp.example.com.

   Sample output

   +-------------+------------------------------------------------+
   | Field       | Value                                          |
   +-------------+------------------------------------------------+
   | action      | CREATE                                         |
   | address     | 192.0.2.11                                     |
   | description | None                                           |
   | id          | RegionOne:5c02c519-4928-4a38-bd10-c748c200912f |
   | ptrdname    | ftp.example.com.                               |
   | status      | PENDING                                        |
   | ttl         | 3600                                           |
   +-------------+------------------------------------------------+

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Determine the ID of the floating IP address for which you want to delete a PTR record. You need this information in a later step.

   $ openstack floating ip list -c ID -c "Floating IP Address"

   Sample output

   +--------------------------------------+---------------------+
   | ID                                   | Floating IP Address |
   +--------------------------------------+---------------------+
   | 5c02c519-4928-4a38-bd10-c748c200912f | 192.0.2.11          |
   | 89532684-13e1-4af3-bd79-f434c9920cc3 | 192.0.2.12          |
   | ea3ebc6d-a146-47cd-aaa8-35f06e1e8c3d | 192.0.2.13          |
   +--------------------------------------+---------------------+

3. Determine the name of your RHOSP region. You need this information in a later step.

   $ openstack endpoint list -c ID -c Region -c "Service Name"

   Sample output

   +----------------------------------+-----------+--------------+
   | ID                               | Region    | Service Name |
   +----------------------------------+-----------+--------------+
   | 16526452effd467a915155ceccf79dae | RegionOne | placement    |
   | 21bf826a62a14456a61bd8f39648e849 | RegionOne | keystone     |
   | 9cb1956999c54001a39d11ea14e037a1 | RegionOne | nova         |
   | bdeec4e2665d4605bb89e16a8b1bc50d | RegionOne | glance       |
   | ced05a1c03ab44caa1a351ace95429e6 | RegionOne | neutron      |
   | e79e3113ea544d039b3a6378e60bdf3f | RegionOne | nova         |
   | f91ee44123954b6c82162dcd2d4fc965 | RegionOne | designate    |
   +----------------------------------+-----------+--------------+

4. Delete the PTR record by using the openstack ptr record unset command and specifying these required arguments:

   <floating_IP_ID>

   the floating IP ID in the format: <region>:<floating_IP_ID>.

   Example

   $ openstack ptr record unset RegionOne:5c02c519-4928-4a38-bd10-c748c200912f

Procedure

1. Log in to one of the Controller nodes and display the current running DNS service pool configuration to the console.

   Example

   In this example, the administrator accesses a Controller node, controller-0.ctlplane, through SSH as the tripleo-admin user and executes the designate-manage pool show_config command running in the designate_central container:

   $ ssh tripleo-admin@controller-0.ctlplane sudo podman exec \
   designate_central designate-manage pool show_config

   Sample output

   Pool Configuration:
   -------------------
   also_notifies: []
   attributes: {}
   description: Default Pool
   id: 794ccc2c-d751-44fe-b57f-8894c9f5c842
   name: default
   nameservers:
   - host: 192.0.2.111
     port: 53
   - host: 192.0.2.109
     port: 53
   - host: 192.0.2.131
     port: 53
   ns_records:
   - hostname: ns2.example.com.
     priority: 2
   - hostname: ns1.example.com.
     priority: 1
   - hostname: ns3.example.com.
     priority: 3
   targets:
   - description: BIND9 Server 3
     masters:
     - host: 192.0.2.137
       port: 16002
     - host: 192.0.2.137
       port: 16001
     - host: 192.0.2.137
       port: 16000
     options:
       host: 192.0.2.111
       port: '53'
       rndc_config_file: /etc/designate/private/bind3.conf
       rndc_host: 192.0.2.111
       rndc_port: '953'
     type: bind9
   - description: BIND9 Server 2
     masters:
     - host: 192.0.2.137
       port: 16001
     - host: 192.0.2.137
       port: 16002
     - host: 192.0.2.137
       port: 16000
     options:
       host: 192.0.2.131
       port: '53'
       rndc_config_file: /etc/designate/private/bind2.conf
       rndc_host: 192.0.2.131
       rndc_port: '953'
     type: bind9
   - description: BIND9 Server 1
     masters:
     - host: 192.0.2.137
       port: 16002
     - host: 192.0.2.137
       port: 16001
     - host: 192.0.2.137
       port: 16000
     options:
       host: 192.0.2.109
       port: '53'
       rndc_config_file: /etc/designate/private/bind1.conf
       rndc_host: 192.0.2.109
       rndc_port: '953'
     type: bind9

2. If you want to export the current pool configuration to a file, use the designate-manage pool generate_file command.

   Example

   In this example, the administrator accesses a Controller node, controller-0.ctlplane, through SSH as the tripleo-admin user and executes the designate-manage pool generate_file --file <file_name> command running in the designate_central container. The DNS service exports the current pool configuration to a file that is specified by the --file option, in this example, ~/my_dns_service_config.yaml:

   $ ssh tripleo-admin@controller-0.ctlplane sudo podman exec \
   designate_central designate-manage pool generate_file \
   --file ~/my_dns_service_config.yaml

   Tip

   Use the podman cp command to copy files from a container to your local system.

Procedure

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. List the available RHOSP service endpoints:

   $ openstack endpoint list --service designate -c Interface -c URL

   Sample output

   +-----------+-------------------------+
   | Interface | URL                     |
   +-----------+-------------------------+
   | internal  | http://172.17.1.44:9001 |
   | public    | http://10.0.0.147:9001  |
   | admin     | http://172.17.1.44:9001 |
   +-----------+-------------------------+