Activation of and for Web Server use

1. Executive Summary

In principle, there is no technical reason why a hostname of 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 1990's Email was the dominant protocol, and 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 and be left alone.

2. Background

From a technical aspect, the domain name 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 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,,, although in principle, any name can generally be used for the server offering any service.

A handful of legacy DNS records of the form do exist, although we have never had an A record for 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 be associated with such systems.

4. What else?

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, we can in principle support an A record for 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 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.

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 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 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 rather than 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 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 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 and would require that there still be a single official name for the organisation's home page (eg and any visit to other forms generates an HTTP redirect to the canonical URL. If the 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 is to be supported then we would strongly recommend that it be pointed to the IP address of [sic]. This is a different IP address to and any access already generates an HTTP redirect. Indeed a large number of different names are supported in this way, including,, 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.

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, your email client will potentially attempt a connection to If no valid certificate exists for, 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. 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 is to point to a single host it must go into the DNS as an A record (pointing to an IP address); is currently an alias (for In this case a possible workaround would be to make an alias for if they are to be hosted on the same server IP address.

6. Recommendation

Where there is a strong desire or technical need for an A record for, 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, all requests should be redirected to (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 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).


Written by IT Services. Latest revision 27 November 2015