The HPE Helion OpenStack DNS Service supports several different backends for domain name service. The choice of backend must be included in the deployment model before the HPE Helion OpenStack install is completed.
By default any user in the project is allowed to manage a DNS domain. This can be changed by updating the Policy.json file for Designate.
The backends that are available within the DNS Service are separated into two categories, self-contained and external.
Category | Backend | Description | Recommended For |
---|---|---|---|
Self-contained | PowerDNS 3.4.1, BIND 9.9.5 | All components necessary will be installed and configured as part of the HPE Helion OpenStack install. | POCs and customers who wish to keep cloud and traditional DNS separated. |
External | InfoBlox | The authoritative DNS server itself is external to HPE Helion OpenStack. Management and configuration is out of scope for the Cloud Lifecycle Manager but remains the responsibility of the customer. | Customers who wish to integrate with their existing DNS infrastructure. |
HPE Helion OpenStack DNS Service defaults to the BIND back-end if another back-end is not configured for domain name service. BIND will be deployed to one or more control planes clusters. The following configuration example shows how the BIND service is installed.
Ensure the DNS Service components and the BIND component have been placed on a cluster. BIND can be placed on a cluster separate from the other DNS service components.
control-planes: - name: control-plane-1 region-name: region1 clusters: - name: cluster1 service-components: - lifecycle-manager - mariadb - ip-cluster - apache2 - ... - designate-api - designate-central - designate-pool-manager - designate-zone-manager - designate-mdns - designate-client - bind
Updating the Input Model
When the back-end is configured, add bind-ext
to the file
network_groups.yml
.
Edit
~/openstack/my_cloud/definition/data/network_groups.yml
to add bind-ext
to component-endpoints.
name: EXTERNAL-API hostname-suffix: extapi component-endpoints: - bind-ext
Save the file.
HPE Helion OpenStack 5 and older use the PowerDNS v3.4 backend for Designate. The database schema used in the previous version is not compatible with PowerDNS v4. This means that migration of PowerDNS v3 to v4 is not supported.
HPE Helion OpenStack DNS Service and PowerDNS can be installed together instead of the default BIND backend. PowerDNS will be deployed to one or more control planes clusters. The following configuration example shows how the PowerDNS service is installed.
To configure the backend for PowerDNS, follow these steps.
Ensure the DNS Service components and the PowerDNS component have been placed on a cluster. PowerDNS may be placed on a separate cluster to the other DNS Service components. Ensure the default bind component has been removed.
control-planes: - name: control-plane-1 region-name: region1 clusters: - name: cluster1 service-components: - lifecycle-manager - mariadb - ip-cluster - apache2 - ... - designate-api - designate-central - designate-pool-manager - designate-zone-manager - designate-mdns - designate-client - powerdns
Edit the
~/openstack/my_cloud/definitions/data/network_groups.yml
file to include the powerdns-ext.
- name: EXTERNAL-API hostname-suffix: extapi component-endpoints: - powerdns-ext load-balancers: - provider: ip-cluster
Edit the
~/openstack/my_cloud/definitions/data/firewall_rules.yml
to allow UDP/TCP access.
- name: DNSudp # network-groups lists the network group names that the rules apply to network-groups: - EXTERNAL-API rules: - type: allow # range of remote addresses in CIDR format that this rule applies to remote-ip-prefix: 0.0.0.0/0 port-range-min: 53 port-range-max: 53 protocol: udp - name: DNStcp # network-groups lists the network group names that the rules apply to network-groups: - EXTERNAL-API rules: - type: allow # range of remote addresses in CIDR format that this rule applies to remote-ip-prefix: 0.0.0.0/0 port-range-min: 53 port-range-max: 53 protocol: tcp
Please see Book “Operations Guide”, Chapter 9 “Managing Networking”, Section 9.2 “DNS Service Overview”, Section 9.2.2 “Designate Initial Configuration” for post-installation DNS Service configuration.
To configure the default DNS domain and Name Server records for the default pool, follow these steps.
Ensure that designate_config.yml
file is present in the
~/openstack/my_cloud/definition/data/designate
folder. If
the file or folder is not present, create the folder and copy
designate_config.yml
file from one of the example input
models (for example,
~/openstack/examples/entry-scale-kvm/data/designate/designate_config.yml
).
Modify the dns_domain and/or
ns_records entries in the
designate_config.yml
file.
data: dns_domain: example.org. ns_records: hostname: ns1.example.org. priority: 1 hostname: ns2.example.org. priority: 2
Edit your input model's control_plane.yml
file to
include DESIGNATE-CONFIG-CP1 in
configuration-data section.
control-planes: - name: control-plane-1 region-name: region1 lifecycle-manager-target configuration-data: - DESIGNATE-CONFIG-CP1 - NEUTRON-CONFIG-CP1
Continue your cloud deployment by reviewing and committing your changes.
$ git add ~/openstack/my_cloud/definition/data/designate/designate_config.yml $ git commit -m "Adding DNS Domain and NS Records"
In an entry-scale model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.1 “Entry-Scale Cloud”), you will have 3 ns_records since the DNS service runs on all three control planes.
In a mid-scale model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.3 “Single-Region Mid-Size Model”) or dedicated metering, monitoring and logging model (Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 9 “Example Configurations”, Section 9.3 “KVM Examples”, Section 9.3.2 “Entry Scale Cloud with Metering and Monitoring Services”), the above example would be correct since there are only two controller nodes.