Activation of http://ox.ac.uk/ and http://unit.ox.ac.uk/ for web server use

Considerations and guidance on serving web pages from www-less domains

Expand All

In principle, there is no technical reason why a hostname of ox.ac.uk may not exist; indeed, similar DNS records exist for many other domains. However, the introduction of such a hostname may present us with problems in the future, and cause difficulties with the operation of certain non-web services. We have therefore been reluctant to add such records because of the potential implications, which may only become apparent many years hence.

If this sounds far-fetched, remember that for much of the 1990s Email was the dominant protocol, and unit.ox.ac.uk was often used for UNIX log-in systems. Is the University able to predict what will happen in the next ten years? There are sufficient warning signs to make Hostmaster recommend that ox.ac.uk and unit.ox.ac.uk be left alone.

From a technical aspect, the domain name ox.ac.uk is just that, a domain name. It is not specifying any particular service such as Web, Email, or FTP. While in theory a hostname matching the domain name may exist, there is a problem as to what service(s) should be associated with that hostname. Nowadays one would not choose to run multiple services from one host, for reasons of resilience and security amongst others. Therefore when the hostname ox.ac.uk exists there is an implicit acceptance that this is for the use of one service at the exclusion of any other.

The problem was solved for Email many years ago with the addition of a dedicated DNS record type (the MX record), allowing for complex setups for a mail domain with a name matching that of the domain. A more general method does exist for other services in the form of the SRV record, but outside of certain areas (such as MIT Kerberos systems or Windows domains) they are not widely used. Standard practice has instead been to use service-specific hostnames, such as www.ox.ac.uk, ftp.ox.ac.uk, smtp.ox.ac.uk, although in principle, any name can generally be used for the server offering any service.

A handful of legacy DNS records of the form unit.ox.ac.uk do exist, although we have never had an A record for ox.ac.uk itself. Mostly these were originally set up for use with departmental "bastion" hosts, often used as telnet (and later ssh) gateways. These days we would recommend that a name such as login.unit.ox.ac.uk be associated with such systems.

In recent months, we have become aware of potential issues with Microsoft Active Directory which can only be resolved by creating an A record in the DNS for the domain name, to be pointed at one or more of the Active Directory servers, and one has now been added for one unit.

Even though Active Directory makes widespread use of SRV records, it appears that in certain setups they are ignored by clients and an A record for the domain name may be required. At present there is no Active Directory realm named ox.ac.uk but it is possible that one may be required as part of (or an extension of) the Groupware Project. A decision at this stage to support http://ox.ac.uk/ therefore has clear implications regarding the future possibility of such a central Active Directory service (recall that using ox.ac.uk for one service is at the exclusion of all others).

It is possible that in the future, workarounds similar to that used with Active Directory may be required for other protocols. Workarounds for multiple protocols may be mutually incompatible and we are required to choose which, if any, will be implemented. We would much prefer to avoid this situation.

It is also possible that at some stage in the future, http ceases to be the "dominant" protocol in the eyes of the average user and there is a call for an A record to be used for some other purpose. If this seems far-fetched today, consider that originally A records were often used to denote mail servers (prior to the introduction of the MX record), and that in the 90s it was not uncommon for a department to want an A record for its domain name to point to its login gateway.

In the case of unit.ox.ac.uk, we can in principle support an A record for unit.ox.ac.uk for one particular service, with the clear caveat that this may cause them problems with other services in the future. If such problems arise, it is then up to the unit to decide how to proceed.

In the case of the ox.ac.uk domain, multiple teams in different sections of the University are responsible for different services (eg OUCS, ICT support team, UAS, BSP), greatly complicating resolution should any conflict arise.

These should not be considered showstoppers but should not be ignored

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 a 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 sample-email-address@example.ox.ac.uk, 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 the Nexus automatic configuration 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.

Where there is a strong desire or technical need for an A record for unit.ox.ac.uk, the hostmaster team are prepared to add it on the request of the senior IT officer ("itss01") for the unit in question, provided that he or she has been made aware of the above issues and accepts responsibility for any future consequences. Units should bear in mind that with the current DNS interface, they will not be able to make changes to this DNS record themselves but must instead request changes through Hostmaster.

Where an HTTP service is offered for a host unit.ox.ac.uk, all requests should be redirected to www.unit.ox.ac.uk (or the unit's choice of canonical web address). For consistency, the HTTP service should be globally-accessible if it is accessible at all.

An A record for ox.ac.uk itself has implications for several University groups with potentially conflicting interests. While the hostmaster team are prepared to offer technical advice and recommend other persons or groups who should be consulted, they feel that policy decisions should be seen to be made at a more senior level within the University (for instance, by the Director of IT).

 

Related links

Get support

If you cannot find the solution you need here then we have other ways to get IT support

GET IT SUPPORT