View on GitHub

Custom domains


As part of our web hosting, we provide free domains for both individuals (of the form <crsid> and group accounts (<groupname> These are configured as standard, and will serve any web content placed in the public_html directory of the respective personal or group account (subject to a 20-minute delay when publishing a new website).

We also support external domains purchased from a domain registrar. If you are looking to buy a domain for yourself or your society then we can recommend Mythic Beasts but there are plenty of other registrars out there with varied pricing.

You’ll need to make sure the domain resolves to us – this is controlled by DNS records, which your registrar should allow you to configure. If you’ve delegated DNS from your registrar to a third-party service such as Cloudflare, you’ll need to configure it there.

Assuming you want to serve your site from the base domain, your DNS records should look something like the following:

  Subdomain   Type    Value
  ----------- ------- ------------------------------------
  @           A
  @           AAAA    2001:630:212:700:2::1
  www         CNAME

The first record (A) makes your base domain point to our webserver’s IPv4 address; the second (AAAA) does the same but for IPv6. The third (CNAME) sets an alias from to our webserver.

If instead you want to use the subdomain

  Subdomain     Type    Value
  ------------- ------- ------------------------------------
  bubbles       CNAME
  www.bubbles   CNAME

More information

The preferred method is a CNAME record, which acts as an alias from your domain to ours. The value of this record should be – this means your domain will continue to work even if we move servers, as our hostname will stay the same. Note that you must remove any other non-CNAME records for this particular (sub)domain.

CNAMEs should not be used on base domains (, sometimes called the zone apex), only on subdomains. The alternative is to use A (for IPv4) and AAAA (IPv6) records to specify an IP address. The A record should be set to, whilst AAAA should be 2001:630:212:700:2::1. Make sure to remove all other A/AAAA records for that domain, otherwise browsers and other software may arbitrarily choose between our web server and whatever else is configured.

You can confirm if the domain is resolving to us correctly by visiting it in your browser – you should be greeted with a ‘non-existent site’ page on our site. Once this is visible to you, use the SRCF control panel to assign the domain to your (group) account.

Document roots and multiple websites

You may wish to run more than one website under a single account. This can be done if you have your own domain, by delegating different (sub)domains to different sites.

<crsid> and <groupname> domains are fixed at serving the root of your public_html directory. When adding custom domains to your account, you can optionally set a Document root – this is a subdirectory of public_html which acts as the root of your domain.

For example, you may wish to serve from /societies/<groupname>/public_html, and from /societies/<groupname>/public_html/bubbles. This means that /societies/<groupname>/public_html/bubbles/index.html would be served as the index page of


HTTPS provides secure communication between our servers and your website visitors, and is recommended for any site that handles personal information or provides password authentication. In comparison, HTTP transmits in plain text, and is susceptible to eavesdropping over an untrusted network (such as public wi-fi or other shared networks).

Websites served from and addresses come with working HTTPS by default, but custom domains must be opted-in manually. This can be done using the Let’s Encrypt form. Requests will be queued, and processed together at the end of each day.

Note that your domains need to be actively resolving to us in order to have certificates issued – if not, they will be dropped from the queue. The resulting certificate we’ll serve will list each of your domains as a Subject Alternative Name (SAN). Once opted in, no further action is required – certificates will automatically be renewed close to their expiry.

Websites that are not opted-in will not be served over HTTPS, so will only respond to plain HTTP. Requests for an HTTPS version will show a ‘non-existent site’ page.

Note that we only handle serving your website over HTTPS, and will still accept HTTP connections. If your site uses a CMS that stores a canonical domain, you’ll need to update that to use HTTPS if desired. You can also use a .htaccess file to require secure connections, and redirect plain HTTP.

What about email?

The SRCF cannot process mail for your domain – we are prevented from doing so by the university. This means you must not point MX records at SRCF machines, as any mail sent there will be dropped before it enters the CUDN.

You should check what services your domain registrar provides, which may include forwarding addresses (so that mail sent to is redirected to a mailbox elsewhere) or real mailboxes (so that you connect to your registrar’s mail server to read mail).

Last modified on Thursday May 6, 2021 by Matias Silva