Associate a FQDN to your VMs

The xip.io approach

The INFN Cloud DNS implements a mechanism very similar to that of xip.io and of nip.io. This means that every INFN Cloud IP address is always resolved by any DNS name in the form:

<any string>.<your INFN Cloud public IP address>.myip.cloud.infn.it.

For example, suppose that the public address of your VM is 90.147.174.232.

user@laptop:~$ host wordpress.90.147.174.232.myip.cloud.infn.it
wordpress.90.147.174.232.myip.cloud.infn.it has address 90.147.174.232

but also

user@laptop:~$ host apache.90.147.174.232.myip.cloud.infn.it

and

user@laptop:~$ host xxxyyyzzz.90.147.174.232.myip.cloud.infn.it
xxxyyyzzz.90.147.174.232.myip.cloud.infn.it has address 90.147.174.232

This mechanism is useful when you want to expose one or more services based on http(s) on your VMs, you can obtain x509 certificates for the FQDNs you decide to use.

The traditional approach

If you plan to create a long term running service and you want a “nicer” FQDN or you think the IP address behind the service might not be always the same, you can open a ticket on the INFN Cloud Service Desk system (https://servicedesk.cloud.infn.it) asking for a custom FQDN for your service. This will have the form:

<hostname>.<project>.cloud.infn.it

x509 Certificates

x509 certificates for SSL connections can be asked for by opening a ticket on the INFN Cloud Service Desk system. Another possible approach is that of managing the x509 certificate lifecycle autonomously using Let’s Encrypt certificates.