Access Keys:
Skip to content (Access Key - 0)

Hostname Migration - Validation ahead of DNS change


Suppose you have an MIT website (perhaps hosted on a managed server), and you have hired a third party provider to host your website somewhere else. You wish to move your MIT hostname to point at your provider's server, and to manage the transition gracefully, so that all website visitors see either the old or the new website. This article describes the steps involved, and how to accomplish this.

Can your hostname be pointed at destination?

Pointing an MIT hostname off of MITnet is usually allowed, provided:

  • A single A or CNAME record is desired
  • The hostname is not a fourth level or wildcard name:
    • Accepted:
    • Fourth level or wildcard: * or
  • The requester can provide a valid MIT cost object to track the record on our systems. No cost is associated, but the cost object insures that someone will take responsibility for hostname going forward.
  • Vanity hostnames (such as are discouraged

However, we won't be able to work with your outsourcing provider if they require that we delegate DNS authority, nor if they have onerous validation procedures. This means that directing MIT DNS at Squarespace sites is difficult and working with some other low-cost providers (where delegated DNS is required) is not available.

Additionally, the hosting provider will need to provide an appropriate web server configuration to recognize that requests for your hostname should get your content. Some hostname requests are not appropriately handled as a DNS configuration - included in these are the situations in which you need to link the MIT hostname to a deep URL within a website that you don't wholly control. See Hostname Migration - Hosted HTTP redirects for more information.

Is your outsourced destination serving a valid web server (SNI) configuration?

Perhaps your technical contact at the destination told you they'd take care of it, or perhaps you used an auto-configuration interface to set this up. In any case, once you think it's configured, but before putting in the DNS request, you will need to test it, by altering your workstation's DNS configuration to imitate the final configuration.

Before proceeding further, you will need the IP address of the outsourced website.

  1. Edit the /etc/hosts file on your workstation (eg., with sudo vi /etc/hosts) and append the IP address (destination) and hostname (desired). For example:

    You may also need to clear your OS's DNS caching mechanism:
    Linux/Unix: nscd
    MacOS: mDNSresponder
    Windows: ipconfig / flushdns
    Refer to OS specific documentation if you need assistance, or test whether you have the desired DNS resolution.

  2. Clear your browser's cached content, then quit and restart your browser (important - most browsers cache DNS information very aggressively)
  3. Visit your desired website

Do you see valid content? Or do you see some kind of landing/configuration page?

Remember to undo the steps above, when you are done - a locally edited /etc/hosts can be horribly confusing if you forget about it.

Is your outsourced destination serving a valid SSL certificate?

Repeat the steps in the previous section, using the https URL for your site. Do you get a certificate mismatch error, or other error?

Note that many website providers fetch a certificate from Let's Encrypt (a free certificate generating service) once your public DNS records are transferred over, so it's very plausible that you will not be able to validate the certificate in advance, but will have to wait for their process to do it. Please consult your provider's documentation.

Planning the cutover

DNS configurations for off-campus destinations are handled manually. You will normally need to schedule a time several days in advance. Who you work with has some dependence on the specific use case.

Note that because DNS is cached, your cutover will not be instant; clients who were using to the old host will keep directing request to the old host, potentially for several days. We normally schedule DNS cutovers during the business day. If your website is accepting uploads of user data, you should plan to make the old host display a maintenance page after the cutover is complete.

Managed Server customers

If you are an existing managed server customer, the Application Delivery team will coordinate making the DNS request. We will also need to remove monitoring, and clean up the configurations on your existing hosting after the transition is complete. Please reach out to

IS&T Internal Projects

If IS&T is outsourcing the configuration, Application Delivery will track and monitor the service via our Opsview monitoring. Again, please reach out to for further assistance.

Moving a hostname from Drupal Cloud elsewhere

The Drupal Cloud/Application Delivery staff will need to verify that you own the Drupal Cloud site in question, and coordinate the transition

Oursource-to-outsource, and transitions that don't involve managed servers

If the moira host record (for the desired MIT hostname) is in your name, or doesn't exist yet, you should coordinate the transition with

You should provide:

  • Whether an A record of CNAME record is wanted, and the appropriate destination
  • The ownership and cost object of the MIT hostname in question
  • What schedule you expect the change to take place on - "please make the change anytime" vs. "please schedule this next Tuesday at 11am, or offer me an alternate date to plan around."

IS&T Contributions

Documentation and information provided by IS&T staff members

Last Modified:

August 29, 2019

Get Help

Request help
from the Help Desk
Report a security incident
to the Security Team
c-managed-hosting c-managed-hosting Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
This product/service is:
Easy to use
Difficult to use

This article is:
Adaptavist Theme Builder (4.2.3) Powered by Atlassian Confluence 3.5.13, the Enterprise Wiki