5. Other potential issues

These should not be considered showstoppers but should not be ignored.

An Inconsistent Experience

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.

Publication Risks

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.

SSL support

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. The solution is to associate each hostname with a different IP address, which allows SSL certificates bearing different names to be used. If a large number of names are supported then it gets expensive in terms of IP space consumption, and complicated and risky for the systems administrators.

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.

Server changes

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.

Up: Contents Previous: 4. What else? Next: 6. Recommendation