Appendix B. Dynamic DNS Service

The installation process for RHOCP depends on a reliable name service that contains an address record for each of the target instances. When installing RHOCP in a cloud environment, the IP address of each instance is not known at the beginning. The address record for each instance must be created dyamically by the orchestration system as the instances themselves are created.

RHOSP does not have an integrated DNS service, but it is possible to create new records in a DNS service using dynamic updates as defined in RFC2137. This method uses a symmetric key to authenticate and authorize updates to a specific zone.

Installation of RHOCP on RHOSP requires a DNS service capable of accepting DNS update records for the new instances. This section describes a method to create a suitable DNS service within RHOSP as a heat stack. The resulting stack contains a DNS master and two DNS slaves. The DNS is capable of accepting DNS queries and update requests for the RHOSP service. It is suitable for delegation to make the RHOCP service accessable to users.

The Ansible playbook that creates and configures the heat stack and configures the DNS service is part of the openshift-ansible-contrib repository on on Github. The RHOSP DNS service is in the osp-dns section for reference architectures.

B.1. Automated Deployment of a DNS service

Note

Before running this playbook, be sure to initialize the RHOSP credentials environment variables.

The script invocation below is a sample that shows the required input parameters. The callouts lead to details of each parameter.

Download DNS service playbook

git clone https://github.com/openshift/openshift-ansible-contrib

B.1.1. Configure the DNS Service

The Ansible playbook requires a set of inputs that define the characteristics of the DNS service. These inputs are provided as a YAML formatted data file. The input parameters are broadly divided into three groups:

  • DNS Service settings
  • OpenStack host parameters
  • Software update subscription

In the sample file below the values must be updated for the target environment. Create a file from this template and replace the values as needed.

dns-vars.yaml

---
domain_name: ocp3.example.com          1
contact: admin@ocp3.example.com
dns_forwarders: [10.x.x.41, 10.x.x.2]  2
update_key: "NOT A REAL KEY"           3
slave_count: 2                         4

stack_name: dns-service                5
external_network: public               6

image: rhel7                           7
flavor: m1.small
ssh_user: cloud-user
ssh_key_name: ocp3

# NOTE: For Red Hat Enterprise Linux:  8
rhn_username: "rhnusername"
rhn_password: "NOT A REAL PASSWORD"
rhn_pool: "pool id string"
# Either RHN or Sat6
# sat6_hostname: ""
# sat6_organization: ""
# sat6_activationkey: ""

1
DNS Domain Name
This is the domain that the server manages. It must be a fully-qualified domain name. If it is delegated then it must be a proper subdomain of an established parent domain.
2
DNS Forwarders
This is a comma separated list of IP addresses enclosed in square brackets. Each must be the address of a DNS server that is capable of accepting forwarded DNS queries.
3
DNS Update Key
This is a DNS TSIG signing key. The key can be generated using ddns-confgen or rndc-confgen. See Generating an Update Key
4
Slave Count
The slave count defines the number of DNS slaves. A functional DNS service can have no slaves, but for legal delegation a service must have a master and at least 1 slave. The default is 2.
5
Stack Name
This value defines the name of the Heat stack that is created. It defaults to dns-service.
6
External Network Name
This value must be the name of the public or external network in the Red Hat OpenStack Platform service.
7
Instance Creation Parameters
These parameters set the characteristics of the instances which host the DNS service. The image and flavor must already be defined in the Red Hat OpenStack Platform service. The ssh_user is the user which allows login with the matching key.
8
Software Update Subscription
These parameters enable access to software updates. Use either the rhn_ or sat6 values, but not both.

B.1.2. Deploy the DNS service

The DNS service is defined as an Ansible playbook. This playbook creates a Heat stack that implements the network and the host instances for the DNS service. It then applies the DNS service configuration to each instance to complete the process.

Deploy the DNS service

export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook --private-key <keyfile> -e @dns-vars.yaml \ openshift-ansible-contrib/reference-architecture/osp-dns/deploy-dns.yaml

Where the <keyfile> is the file name of the private key file matching the OSP keypair name. If needed, adjust the location of the root of the openshift-ansible-contrib repository.

