In March 2004 we moved all three of our servers into a single rack in the 6/7 Harbour Exchange data centre, operated at the time by Redbus.  The data centre has changed hands several times, and merged with the building next door to become what is now Equinix LD8. We’ve been continuously present for 20 years and 1 month. Normally moving out of a data centre is a difficult, expensive and time consuming operation that is best avoided, but Equinix offered us terms that made doing so make sense. In September 2023 we opened our new core point of presence in Telehouse South.

We’re happy to report this project is now complete and our footprint in Equinix LD8 is now reduced to an optical-only point of presence forwarding 10Gbps waves to our core site at City Lifeline.

Our new space in Telehouse South offers a considerable upgrade over what we could offer in LD8. All servers now have remotely switchable dual power feeds and with dual 10Gbps uplinks. We are able to offer offer cross-connects to anywhere in the Telehouse London campus and 10Gbps wavelengths back to our other sites. We already have some new colocation customers taking advantage of these additional services. We still include serial for out-of-band server management.

During this move, we live migrated our virtual server cloud to hosts in either City Lifeline or Sovereign House. Apart from a few special cases supporting very old virtual servers or ones with BGP transit services, this was done without interruption to the client. Dedicated servers and colocation customers moved in a series of windows to minimise downtime while the servers were relocated.

We brought on additional network capacity as part of the move including 10Gbps and 100Gbps links to transit providers and private peers within the Telehouse London campus. This provides a significant upgrade in connected external capacity.

It’s a popular meme that all mysterious internet problems are caused by issues with the Domain Name System (DNS). Like most memes, it gets over-used, but when it comes to transferring a domain between providers, the intricacies of DNS create some very real problems.

To make things easier, we’ve just rolled out a new feature to our DNS management system that allows you to fetch records from your old provider’s nameservers prior to transferring the DNS for your domain to us.

Why is this needed?

This functionality can help achieve a seamless transfer of your hosting, by working around an annoying feature of the DNS system.

DNS is the system that converts internet names (like “www.mythic-beasts.com”) into IP addresses (like “93.93.129.174”) that can be used to locate the server for a particular service. This conversion is done by nameservers, and each domain has its own nameservers, usually provided by your hosting provider.

When you transfer the hosting for your domain between providers, you’ll need to update your DNS records to point at your new web and email servers, but you will also typically change from using your old provider’s nameservers to your new provider’s.

The simple way to transfer your domain is to do these two things in one go.  Your old provider’s nameservers direct traffic for your domain at your old web and email servers, your new provider’s nameservers direct traffic at your new hosting service, so just change the nameservers for your domain from your old provider’s to your new provider’s and you’re done, right?

This approach works, but it’s not ideal for domains that are in active use because of the delays created by caching.

Caching and TTL

One of the things that makes DNS so confusing is caching. When you look up a name, you’re told to remember the answer for a set period of time. IP addresses don’t change very often, so looking up a name every single time you need it would generate a lot of unnecessary traffic, and slow things down.

All DNS records have a “Time To Live” (“TTL”). This is the number of seconds that you’re allowed to remember it for before you have to do a new lookup to see if it’s changed. In the past, TTLs were usually set to hours, days or even a week. As the Internet has become faster, the overhead of DNS lookups has become less of a problem, and TTLs of one hour or a few minutes are now common.

Although caching helps improve performance in normal use, it creates a problem when you need to make changes. When you make a change to the DNS records for your domain, it won’t be picked up immediately by all users, because some people will have the old value cached.

If you know you’re going to need to change a DNS record, you can lower the TTL in advance (for example to 60 seconds), and then, when you come to change the record, all users will pick up the change very quickly.

If you’re planning to change hosting provider, it makes sense to lower the TTL on your DNS records in advance, so that when you come to make the change, all traffic is switched from the old provider to the new provider quickly.

Changing nameservers

When you have your own domain, you need to have some nameservers to answer DNS queries. As described above, when you transfer the hosting for your domain, you will typically also switch from using your old provider’s nameservers to your new provider’s.

The domain name system keeps a record of which nameservers provide the DNS for each domain. For example, DNS for mythic-beasts.com is provided by our nameservers (ns1.mythic-beasts.com and ns2.mythic-beasts.com). The problem is that these records are also subject to caching and usually have a fixed TTL of 48 hours.

This means that even if you set a low TTL for your own records, when you change the nameservers for a domain, you have a two day period when queries for your domain might still end up at your old nameservers. If your old and new servers are serving different records, users will get a mix of different answers.

The trick to achieving a clean switch between hosting providers is to separate the move from your old provider’s nameservers to your new provider’s from changing the individual DNS records that control who provides your web and email hosting. In other words, get the old and new nameservers serving exactly the same records, so that during the 48 hour nameserver changeover period, it doesn’t matter which nameserver answers the query. Once that changeover is complete, you can switch your web and email hosting by updating low-TTL records.

