Designate requires you to use fully qualified domain names—this includes the trailing “.”. Strictly speaking, a name is not a FQDN without that, and
Designate will enforce this.
For each domain, the DNS server holds records. Each record has a type, a name, a time-to-live and any associated data. While there are many record types,
Designate supports nine common types as of the Kilo release, shown in the
following table. Remember, each record also has a name—the example data shown here is the result of a query for that name.
Record Type
Example Data Description
A 10.0.0.1 An IPv4 Address record. AAAA 2001:DB8::1 An IPv6 Address record.
CNAME foo.example.com. A canonical name—this is an entry used to map one name to another. For example, if there is a DNS A record named bar.example.com, referring to 10.0.0.1, then you can create a CNAME record named
foo.example.com. referring to bar.example.com. (the true, or canonical, name of the resource).
MX 10 mail.example .com.
A mail exchange server for the domain. This is used by mail agents to decide how to send mail to email addresses in this domain.
NS ns1.example.com. A name server record. The NS records on a domain specify which name servers are authoritative for the domain.
SSHFP 1 2 a4b1a288… 8821ab33ef
A public SSH host key fingerprint. This can be used to help verify hosts are who they say when using ssh. SPF v=spf1
ip4:192.0.2.0/24 a –all
A Sender Policy Framework record, used to help
prevent email spoofing. It enables you to specify rules to filter out incoming email. TXT records are often used for this instead.
SRV 20 5 5060
sip.example.com.
A general service locator record. This is used to locate newer services rather than using a service-specific type like MX. See RFC 2782.
TXT Some example text.
Arbitrary text, either for human or machine consumption.
Most often, you will use the A, AAAA, CNAME and perhaps MX records. For deploying some applications you may also take advantage of SRV records to advertise the availability of the application service to the rest of the organization. The remainder are primarily used by the administrator or for special purposes.
Record sets are groups of records with the same type, name, and TTL, but with different data. So, you can define an A record set with multiple IP addresses as data. The name is what you are actually using when you lookup a resource. For example, to lookup the address (A) record name blue.foobar.example.com from
the DNS server at 172.16.98.136, you can use the host utility in Linux:
$ host -t A blue.foobar.example.com. 172.16.98.136 Using domain server:
Name: 172.16.98.136
Address: 172.16.98.136#53 Aliases:
blue.foobar.example.com has address 10.1.0.100 $
In the quota list, the domain_recordsets entry indicates the maximum number of
record sets (ie, unique type/name combinations) you may have in a single domain. The recordset_records indicates the maximum number of records in a single
record set. And finally the domain_records entry puts an additional constraint on
total records in a domain.
Creating a domain using the CLI is straightforward—you use the domain-create
command.
$ designate domain-create --ttl 3600 --name foobar.example.com. --email [email protected] +---+---+ | Field | Value | +---+---+ | description | None | | created_at | 2015-08-10T19:11:22.000000 | | updated_at | None | | email | [email protected] | | ttl | 3600 | | serial | 1439233882 | | id | 7254c2b3-187c-428e-974d-03bac08cb2af | | name | foobar.example.com. | +---+---+ $
You will notice that you must specify an email address as the contact for the domain. You also may specify the TTL value. This value is used by downstream caching name servers to know how long to hold on to the data before refreshing their cache. The value is in seconds; the longer you specify, the more time it will take for changes to go into effect across the entire Internet. However, specifying too low of a value for a frequently looked up domain can overburden your DNS servers. The default value in Designate is 3600, or one hour.
Once you have created a domain, you can start creating records. When you spin up a new VM, you can create a DNS entry for it so that other VMs within the cloud can access it by name, rather than by IP address. To create the record we used in the example lookup earlier, use this command.
$ designate record-create --type A --name blue.foobar.example.com. \ --data 10.1.0.100 foobar.example.com. +---+---+ | Field | Value | +---+---+ | description | None | | type | A | | created_at | 2015-08-10T19:18:59.000000 | | updated_at | None | | domain_id | 7254c2b3-187c-428e-974d-03bac08cb2af | | priority | None |
| ttl | None | | data | 10.1.0.100 | | id | fc83692a-f484-41fa-81c8-25300a908f7b | | name | blue.foobar.example.com. | +---+---+ $
You will notice that the statement above says “within the cloud.” The VM IP
address at spin up is typically a private address, so machines external to the cloud will not be able to access the address directly. To enable external systems to access the VM via the name lookup, you need to associate a DNS entry with the floating IP address, not the private IP address.
One option to handle this cleanly is to use two different domain names for internal and external references. For example, if you want others in your organization to access your application from outside the cloud, you could create a domain
cloud.example.com and another cloud-local.example.com. When you provision a
VM (or a port in Neutron), you create an entry in the cloud-local.example.com
domain. When you associate a floating IP address with that VM, you create a separate entry for the floating IP in cloud.example.com. Your internal cloud
applications can refer to the cloud-local.example.com domain and the external
clients to the cloud.example.com domain.
This works, but it’s a pretty cumbersome solution. The alternative typically used in DNS is called split-horizon DNS. In this configuration, the DNS server can look at information about the inbound request, such as the DNS server IP address it came in through, or the source IP address of the query. It uses this information to
choose the DNS view in which to evaluate the query response. DNS views enable you to define a different response for the same query—one in each view. So, you can define an A record for www.cloud.example.com. In the internal view that
resolves to 10.1.0.100, and an A record for www.cloud.example.com in the external
view that resolves to the floating IP address.
Unfortunately, as of the Kilo release, Designate does not yet support split-horizon DNS. However, it is on the roadmap so we can look forward to it in a future
release.
Designate is a powerful and important part in automating your deployments. The ability to make your application immediately accessible via a DNS entry is critical to the rapid spin up of applications. Without the capabilities of Designate,
application deployments in OpenStack would be limited by the often manual DNS entry creation process.
MAGNUM
One of the newest and most interesting components in the OpenStack ecosystem is a container focused project called Magnum. If you are unfamiliar with them, containers are a virtualization technology similar to virtual machines, only they work without a hypervisor. A more detailed conversation about exactly what containers are, how they compare to virtual machines, and the challenges/
solutions they provide can be found at the beginning of Chapter 6. In truth, when used in an OpenStack environment, containers actually have to live on top of classically provisioned instances. However, for the purposes of understanding what Magnum is and why it is important, containers can simply be looked at as another type of virtual machine that cannot be managed via Nova or Neutron.