Administrative metadata

The IP Register database contains information about domain names under cam.ac.uk and subnets on the CUDN. These are organized into mzones which determine how who has administrative access to which domains and subnets.

This page has some notes on how we organize this administrative metadata. This is what happens after the naming committee has approved a domain, to put their decision into effect.

• Management zones
• Naming an mzone
• Staff details
• Shared IT staff
• Split institutions
• UIS mzones
• Soliton domains
• Soliton contacts
• Renaming domains
• Long / short domain aliases

Management zones

The platonic ideal of an mzone corresponds to an institution with a CUDN connection, one or more subnet allocations, and one or more domain names, with control delegated to that institution's IT staff. The reality is often not that simple.

As a rule of thumb, an mzone should only exist if it has network allocations, apart from the umbrella mzones discussed under domain names below.

Naming an mzone

Normally an mzone will match its primary domain name, e.g. Trinity College's domain name is trin.cam.ac.uk and its mzone is TRIN. There is little cost in IP Register to renaming or reorganizing an mzone when an institution changes. The costs are more to do with any change of domain name, as discussed below.

Mistakes were made: In the User Admin database it is much harder to rename an institution code. Unfortunately, although the frozen User Admin inst codes were supposed to be a hidden implementation detail, they have been exposed by the Lookup directory. So the code for Plant Sciences is forever BOT (for botany). Let's not repeat that mistake.

Staff details

The contact email address for an mzone should be a role address rather than an individual. It may be used by automated systems to inform the relevant people about something important.

The mzone_co list contains the IT staff that should have control over the mzone. They should all be technically savvy. We try to put the person's full name in the remarks field for our convenience, and use the Lookup directory for other details.

We expect IT staff to help us to keep the mzone_co list up-to-date. Whenever we make a change to an mzone's details we send a copy of the mzone_info rubric to the relevant people, which is usually enough to prompt a correction if one is needed.

Mistakes were made: There is still the occasional phone number lurking around, from the days before Lookup.

Shared IT staff

There are a number of cases where IT support for an institution is provided by staff from a different institution, such as the UIS Institution Support service, or the Clinical School Computing Service.

In these cases, to reduce churn it's generally better that the mzone keeps a separate identity if the institution has a separate management structure. Whether it makes sense to combine or keep separate is a bit of a guessing game; we generally choose based on how the institutions' IT staff want to run things.

Difficult cases: The Institute for Continuing Education was folded into the ADMIN mzone in 2012, and split back out again in 2019. However this had more to do with the organization of the UIS than changes in ICE.

Split institutions

In a few cases an institution has multiple related mzones. These should be named with a common prefix, so for example CCI-BIRDLIFE corresponds to birdlife.conservation.cam.ac.uk.

Mistakes were made: When Physics was split, the mzones were named in DNS order like HEP-PHY. This has the disadvantage of not keeping related mzones together when they ae listed in alphabetical order.

UIS mzones

Within the UIS there are mzones that correspond roughly to teams or services. As in the wider University this is to give our colleagues as much autonomy as is sensible by providing a self-service system.

As usual, an mzone name matches its principal domain name, with a UIS- prefix, though there are a few pre-UIS mzones that lack the prefix.

We are gradually moving towards a security architecture with greater network partitioning, which we hope will match the mzone structure resonably well. However this structure is not (as of late 2019) widespread, and we have some cross-cutting teams, such as Security Engineering, and Servers and Storage, which do not fit the mzone structure too well. It remains to be seen how well this will work, or how it will fit with plans for on-site cloud infrastructure.

Soliton domains

We have a lot of domain names that exist only to host a web site and maybe a mail domain. These are assigned to an mzone as follows:

• If the domain belongs to particular institution (or team in the UIS) and is hosted in their mzone, then it is assigned to their mzone.

• If the domain is a subdomain of one of the special umbrella domains it is assigned to the corresponding umbrella mzone.

• Otherwise it is assigned to the SOLITON mzone.

Web sites hosted by the UIS are assigned to an umbrella or SOLITON mzone. The UIS web services have a special API for managing the DNS for web sites.

Soliton contacts

We use the remarks field of a soliton domain to record a hint as to who is responsible for it. There isn't any process for keeping these notes up-to-date, and there is no automated system that relies on this information. It is an aid for finding the right people, together with the domain's description, the contents of the web site, and colleagues who might have a better knowledge of the current state of things.

These contacts are rarely used, so it works quite well to not worry about their accuracy until the information is actually needed.

Mistakes were made: Often the people responsible for these domains are not technical. We have had problems when a domain was assigned to an mzone with no network assignments and no technical staff, so our automated systems sent a request to someone who wasn't prepared for it and/or was no longer involved with the web site.

Renaming domains

When an institution changes its domain name, a lot of work is required from their IT staff to rename all their gear into the new domain. During this transition period we will assign both old and new domain names to the institution's mzone.

Typically we don't expect a rename to take less than a year, but we also do not want to allow it to drag on forever.

Long / short domain aliases

In cases where an institution wants a more friendly domain name but does not want to do a wholesale rename, we assign the domain alias to the LONGFORM mzone. These aliases are supposed to be for limited use, for email and for the institution's main web site. This limitation is enforced by assigning the domain to a separate mzone.