Delegated DNS for cloud providers

Institutions with off-site hosts and services that require names within can ask us to set up the necessary DNS records.

This page explains the process for setting up delegated DNS for cloud providers when services are being deployed off site en masse. There is a different process for the simpler case of individual off-site services.


The aim of the setup described on this page is to allow you to host services at cloud providers in a reasonably convenient way, without per-service manual setup.

We want to keep a clear line between devices and services on the CUDN, and those hosted off-site. The IP Register database will continue to manage DNS names and IP addresses for the CUDN for use by our other systems (such as DHCP and Friendly Probing). At the same time, we want you to be able to benefit from the closer integration that comes from using the cloud provider's own DNS.

The acceptable use policies for the CUDN and JANET apply to services hosted by cloud providers.

Web servers on the referenced external host must serve only Cambridge-related material when identified by the name.

Cloud subdomains

An institution's main domain name (such as will continue to be managed through the IP Register database. Services hosted by a cloud provider are given a separate subdomain, typically named after the provider (e.g.

You should discuss the name of you cloud subdomain with before doing any setup.

When the name has been confirmed you can set up the subdomain at your cloud provider. You will need to provide with the DNS delegation records to complete the initial setup - the NS records (and DS records if DNSSEC is supported by the cloud provider).

Service endpoints and friendly names

For each user-facing service there will typically be two names:

  • a service endpoint under the cloud subdomain (e.g. which is managed with the cloud provider's provisioning systems

  • a friendly name that your users see (e.g. which is added to the DNS via the IP Register database

The friendly name is set up as a CNAME pointing at the service endpoint. To create a CNAME, the IP Register database needs to know about both names:

  • Using vbox_ops, create a shadow entry for your service endpoint (e.g. without any IP addresses.

  • Using cname_ops, create the friendly name (e.g. with the target name being the service endpoint (e.g.

You can use xlist_ops to automate the set up of the vbox and cname.

The shadow vbox is underneath your cloud subdomain's delegation point, so the version that appears in the DNS is the real endpoint that you configured with your cloud provider. The shadow version of the endpoint in the IP Register database just provides a target for the friendly CNAME.

(The setup for individual off-site CNAMEs is similar, though their shadow target objects are anames rather than vboxes.)