ucam.org domain names

Purposes

Some misguided people will only issue hostnames to students which are generated in some poor way (for example, by requiring that the user's machine's hostname be their username). Such machines can have a more sensible names in ucam.org.

Administrators of services on student-run systems can use and publish service names for them, so that the service can be moved to different systems transparently when required.

Finally, to provide a mail domain and www site that can be used for miscellaneous Cambridge activity associated with ucam.chat and the like.

Mechanism

Allocation and Change Request Procedure

For a simple alias, please state:

• the name you want in ucam.org (see below);
• the machine name (not IP address) that it should refer to;
• the name and email address of the machine's administrator, if that's not you.

Allocation Policy

Names in ucam.org will usually be handed out first come first served to members and staff of Cambridge University and the Colleges. They will persist while they are still being used, unless the owner requests that they be removed. If a name falls into disuse it may be reused later.

Societies will not usually be allocated society-name.ucam.org; instead, societies will be allocated abbrev.soc.ucam.org. We're aware that there is a lot of collision in society acroynms; they are on a first come first served basis, but it would be nice if people could try to pick likely-to-be-unique abbreviations rather than likely-to-collide acronyms.

We'll usually accede to requests for aliases for systems in cam.ac.uk made by other than the system's owner, but the owner will be informed and we'll remove the alias if they object (or change it if they prefer a different name).

`Meaningful' names

In the unlikely event of some kind of dispute between competing claimants we'll have to make a decision as to who or what is the best group or way to provide the service, so we reserve the right to revoke the allocation of such a meaningful domain name and to allocate subdomains to different people or some such (though we hope never to have to exercise it).

If the activities you'll use the name for are related to the meaning of the name itself then you should let us know, either when you request the name or when you propose to change the use in this way.

CRSID's (Computing Service usernames) and `namespace' uses

We recommend that you do not name your computer(s) after your CRSID. It is a bad idea to give a computer your own name in this way, for a number of reasons. See the advice in FYI5, aka RFC1178, `Choosing a Name for Your Computer'.

You may find it useful to inform us of your use of the CRSID. This will help avoid us accidentally allocating your name to someone else (eg, because we didn't realise that they weren't you), and can also help avoid problems in the rare cases where the Computing Service reissue a CRSID to someone else.

Relationship with the University Computing Service

You should not cause address(es) or name(s) to be registered in any other part of the DNS without previously consulting the Computing Service as such aliases can give a misleading impression about the proper use of the CUDN, JANET and other networks, and can cause confusion leading to the waste of network staff time.

According to a mail to Ian Jackson from Tony Stoneley in January 1998,

As far as I'm concerned, the consultation referred to therein has happened in respect of ucam.org with its current style and purpose.

Note that publishing a name in ucam.org for a service rather than a name in cam.ac.uk doesn't obviate the need for you to comply with the JANET, CUDN and College AUPs.

More complex activities and requirements

Web site aliases

Service names

(A service name is a name that refers to a service rather than to a particular host. Service names are a good idea because they make it much easier to move a service without publishing a new name for it.)

Departure of a ucam.org host from the CUDN

If the new systems are not in the CUDN then this is fine. However:

Normal consumer-level ISP service cannot usually be made to handle providing service under a ucam.org alias. For example, if we were to make www.exemplar.ucam.org an alias for www.exemplar.demon.co.uk then it wouldn't work properly, because Demon's webservers would not know which pages to deliver for www.exemplar.ucam.org when they received the requests. Similar considerations apply for mail and most other internet services.

If you wish continuity of www service, or other services, then you need to get someone to actually host those services. This could be a competent person with a permanently network-connected system who is willing to do you this favour, or a commercial ISP that you've paid the relevant (usually much higher) amount of money. In either case the hosting systems' relevant technical people should contact hostmaster@ucam.org so that the details can be sorted out - either addition of the appropriate DNS RRs to the ucam.org zone, or delegation (but see below).

Delegation

However:

• You must comply with all the CS's requirements if you are going to be using their network. For example, if you wish to run the primary nameserver in the CUDN, or do other things that the CS might object to, you should talk to the CS first.
• For technical reasons, if the domain you wish to be delegated is directly under ucam.org (eg, exemplar.ucam.org instead of experiment.exemplar.ucam.org) then there should be at least three nameservers, one of which is on the CUDN, and all of the nameservers should be reliable. We can arrange for a secondary - contact us for details.
• You must allow outbound zone transfers to all comers.
• You must have at least two nameservers. Three is usually better; we can provide a tertiary server.
• Granting a domain, or delegating a subzone, in ucam.org does not imply that the ucam.org administrators will be willing to host mail relays, virtual web servers and the like, on their systems. If you want these facilities you will have to obtain them separately.

Mail

• The system named in the MX records would have to be willing to handle all the mail for the relevant domains. (The ucam.org administrators are personally in general not willing to do this.)
• An MX record and a CNAME record cannot coexist at the same place in the DNS. That is, a name cannot be both a mail domain and an alias to something that isn't a mail domain.
• At the very least politeness would require us to consult the CS. Things need to be arranged so that the CS aren't exposed to internal details of the arrangements, even when the inevitable problems occur.
• What about enormous mail queues during the holidays ?
• Many of the most obvious solutions in fact involve nontrivial research, programming and/or administration.
• Email addresses in ucam.org would be even more ephemeral than students' CS-issued addresses. Ephemeral email addresses are often a bad thing.
• Someone competent would have to be willing and available to chase up the inevitable incompetents when their mail systems go wrong.

Campaign for a non-browser-specific WWW