Chapter 1. Introduction to the DNS service
The DNS service (designate) provides a DNS-as-a-Service implementation for Red Hat OpenStack platform (RHOSP) deployments.
This section briefly describes some Domain Name System (DNS) basics, describes the DNS service components, presents a simple use case, and lists various ways to run the DNS service.
The topics included in this section are:
1.1. Basics of the Domain Name System (DNS)
The Domain Name System (DNS) is a naming system for resources connected to a private or a public network. A hierarchical, distributed database, DNS associates information about resources with domain names that are organized into various groups called zones. Authoritative name servers store resource and zone information in records which can be queried by resolvers to identify and locate resources for routing network data.
Names are divided up into a hierarchy of zones which facilitates delegation. Separate name servers are responsible for a particular zone.
Figure 1.1. The Domain Name System
The root zone, which is simply . (a dot), contains records that delegate various top-level domains (TLDs) to other name servers. These types of records are called name server (NS) records and identify which DNS server is authoritative for a particular domain. It is not uncommon for there to be more than one NS record to indicate a primary and a backup name server for a domain.
Beneath the root zone are various TLD name servers that contain records for domains only within their TLD. These are address records and canonical name records and are referred to as A and CNAME records, respectively.
For example, the .com name server contains a CNAME record for example.com, in addition to NS records that delegate zones to other name servers. The domain example.com might have its own name server so that it can then create other domains like cloud.example.com.
Resolvers are often formed in two parts: a stub resolver which is usually a library on a user’s computer, and a recursive resolver that performs queries against name servers before returning the result to the user. When searching for a domain, the resolver starts at the end of the domain and works toward the beginning of the domain.
For example, when searching for cloud.example.com, the resolver starts with the root name server .. The root replies with the location of the .com name server. The resolver then contacts the .com name server to get the example.com name server. Finally, the resolver locates the cloud.example.com record and returns it to the user.
Figure 1.2. Resolving a DNS query
| 1 |
A user queries for the address of |
| 2 |
The recursive resolver queries the |
| 3 |
The record is not found, and the |
| 4 |
The resolver queries the |
| 5 |
The record is not found, and the |
| 6 |
The resolver queries the |
| 7 |
The |
| 8 |
The resolver forwards the A record for |
To make this search more efficient, the results are cached on the resolver, so after the first user has requested cloud.example.com, the resolver can quickly return the cached result for subsequent requests.
1.2. Introducing the RHOSP DNS service
The Red Hat OpenStack Platform (RHOSP) DNS service (designate) is a multi-tenant service that enables you to manage DNS records, names, and zones. The RHOSP DNS service provides a REST API, and is integrated with the RHOSP Identity service (keystone) for user management.
Using RHOSP director you can deploy BIND instances to contain DNS records, or you can integrate the DNS service into an existing BIND infrastructure. In addition, director can configure DNS service integration with the RHOSP Networking service (neutron) to automatically create records for compute instances, network ports, and floating IPs.
1.3. DNS service components
The Red Hat OpenStack Platform (RHOSP) DNS service (designate) is comprised of several different services that run in containers on one or more RHOSP Controller hosts, by default:
- Designate API (
designate-apicontainer) - Provides the OpenStack standard REST API for users and the RHOSP 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-producercontainer) -
Orchestrates periodic tasks that are run by designate. These tasks are long-running and potentially large jobs such as emitting
dns.zone.existsfor Ceilometer, purging deleted zones from the database, polling secondary zones at their refresh intervals, generating delayedNOTIFYtransactions, and invoking a periodic recovery of zones in an error state. - Central (
designate-centralcontainer) - 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-workercontainer) - 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-mdnscontainer) - 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.3. The DNS service architecture
In RHOSP, by default, the DNS components are BIND 9 and Unbound:
- BIND 9 (
bindcontainer) - Provides a DNS server for the DNS service. BIND is an open source suite of DNS software, and specifically acts as the authoritative nameserver.
- Unbound (
unboundcontainer) - 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.
1.4. A common deployment scenario for the DNS service
A user has created two zones, zone1.cloud.example.com and zone2.cloud.example.com, and the DNS service adds a new Start of Authority (SOA) record and new a name server (NS) record for each new zone, respectively, on the DNS name server.
Using the RHOSP Networking service, 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 1.4. Common DNS service deployment
| 1 | You can associate domains and names with floating IPs, ports, and networks in the RHOSP Networking service. The RHOSP Networking service uses the designate API to manage records when ports are created and destroyed. |
| 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. |
Additional resources
1.5. Different ways to use the DNS service
The Red Hat OpenStack Platform (RHOSP) DNS service (designate) provides a REST API and that is commonly used in three ways.
- The most common is to use the RHOSP OpenStack client, a python command line tool with commands for interacting with RHOSP services.
- You can also use the DNS service through a graphical user interface, the RHOSP Dashboard (horizon).
- Developers can use the OpenStack SDK for writing applications. For more information, see openstacksdk.
