DNS service components

The DNS service (designate) runs multiple specialized components in the RHOSO control plane, each handling specific DNS management tasks such as API processing, zone orchestration, and name server integration.

Specifically, these services are:

Designate API (designate-api pod)
Provides the OpenStack standard REST API for users and the RHOSO Networking service (neutron) to interact with designate. The API processes requests by sending them to the Central service over Remote Procedure Call (RPC).
Producer (designate-producer pod)
Orchestrates periodic tasks that are run by designate. These tasks are long-running and potentially large jobs such as emitting dns.zone.exists for Ceilometer, purging deleted zones from the database, polling secondary zones at their refresh intervals, generating delayed NOTIFY transactions, and invoking a periodic recovery of zones in an error state.
Central (designate-central pod)
Orchestrates zone and record set creation, update, and deletion. The Central service receives RPC requests sent by the Designate API service and applies the necessary business logic to the data while coordinating its persistent storage.
Worker (designate-worker pod)
Provides the interface to the drivers for the DNS servers that designate manages. The Worker service reads the server configuration from the designate database, and also manages periodic tasks that are requested by the Producer.
Mini DNS (designate-mdns pod)
Manages zone authoritative transfer (AXFR) requests from the name servers. The Mini DNS service also pulls DNS information about DNS zones hosted outside of the designate infrastructure.
Figure 1. The DNS service architecture

The DNS service architecture

In RHOSO, by default, the DNS components are BIND 9 and Unbound:

BIND 9 (bind pod)
Provides a DNS server for the DNS service. BIND is an open source suite of DNS software, and specifically acts as the authoritative name server.
Unbound (unbound pod)
Fulfills the role of the DNS recursive resolver, which initiates and sequences the queries needed to translate DNS requests into an IP address. Unbound is an open source program that the DNS service uses as its recursive resolver.

The DNS service uses an oslo compatible database to store data and oslo messaging to facilitate communication between services. Multiple instances of the DNS services can be run in tandem to facilitate high availability deployments, with the API process often located behind load balancers.

DNS service dedicated networks
Copy link

The DNS service requires a dedicated macvlan network attachment that provides static IP addresses for DNS service pods running in the RHOSO control plane.

While pods running on the RHOCP cluster can typically communicate over the default cluster pod network, the designate network provides a dedicated interface and a highly controlled IP address pool managed by the designate Operator.

The primary purpose of this dedicated network is to ensure that the BIND 9 and Mini DNS servers maintain static, predictable IP addresses.

In a RHOSO environment that uses the DNS service, the zone information created and stored in the BIND 9 servers includes the IP addresses of the Mini DNS services that serve the role of primary DNS servers. Because the default pod network dynamically assigns IP addresses, a rescheduled pod would necessitate resource-intensive updates across potentially thousands of zones. The designate network provides the consistent IP mapping required to keep the DNS system stable.

Additionally, the designate network provides strict access control and isolation by keeping traffic internal to the OpenShift cluster. Network activity is purposefully restricted to control plane communications, such as RNDC requests and zone transfers between the designate services.

The designateext network is an optional network that provides external access to the DNS service resolver and the DNS servers.

DNS service access methods
Copy link

You can interact with the DNS service through the OpenStack CLI, the Dashboard web interface, or the OpenStack SDK for application development.

The most common is to use the RHOSO OpenStack client, a python command line tool with commands for interacting with RHOSO services.

You can also use the DNS service through a graphical user interface, the RHOSO Dashboard (horizon).

Developers can use the OpenStack SDK for writing applications.

DNS service deployment example
Copy link

Improve your understanding of DNS operation by reviewing an example.

A user creates two zones, zone1.cloud.example.com and zone2.cloud.example.com, and the DNS service adds a new Start of Authority (SOA) record and a new name server (NS) record for each new zone, on the DNS name server.

Using the Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron), the user creates a private network and associates it to zone1 and a public network and associates it to zone2.

Finally, the user connects a VM instance to the private network and attaches a floating IP. The user connects a second instance directly to the public network. These connections trigger the Networking service to request the DNS service to create records on behalf of the user. The DNS service maps the instance names to domains on the authoritative name server and also creates PTR records to enable reverse lookups.

Figure 2. Common DNS service deployment

Common DNS service deployment

1

You can associate domains and names with floating IPs, ports, and networks in the RHOSO Networking service. The RHOSO Networking service uses the designate API to manage records when ports are created and deleted.

2

The designate Worker tells the name server to update its zone information.

3

The name server requests updated zone information from Mini DNS.

4

The name server creates both forward and reverse records.