Our new fetch live records feature makes it easier to copy the records from your old provider’s nameservers to ours, so that you can do a seamless nameserver handover before migrating your web and email hosting. Unfortunately, this tool can only check for commonly used records because there’s no reliable way to get a complete list. The best solution is to get an export of your current DNS records from your current provider, and use our import function, but many providers don’t have an export feature in their systems.

This stuff is hard – we’re here to help

Domain transfers, and DNS in general, are difficult and confusing. For many of our customers, changing providers is a once-per-decade thing, whereas we deal with domain transfers every single day.

We’re working hard to build tools that make the process easier, but our support team is always on hand to provide personalised help.

Mythic Beasts is now a verified Green Hosting Provider according to the Green Web Foundation.

We’ve demonstrated to the Green Web Foundation that all our UK and EU data centres buy as much renewable electricity as they use. This hasn’t changed our operations; internally we met this requirement in 2018. What’s changed is that we’ve now provided all the documentation to meet the certification standards of the Green Web Foundation.

Of course this isn’t quite the same as saying that all the electricity we use comes from renewable power. Ultimately, the electrical energy from a wind farm isn’t tagged to flow directly to the data centres we use and there is also no requirement that the electricity is bought at exactly the same time it is used. Similarly, the data centres have fossil-fueled generator backup which means small amounts of fossil energy are still used.

That said, we do believe that this is an important and useful step in the right direction. By getting verified under this scheme we, and the 429 other verified companies, apply pressure on the data centre suppliers to buy and use renewable energy which strongly encourages the marketplace to build more renewable generation.

Some of our data centre providers are very large well-resourced companies and they place very large long term orders for renewable power. This means renewable power providers can secure funding to build out renewable power generation. When they want to build a data centre, they also have to fund the building of an equivalent amount of renewable generation to power it.

Yesterday, the following not-so-subtle notice appeared on the admin interface of all Mastodon instances:

The Mastodon team announced on Monday that this release was coming, so we were ready for it:

Details of the vulnerability are still limited, but from what we do know it sounds serious (“Remote account takeover“).

All our managed Mastodon instances were safely patched just over an hour after the new packages dropped. One instance gave us a bit of trouble, as the new version appeared to tickle a bug in Elasticsearch causing ES to consume all CPU on the server. After we eventually pinned down the cause, it was resolved by an upgrade of Elasticsearch. Turns out the ES upgrade didn’t fix it, and we’re still working with our customer to get this resolved.

Managed open source hosting

Open source software such as Mastodon, GitLab and Nextcloud can offer a great alternative to the lock-in associated with proprietary cloud equivalents, but the effort associated with hosting them can be significant: backups, monitoring, security patching, and the investigation and debugging required when a supposedly innocuous software upgrade leaves your CPU usage wedged at 100%.

Our managed open source hosting provides the best of both worlds: the convenience of a “cloud” solution, but without the lock-in. Your data is yours, and if you don’t like our service you can take your data and host it somewhere else (although we’re confident you won’t want to). And because there’s no lock-in, you get straightforward pricing based on the resources you’re using, rather than loss-leaders followed by price hikes once you’re hooked.

Read more about our managed hosting, or drop us an email at for more information.

Recently Trend Micro, through their Zero Day Initiative, published a critical flaw for the Exim mail server. It’s described as allowing remote attackers to execute arbitrary code on the Exim server without authentication. On the face of it, any server running Exim and listening on the internet can immediately be taken over by an attacker. What makes this worse is that they claim they reported this in June 2022, and the Exim team have ignored fixing it.

ZDI say ‘The only salient mitigation strategy is to restrict interaction with the application.’ and have allocated a scarily high severity score of 9.8/10.

Mythic Beasts make pretty heavy use of Exim in our mail infrastructure, and mitigating the security risk by turning off email is a pretty severe step while we wait for a fix. On top of that amongst servers we manage for ourselves and clients there’s nearly a thousand installed copies of Exim that will need to be updated.

The Exim team have a different view on the severity, as do other reputable security specialists. Watchtowr have a nice write-up explaining that, by default, none of the six issues can be exploited. Cross checking to Mythic Beasts mail infrastructure we can quickly confirm we’re not affected, and we believe that none of the managed customers should be either.

As this is now not especially time critical, we can wait for the supported operating systems to release updated packages which we can install.

Patching

The security issue is definitely significant enough to meet our 0-day policy of patching immediately as it’s network listening software with a risk of compromise. Debian released packages with the most important fixes on Monday 2nd October. Because this issue covers a very large number of affected machines, some of which are absolutely critical we decided to stage the rollout. First we did our staging servers, then one of our core mailhubs. We then paused for a short while to check no functionality was affected. Then we completed the full roll-out to all managed servers both customer and internal. The final step is our audit – recheck the Exim package on every managed server to make sure the update had applied everywhere. The full rollout and audit completed in around three hours.

We’re expecting updated packages from Ubuntu shortly, which will then be rolled out to all supported managed Ubuntu customers when available.

Last year, we undertook a significant data centre migration, with the closure of Digital Realty’s Meridian Gate requiring us to move our entire presence there to Redcentric’s City Life Line. Having done it once, why not do it again?

