Chapter 1. Introduction to the DNS service

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 and canonical name records which 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

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.

The Red Hat OpenStack Services on OpenShift (RHOSO) DNS service (designate) provides a DNS as a service implementation for Red Hat OpenStack Services on OpenShift (RHOSO) deployments. A multi-tenant service that enables you to manage DNS records, names, and zones, the DNS service provides a REST API, and is integrated with the Identity service (keystone) for user management.

You can deploy BIND 9 instances to contain DNS records, or you can integrate the DNS service into an existing BIND 9 infrastructure. In addition, you can configure DNS service integration with the RHOSO Networking service (neutron) to automatically create records for compute instances, network ports, and floating IPs.

The Red Hat OpenStack Services on OpenShift (RHOSO) DNS service (designate) is comprised of several different services that run in pods on the RHOSO control plane:

Figure 1.3. The DNS service architecture

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

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.

The Red Hat OpenStack Services on OpenShift (RHOSO) DNS service (designate) requires a dedicated network, the designate network. Sometimes referred to as the designate control network, the designate network is a dedicated macvlan network attachment used by DNS service (designate) pods running within the RHOSO control plane on the Red Hat OpenShift Container Platform (RHOCP) cluster. 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.

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 a new name server (NS) record for each new zone, respectively, 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 1.4. Common DNS service deployment

The Red Hat OpenStack Services on OpenShift (RHOSO) DNS service (designate) provides a REST API and that is commonly used in three ways: