SWITCH | SWITCHdrive | SWITCHengines |

Calling your SWITCHengines instances by name: DNS and other mechanisms


#1

IP addresses

SWITCHengines assigns various kinds of IP addresses to instances:

  • “Fixed IPs” are usually on private (RFC1918) address space such as 10.0.0.0/8. They are attached directly to instances. Those addresses are not reachable from the Internet, but you can use them for communication between your instances.
  • “Floating IPs” are publicly reachable addresses. Currently those are from the 86.119.0.0/16 range. They are mapped to fixed IPs using Network Address Translation (NAT). The instances don’t “know” about these addresses.

Referring to hosts

You may want to log in to an instance via SSH, or contact a Web server running on it, or have instances connect to others to form some kind of distributed operation. In each of these cases, you could use the respective target server’s IP address—usually the Fixed IP when connecting from the “inside”, i.e. from other SWITCHengines instances on a tenant network, and the Floating IP when connecting from the general Internet.

Now, many people (the author included) don’t like to refer to hosts using raw IP addresses. You want to be able to discreetly change IP addresses without having to modify all clients.

According to a famous quote by David Wheeler: “All problems in computer science can be solved by another level of indirection”, and this is a classic example. The canonical mechanism for referring to hosts is the hostname. The canonical mechanism for mapping hostnames to addresses used to be the /etc/hosts file, which was replaced by the Domain Name System (DNS) starting in the 1980s.

/etc/hosts

When you manage multiple instances within SWITCHengines, it can be useful to set up /etc/hosts files on them that include names for all the hosts, mapping to their (Fixed) IP addresses. Configuration management systems such as Puppet allow managing such files in a central place and distributing them consistently across many hosts.

DNS

If you have control over a part of the DNS tree (such parts are called “zones”), then you can add DNS entries for your hosts. Note that only Floating IPs are useful for the general Internet. You are free to put Fixed IP addresses in your DNS zones too, although some people think that it is bad style to put private IP addresses into the public DNS. (Feel free to ignore them if you think this makes your life simpler.)

Generic default hostnames for Floating IPs

Based on the idea that every active public IP address should have a hostname, we have added “synthetic” hostnames for all Floating IPs. Thanks to DNS inverse mapping (see below), you can look up the generic name corresponding to a Floating IP using host <IP> or dig +short ptr -x <IP>. Example:

162.35.119.86.in-addr.arpa domain name pointer fl-1-162.zhdk.cloud.switch.ch.
$ dig +short ptr -x 86.119.35.162
fl-1-162.zhdk.cloud.switch.ch.```

In general, we do not advise using those hostnames except as a target for a `CNAME` (alias record in DNS).

### Example: Putting a Floating IP in DNS
Assuming that I am in control of the DNS zone `leinen.ch`, and that I would like the hostname `gitlab.leinen.ch` to refer to the Floating IP mentioned above (86.119.35.162).  I can use an `A` (IPv4 address) record or a `CNAME` (canonical name) pointer for this.

#### Variant A: Use an `A` ((IPv4) address) record
```gitlab.leinen.ch. IN A 86.119.35.162```
#### Variant B: Use a `CNAME` (canonical name) pointer
```gitlab.leinen.ch. IN CNAME fl-1-162.zhdk.cloud.switch.ch.```

### Inverse Mapping (address → name)
Note that the "inverse" mapping for the Floating IPs will always point to the generic hostname.  At present it is unfortunately not possible to have an inverse mapping point to a hostname defined by you.

## The Future
In the future, we hope to be able to offer better support for names and addresses:

- **IPv6 support.** In addition to IPv4, we also want to enable IPv6 addresses.  They are much more abundant, so every host can have a global address.  (Note that you can still protect them from outsize access using mechanisms such as security groups.) This should also free us from having to do NAT (Network Address Translation), which has performance and reliability/robustness costs.
- **Designate.** This OpenStack project will provide "DNS as a Service", and allow you to manage DNS zones using OpenStack APIs and credentials.  It is still under development and not yet considered production-ready.
- **DNS integration for Nova.** Hopefully the OpenStack Compute (Nova) service will get better DNS integration over time, so that desired hostnames can be specified when instances are created, and these hostnames are automatically entered in DNS zones.

## `$HOME/.ssh/config` as a "poor man's DNS"
If you are only interested in SSH access to your hosts, you can define your hosts in your `.ssh/config` file.  For example, the `gitlab.leinen.ch` name can be made available by adding the following to this file:

    Host gitlab.leinen.ch
        Hostname 86.119.35.162

Of course these aliases only work for SSH, and only for the user/host where this definition is present.  This mechanism can even be used to set up SSH towards instances that only have private addresses (Fixed IPs), provided that you have a "gateway" instance that has a public (Floating) IP.

    Host foo
     	Hostname 10.0.0.42
    	ProxyCommand ssh -q 86.119.34.56 nc %h %p

The `nc %h %p` command uses NetCat to set up a proxy connection through an instance with the public (Floating) IP `86.119.34.56` to the private (Fixed) IP `10.0.0.42`.  This assumes that the instances are on the same tenant network (or can reach each other through routers).