Central Register

DNS is normally one of the first services set up for new infrastructures in the data center; otherwise, it is hardly possible to use the other computers. Many people often only realize how crucial DNS is when it stops working, such as when a website cannot be accessed because the responsible DNS server has crashed. In short: DNS is a fundamental prerequisite for virtually all other services an admin sets up.

The topic of DNS has several dimensions: On the one hand, computers must be able to resolve hostnames to communicate with other computers within and outside the setup. On the other hand, the management of your own DNS entries is done in the appropriate DNS servers: A website that can only be accessed via IP address is rarely desirable; a web address of the expected structure is preferred (e.g., www.example.com ). To that end, a corresponding A record (or AAAA [quad-A] record for IPv6) must be stored for a domain, and a corresponding PTR record (which refers to the A record) must be created in the DNS file for the respective address space.

DNS management for VMs in clouds must be deeply integrated into the cloud itself. The software used must create suitable DNS entries for A/AAAA and PTR records when creating virtual instances, as can be well demonstrated by using the concrete example of OpenStack. The OpenStack component that takes care of the management of DNS entries is called Designate. In this article, I explain what the Designate architecture looks like and at which points Designate becomes involved in setups to attain functioning DNS entries for virtual cloud instances. The goal is DNS as a Service (DNSaaS).

Conventional Is Simple

Classic setups planned from the beginning make DNS easy to address. In such setups it is possible to incorporate both the infrastructure required for DNS and the specific entries for individual hosts and IPs; therefore, it is obvious which servers are parts of the setup and via which address one must access them.

Another factor is that typical setups do not generally change during their service lives. A computer or two might be added, but that can be sorted out easily with a few new DNS entries. The DNS configuration doesn't pose a problem for virtualized setups either, because the only difference is usually that services run in VMs and not on real machines.

Everything Is Different in the Cloud

Virtual environments in clouds differ from their conventional counterparts in two ways. Because clouds increasingly focus on the topic of automation, a cloud setup can usually be rolled out automatically using the orchestration components of the cloud being used. You can specify in a template file that a certain number of application servers, databases, load balancers, or monitoring servers are needed, and the cloud sets up the environment accordingly.

However, clouds also increasingly focus on the on-demand factor; therefore, when installing the setup, you don't have to have already thought about how many servers the setup ultimately needs, because you can enhance any kind of service easily at a later date. The other way around isn't a problem either: The current setup can be reduced if fewer virtual instance are required for the individual server types in times of low load.

Two Worlds

Quickly it becomes self-evident: Classic, rigid DNS management and clouds do not go together. Anyone who starts a virtual machine in a typical cloud will initially receive a configuration without DNS entries, which means there aren't any A records for a specific domain or PTR records for the respective IP addresses. The problem with the A records could still be solved somehow; after all, you could enter A records for the public IP addresses in the DNS configuration of a domain after starting the virtual setup, but that's a lengthy process, and if the whole virtual environment can be conjured up out of nothing in just a few minutes, it doesn't make sense then to spend a load of time creating the DNS entries for the setup.

The principle doesn't work at all for the PTR records for domains, because public clouds assign public IPs dynamically from a predefined pool and authority over the domains lies with the provider. However, the provider is hardly going to allow its customers direct access to its DNS server. At worst in such cases, the customer is forced to create a support ticket with the desired DNS entries; yet, this doesn't have to do with automation or dynamic use – that's why this option drops out.

Although it might be of secondary importance for HTTP and HTTPS that a PTR record is missing, anyone wanting to send email from their systems will quickly stumble: Many email servers do not even accept email if the sending server does not have a PTR record, which is almost always a sure sign of spam.