One unit already has an A record for its unit.ox.ac.uk name, which points to their Active Directory domain controller because of the problems mentioned above. Unfortunately, the implementation results in worse behaviour for any web user attempting to use the site without the "www." prefix. A URL of the form http://unit.ox.ac.uk/ reaches an "Under construction" page from within the University network, but owing to the lack of a port 80 exemption at the University firewall for the IP address in question, attempts to access it from outside the University network merely timeout, with the danger that the user will consider the site to be down. This is clearly suboptimal behaviour for any user trying http://unit.ox.ac.uk/ rather than http://www.unit.ox.ac.uk/. Running no web service at all is little better, especially if firewall configuration still results in a long wait for a timeout to be reached rather than an instant reject.
In general the webserver for a domain will be using a different IP address to the domain controller(s). Pointing an A record for the domain name at both will likely break both web and domain controller functionality. The other option would be to run a simple webserver on the domain controller(s), which does nothing but issue an http redirect to the actual webserver (the unit domain controller in question would be better issuing a redirect to http://www.unit.ox.ac.uk/). Running any additional software on the domain controller is suboptimal, particularly from a security point of view. Separation could be achieved through redirection of port 80 traffic destined to the domain controller IP address, but this adds additional complexity and significant security risk.
In short, enabling the unit.ox.ac.uk hostname has in general solved one "problem" only to create further annoyances and inconsistent experiences for users. This is almost less desirable than the original situation of not having the convenience of the domain name as a hostname for the web service.
If multiple names are supported for a site (i.e. with and without www), then it is very likely they will all be linked or bookmarked to. It is quite common for members of departments to publish URLs without first checking that they exist, or are acceptable to the University's naming policies. Offering www.ox.ac.uk and ox.ac.uk would require that there still be a single official name for the organisation's home page (eg http://www.ox.ac.uk/) and any visit to other forms generates an HTTP redirect to the canonical URL. If the ox.ac.uk address is ever published in paper (and this is highly likely, if it works), there will almost certainly be strong demands not to remove support for it ever, even if we encounter such difficulties as described with Active Directory, above.
If http://ox.ac.uk/ is to be supported then we would strongly recommend that it be pointed to the IP address of www.oxford.ox.ac.uk[sic]. This is a different IP address to www.ox.ac.uk and any access already generates an HTTP redirect. Indeed a large number of different names are supported in this way, including www.oxford.ac.uk, www.oxforduniversity.com, www.oxuni.org.uk and many others.
Having multiple forms of the name for a site is fine for plain http but causes problems with SSL certificates if the site is available over https. Anyone using a name other than that defined in the SSL certificate is liable to get a certificate warning in their browser; indeed in some recent browsers such as Firefox 3, overriding the warning is deliberately made difficult.
Some email clients will, given the existence of an A record for your domain, try to connect to the domain part of the mail. For example if you have an email address firstname.lastname@example.org, your email client will potentially attempt a connection to example.ox.ac.uk. If no valid certificate exists for example.ox.ac.uk, then a warning will be presented to the user. Outlook 2016 is an example of a client that exhibits this behaviour as well as other clients that attempt connections via Nexus's autoconfigure feature.
www.ox.ac.uk does not currently support SSL access but this may not be the case forever, particularly if there is a desire to restrict access to parts of the site via user log-in, which would have to be done over SSL.
It is not uncommon for systems to change IP address, or for the target of a DNS alias to be changed. Unfortunately where multiple names are in use, it is not uncommon for IT staff to forget that all records must be changed. It can be some time before they realise that some users can no longer access the site using existing links or bookmarks.
DNS aliases (CNAME records) can reduce the likelihood of this problem, but a CNAME record cannot exist for any name which already exists as certain other types of DNS record, such as an MX (for a domain used for email). If ox.ac.uk is to point to a single host it must go into the DNS as an A record (pointing to an IP address); www.ox.ac.uk is currently an alias (for torchbox.oucs.ox.ac.uk). In this case a possible workaround would be to make www.ox.ac.uk an alias for ox.ac.uk if they are to be hosted on the same server IP address.