The Ansible playbook runs in two distinct phases. The first phase creates the instances as a Heat stack. The second phase configures the instances once they are ready, registering for software repositories, installing and updating packages and finally applying the named configuration.

The playbook creates a dynamic inventory based on the result of the stack, adding the new instances. No inventory file is needed to start. A warning indicating either that the inventory is not present or that the host list is empty can be disregarded.

A successful deployment displays an Ansible "PLAY RECAP" which show a count of the applied plays. It includes the IP address of the DNS server instances.

Playbook Result

...
PLAY RECAP *********************************************************************
10.0.x.187              : ok=16   changed=12   unreachable=0    failed=0
10.0.x.209              : ok=15   changed=11   unreachable=0    failed=0
10.0.x.210              : ok=15   changed=11   unreachable=0    failed=0
localhost                  : ok=7    changed=5    unreachable=0    failed=0

The first IP address is the master named. The following addresses are the slaves. Any address can be used for dynamic DNS updates, but the master is the recommended target.

B.2. Generating an Update Key

DNS updates require a special key string that can be generated by ddns-confgen which is part of the bind RPM. The only element needed is the secret string.

Create a DNS update key

rndc-confgen -a -c update.key -k update-key -r /dev/urandom
cat update.key
key "update-key" {
    algorithm hmac-md5;
    secret "key string"; # don't use this
};

The significant part of the key output is the secret field. The value can be passed via command line or by setting and exporting the DNS_UPDATE_KEY environment variable for the deploy script that follows.

B.3. Verifying the DNS Service

Verify both the operation of the DNS service and the ability to update the zone contents using nsupdate are part of the bind-utils rpm.

The installation process reports the IP addresses of the DNS servers. The IP adresses can be retrieved using openstack server list command as well.

Verify that the queries work and that the nameserver NS and A records are present. Query the service with the IP address of the master and each of the slaves in turn to be sure that all return the same results.

B.3.1. Simple Query and Zone Contents

The query below returns the contents of the entire zone. It shows the SOA, NS and A records for the zone and the DNS servers.

dig @10.x.0.187 ocp3.example.com axfr

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> @10.x.0.187 ocp3.example.com axfr
; (1 server found)
;; global options: +cmd
ocp3.example.com.   300 IN  SOA ns-master.ocp3.example.com. admin.ocp3.example.com.ocp3.example.com. 0 28800 3600 604800 86400 1
ocp3.example.com.   300 IN  NS  ns-master.ocp3.example.com. 2
ocp3.example.com.   300 IN  NS  ns0.ocp3.example.com. 3
ocp3.example.com.   300 IN  NS  ns1.ocp3.example.com. 4
ns-master.ocp3.example.com. 300 IN  A   10.x.0.187 5
ns0.ocp3.example.com.   300 IN  A   10.x.0.209 6
ns1.ocp3.example.com.   300 IN  A   10.x.0.210 7
ocp3.example.com.   300 IN  SOA ns-master.ocp3.example.com. admin.ocp3.example.com.ocp3.example.com. 0 28800 3600 604800 86400
;; Query time: 2 msec
;; SERVER: 10.19.114.187#53(10.x.0.187)
;; WHEN: Wed Jun 07 11:46:33 EDT 2017
;; XFR size: 8 records (messages 1, bytes 237)
1
OCP SOA record
2
NS record for the master server
3 4
NS records for the slave servers
5
A record for the master server
6 7
A records for the slave servers

B.3.2. Dynamic Updates

The last test is to verify that dynamic updates work. The fragments below demonstrate adding, verifying and removing a test record. The actual IP address provided does not need to refer to a real host.

nsupdate -k update.key
server 10.x.0.187
zone ocp3.example.com
update add add-test.ocp3.example.com 300 A 1.2.3.4
send
quit

Verify that the new address is present:

dig @10.x.0.187 add-test.ocp3.example.com

Once the records are verified for accuracy, remove the test record.

nsupdate -k update.key
server 10.x.0.187
zone ocp3.example.com
update delete add-test.ocp3.example.com A
send
quit

B.4. RFCs

  • RFC2137 Secure Domain Name System Dynamic Update
  • RFC2535 Domain Name System Security Extensions