This year, we’re planning a move out of Harbour Exchange (HEX), and starting a presence in Telehouse South. A lot of the things we learned during the previous move are making this move easier to manage, although it is still a prodigious effort, both physically and in terms of design and infrastructure.

One of the things we’ve been working on for some time is improved network infrastructure within our data centres. This introduces IP address portability so that IP addresses do not need to change when servers are moved between data centres, as well as significantly higher bandwidth uplinks for our virtual server hosts.

In the last year, we’ve live migrated over a thousand VMs across two data centres, with minimal interruption to service.

We’re about to start migrating all VMs out of our HEX data centre. We have two available London destinations, SOV and CLL. If you’re a customer with a VM in our HEX data centre, we’ll be emailing you over the next couple of weeks, to check if you have a preference (for instance because you have existing services in one of those data centres, and would prefer to be moved to the other to maintain fault-tolerance).

We will also soon be able to offer Telehouse South as a virtual server zone, in addition to SOV and CLL. This means we will continue to provide three London-based zones for our customers running distributed services. We’ll retain a small residual presence in HEX for connectivity.

 

Last year we enhanced our web hosting service with the ability to choose your own PHP verison. You can choose a different PHP version for each website hosted with us, so you can upgrade your staging site and test before you upgrade the production one. With PHP 8.0 about to go end-of-life, the addition of PHP 8.2 provides more options for migrating production applications.

Since the initial roll-out, we’ve added more PHP versions to help with moving and upgrading older applications. Not only is the newest version PHP 8.2 available, but you can also select the older 7.3 and 7.4 versions. We’re proud to sponsor Ondřej Surý who creates the debian packages we rely on.

Our hosting accounts still support unlimited websites, have free and automatic SSL through Let’s Encrypt to keep your sites secure, and include MariaDB databases.

We’ve just rolled out a price reduction for domain registration for the vast majority of the TLDs that we offer, including .com, .net and .org. We pay for most of our domains in US dollars, and thanks to the increasing strength of the pound against the dollar, we’ve been able to reduce our prices for all such domains by an average of just over 10%.

.ie domains

We’re also pleased to announce that we’re now able to offer .ie domain registrations. Unfortunately, ID requirements mean that we’re only able to offer these to corporate registrants, and standard .ie residency requirements apply. .ie domains have been a frustrating gap in our available TLDs for many years, so we’re very happy that we’re now at least partially able to fill it.

No-nonsense pricing

Our full price list can be found on our domains page.

We don’t offer loss-leading promotional pricing — we charge the same for new and existing customers alike, don’t ramp up pricing on renewals, and never charge transfer-out fees.

We offer small multi-year discounts for registration or renewals in advance, and pride ourselves on offering a good service for a reasonable price.

Other domains

We’re also a JISC registrar, meaning that we can provide .ac.uk and .gov.uk domains. We can provide credit accounts (subject to checks), allowing organisations to pay for domains via PO and invoice, if required.

DNS, APIs, DNSSEC, IPv6

Domain registrations include DNS with API access as standard. We also support DNSSEC, and naturally, our nameservers are IPv6-enabled. If you’re migrating existing domains to us, you can import zone files directly, via our control panel or the API. We also provide a Domain management API.

 

On Saturday the Debian team released the latest version of Debian, Bookworm. We’re pleased to announce that this is now available on our virtual and dedicated servers.

Bookworm is a fully supported operating system for our managed hosting and we already have it running on some of our internal production servers. Our preferred open source server management system, Sympl, has also been updated to support Bookworm. Other feature enhancements include much more control over PHP versions and settings. Our virtual server cloud has pre-built images for standard Bookworm and Bookworm with Sympl pre-installed.

There are many improvements in Bookworm, with PHP 8.2 support being the most anticipated by our customers. We would like to thank the Debian team for all their hard work in making this release.

We’ve been offering IPv6-only hosting for eight years now, and have demonstrated that many websites can forego the expense of an IPv4 address pretty easily. You can read more about how we do this on this blog post from 2020. This blog post itself is being served from an IPv6-only server!

A key part of this is our IPv4-to-IPv6 proxy. This listens for incoming traffic on a shared IPv4 address and forwards it to your IPv6-only server. In order to use the proxy, you need to tell it which hostnames to listen for, and which server or servers to forward traffic to. This can be done using our control panel, and as of today, it can also be done via an API.

Having an API for proxy configuration makes it possible to automatically add or remove backend servers, allowing you to spin up additional servers, or take servers out of service for failover or maintenance.

You can also use the API to add and remove hostnames handled by the proxy, and so can be used to automate the provisioning of new services.

Fine-grained access controls

As for our DNS API and Domain API, the Proxy API provides fine-grained access control for API keys. For example, you can create an API key that only has access to a specified domain or hostname, or you can create a read-only API key if you only need to read the current configuration.

Getting started

Our IPv4-to-IPv6 proxy is available to all customers with a Mythic Beasts server, including virtual servers, Raspberry Pi servers, dedicated and colo. You can find more information on the proxy service, and the Proxy API on our support pages.