OpenShift Back End Services: The Domain Name System - Overview

In the previous two posts I covered the OpenShift Origin back end database and the OpenShift broker to node communications system (messaging).

This time I'm going to talk about the service OpenShift Origin uses to publish user's applications: The Domain Name System or DNS.

OpenShift Origin and the DNS

One of the critical functions of OpenShift Origin is the publication of new user applications.

Each new application gets its own IP name. These names are made available universally through the DNS. The name maps directly or indirectly back to the host on which the application runs. Without the DNS, the user applications would remain invisible to the rest of the world and in particular to the application's audience.

The other three back end services (Data store, Messaging and Identification/Authentication) used by OpenShift Origin are, in some sense, self-contained.  Only the OpenShift Origin broker or node needs to access them.  In fact, access by any other means would be considered a security flaw in the design or implementation of the OpenShift Origin service.

One implication of the self-contained nature of these services is that they can be implemented and run without  the need for cooperation with other parts of the network.  Publication (and the DNS) is fundamentally different. It makes no sense to run a "self-contained DNS".

This is why I'm going to urge you not to run your own.

The best way to manage this part of the OpenShift Origin service is to ask someone else to do it. Every organization has an IT department.  They're going to control both the internal and external DNS services.  They're also going to have the knowledge and resources to add a sub-domain for your applications and to configure it for your access.  You'll need to get some information from them that you'll configure into the Bind DNS plugin and then your OpenShift Origin service will be able to publish new applications automatically.

The Openshift Bind Plugin

There's currently only one DNS plugin at the moment.  This is the Bind plugin rubygem-openshift-origin-dns-bind. This is actually a misnomer.  The plugin uses the Dynamic DNS Update protocol defined in RFC 2136. Any DNS service which implements RFC 2136 should accept updates from the Bind plugin. However, the only service I can confirm is ISC Bind, hence the name.

The OpenShift service can only add applications to a single zone. All of the resource records in a dynamic zone are potentially changed. This means that the OpenShift servers should not reside in the same zone as the applications.

Bind Plugin Requirements

If you do get your IT department to set up dynamic DNS for you, this is the information you'll need from them.

The Bind plugin configuration requires:

• Update Server IP address
• Update Server port
• Update zone
• TSIG Key Type
• TSIG Key Name
• TSIG Key Value

Running a Delegated Zone

If your IT department chooses to delegate your application zone, there is some information you will have to give them.

• Primary Nameserver fully qualified domain name
• Primary Nameserver IP address
• Secondary Nameserver fully qualified domain name
• Secondary Nameserver IP address
• Zone contact: an email address for a person who can manage the domain.

Your IT department will configure this information into a Start of Authority (SOA) record, a pair of nameserver (NS) records and two A records.  These are the DNS delegation glue records which allow others to find your zone.

In this case you will be responsible for building and managing your own Dynamic DNS servers.  The next few posts will walk through how to set up your own DNS servers on ISC Bind.  This is a more involved process than either of the previous services, so I'm going to present it in several steps.

1. Caching Server - Answers queries but doesn't contain any zone data.
2. Primary Authoritative Name Server - Answers queries, contains the master copy of some zone data
3. Secondary Authoritative Name Server - Answers queries, contains a slave copy of some zone data
4. TSIG User Key - A symmetric key for user authentication 
5. Dynamic DNS Server - accepts update requests for a zone. Serves the master copy.

Unconventional DNS Configurations

There are two additional topics I plan to cover, though they're best avoided if possible.  They deliberately break the hierarchical model of the DNS and can cause considerable confusion for unwary users and administrators.

• Rogue DNS
  For labs and development
• Serving DNS from dynamic IP addresses.
  For environments like Amazon Web Services or libvirt virtual machines

A Rogue DNS service is one which serves zones which are not properly delegated.  They are accessable only if every host that participates is explicitly configured to make requests from the rogue servers.

Hosts on services like Amazon are normally given IP addresses via DHCP. If the IP address of the primary public interface is re-addressed, the DNS services must also be reconfigured and possibly all of the clients must be notified.  This extremely bad for the stability of a DNS service but may be required in some environments.

References

• The Domain Name System
• Zytrax DNS for Rocket Scientists
• RFC 1591 - The Domain Name System and Delegation
• RFC 2136 - DNS Update
• RFC 2845 - Secret Key Transaction Authentication for DNS
• ISC Bind DNS server