We were asked on Twitter to add a page describing exactly how to get 10/10 on our IPv6 domain readiness checker, so here it is.

1. Add an IPv6 address to your web server

The first step is to get your web server listening on an IPv6 address, as well as an IPv4 address. How you achieve this will depend on how your web server is managed. If you’re on a shared hosting account, you’ll be dependent on your hosting provider. If you run your own server, you’ll need to obtain an IPv6 address from your hosting provider (assuming they support IPv6), configure your server to use it and then ensure that your web server (e.g. Apache is listening on this address).

If you’re using a standard Mythic Beasts hosting account, this step is already done for you. If you’re using a sphinx shell account, please contact support.

2. Add an AAAA record for your website

AAAA records are the IPv6 equivalent of A records, which resolve hostnames to IP addresses.  In order for users to find your website over IPv6, you will need to add an AAAA record for www.yourdomain.com pointing to the IPv6 address configured above.  You can check that this is in place using the dig command:

$ dig +short A www.mythic-beasts.com
93.93.131.39

$ dig +short AAAA www.mythic-beasts.com
2a00:1098:0:86:1000::15

It’s possible that your existing “www” record will be a CNAME for another hostname, in which case you should add the AAAA record to that hostname, rather than the “www” record.

If you’re using a Mythic Beasts hosting account, then provided that you are using the standard template for your account in the DNS configuration for your domain, then this step will already be done for you.

Our health checker will skip this test if your domain doesn’t have an A record for “www”.

3. Add an AAAA record for your bare domain

Most websites are configured to work if the user omits the “www” prefix from the name, for example https://mythic-beasts.com

In order for this to work, you will need an A record for your domain name itself, and to be IPv6-enabled, you’ll also need a corresponding AAAA record.

Once again, our checker will skip this test if the bare domain doesn’t have an A record.

4. Ensure your DNS servers have IPv6 addresses

The steps above make it possible to access your website over IPv6, but unless your DNS servers are accessible over IPv6, users (or more specifically, their DNS resolvers) will still need to use IPv4 in order to find your site in the first place. To avoid this, you need to ensure that your nameservers have IPv6 addresses.

You can find the nameservers for your domain using “whois”, and you can check whether the servers have IPv6 addresses using dig, as before:

$ whois mythic-beasts.com
[ ... ]
Name Server: NS0.BEASTS.ORG
Name Server: NS3.MYTHIC-BEASTS.COM
Name Server: NS2.MYTHIC-BEASTS.COM
Name Server: NS0.MYTHIC-BEASTS.COM
Name Server: NS1.MYTHIC-BEASTS.COM
[ ... ]
$ dig +short AAAA ns1.mythic-beasts.com
2600:3c00::f03c:91ff:fe96:beac

If your nameservers do not have IPv6 addresses, then unless you run your own nameservers, you’ll either need to persuade your hosting provider to enable IPv6, or switch your DNS provider to a different provider.

Mythic Beasts customers should be using ns1 and ns2.mythic-beasts.com, and both of these nameservers have IPv6 addresses, and IPv6 glue (see below).

For a full pass, our health checker requires that at least two of your servers have IPv6 addresses.

5. Add IPv6 glue for your nameservers, if necessary

In order to find the address for your website, a DNS resolver will first need to find the address of your nameservers. If your nameservers are in your own domain, this creates a bootstrapping problem. For example, in order to find the address for ns1.mythic-beasts.com, you need to ask the nameservers for mythic-beasts.com, which includes ns1.mythic-beasts.com. The solution to this is a glue record, a record containing the address of your nameserver which is held by the nameserver for the next zone up. In this case, the next zone up is .com, so the .com nameservers would contain glue records for the ns*.mythic-beasts.com nameservers.

If a nameserver has an IPv6 address, then any glue records for it should also contain that IPv6 address.

Checking for glue records is a little bit involved. The quickest way to do it is to use “dig +trace” to find a nameserver for the next zone up:

$ dig +trace ns1.mythic-beasts.com
[...]
com.      172800  IN  NS  a.gtld-servers.net.
com.      172800  IN  NS  b.gtld-servers.net.
com.      172800  IN  NS  c.gtld-servers.net.
[...]

We can now ask any of those servers for the NS records for our domain. Any glue records that exist will be returned in the “additional” section of the response:

$ $ dig NS mythic-beasts.com @a.gtld-servers.net.
[...]
;; ADDITIONAL SECTION:
ns1.mythic-beasts.com.  172800  IN  AAAA  2600:3c00::f03c:91ff:fe96:beac
ns1.mythic-beasts.com.  172800  IN  A 69.56.173.190
ns2.mythic-beasts.com.  172800  IN  AAAA  2a00:1098:0:80:1000::10
ns2.mythic-beasts.com.  172800  IN  A 93.93.128.67
[...]

If your servers are missing glue records, you will need to get your domain registrar to add them.

It’s worth noting that even if you don’t directly require glue because your nameservers are in a different zone, at some point along the chain there will be a nameserver that does require glue.

For a full pass, our glue checker requires at least two nameservers to be discoverable by a single-stack IPv6 resolver at every step of the chain of delegation.

6. Add IPv6 addresses for your incoming mail servers

In order to receive mail over IPv6, at least some of the mail servers listed in the MX records for your domain must have IPv6 addresses. You can find the mail servers for your domain using dig:

$ dig +short MX mythic-beasts.com
10 mx1.mythic-beasts.com.
10 mx2.mythic-beasts.com.

You can then check that these servers have IPv6 address by using dig to resolve an AAAA record, as before.

Once again, if you’re using a Mythic Beasts hosting account using the standard DNS template for your account type, this will be done for you.

In order to pass this test, at least one of the servers listed in your MX records must have an IPv6 address.

7. Add reverse DNS for your mail servers’ IPv6 address

It is generally advisable to have working reverse DNS for any addresses from which you send outgoing mail. In the case of IPv6, this becomes pretty much essential, as one of the biggest mail providers in the world, Google, will reject mail over IPv6 unless the sending server has working reverse DNS for its IPv6 address.

Unless you run your own mail servers, adding support for IPv6 will be down to your mail provider.

Unfortunately, there is no reliable way to obtain the outgoing mail servers that are used for a particular domain, so instead our health check makes a bold assumption that your outgoing servers are the same as the incoming servers listed in your MX records, and checks those. This assumption is certainly not true of all domains, which is why a failure of this test is only treated as a warning.

8. Check your SPF records

SPF (Sender Policy Framework) is a mechanism for publicly listing your outgoing mail servers, so that receivers can detect spoofed email sent from other servers. If you enable your outgoing mail servers to start sending mail over IPv6, and you have an existing SPF record, it is important that you make sure that it includes the IPv6 addresses for your mailservers.

There are various ways of doing this. If your incoming and outgoing mail servers are the same, then you can use the “mx” mechanism in your SPF record. This means that any hosts listed in the MX records for your domains will be regarded as a legitimate source of mail for your domain, and this will automatically include any IPv6 addresses (assuming you’ve done step 6).

If you list IPv4 addresses or address ranges in your SPF record explicitly, then you will need to add corresponding IPv6 addresses for those servers.

The rules applied by our health checker aren’t entirely trivial, as it’s not uncommon for legitimate third party servers to be included in a domain’s SPF record, and there’s no way of pairing up IPv6 addresses with their IPv4 counter parts. Our health checker applies some very broad rules: if you use the “mx” mechanism, then the checker requires at least one IPv6 address for a server listed in the relevant MX records. If there are any explicit “ip4” addresses or ranges specified in the record, then the health checker expects to find at least one explicit “ip6” mechanism.

If your domain does not list an SPF record then this test will pass automatically, as this effectively defaults to “accept from all”.

These rules aren’t watertight, but have proven to be quite effective in identifying mail sources that either haven’t been enabled by IPv6, or which have but haven’t been added to the SPF record.

Feedback

Hopefully this gives some insight into exactly what our domain tester is looking for, and how to comply with it. Customers who are having trouble getting 10/10 should email support. We’re also always very happy to hear any feedback on the health check, particularly suggestions for additional tests that we should be running.

We’ve just given our IPv6 Health Check a significant overhaul.

IPv6 is coming, and there’s a lot more to being ready for it than adding an AAAA record and enabling IPv6 on your web server. Google are often cited as an example of an IPv6-enabled website, but the truth is, in an IPv6-only world, nobody would ever find Google because none of their nameservers have IPv6 addresses:

Our IPv6 Health Check aims to reach the parts that other testers don’t reach to find out if your domain is really ready for IPv6.  Do your mail servers have IPv6 addresses?  Do they have reverse DNS for those addresses?  Do your SPF records include IPv6 addresses?

The latest version of our health check includes an experimental IPv6 nameserver delegation and glue test that checks that all nameservers the delegation chain between the root DNS servers and your zone have IPv6 addresses, and sufficient glue to allow you to find them in an IPv6-only world. This test has already uncovered some interesting anomalies which we’ll dig into further in a future post.

Although SSL for websites (HTTPS) has been commonplace for e-commerce sites for years, the vast majority of “ordinary” websites still use standard HTTP. In recent months, two things have happened which look set to change that:

• Firstly, on 8th April 2014 Microsoft finally ended support for Windows XP; and
• Secondly, two days ago, Google announced that HTTPS support would be seen as a positive signal when ranking websites in search results.

Whilst the importance of the second of these probably needs no further explanation, the relevance of the first may not be obvious.

Until now, one of the barriers to widespread adoption of SSL over HTTP is that, unlike non-SSL websites, each site requires its own IP address, and IP (or at least, IPv4) addresses are in short supply. This is because the HTTP request which specifies which website is being requested is only done after the SSL certificate has been presented, so if you have multiple sites on a single IP address, there is no way for the server to know which certificate to present.

A solution to this problem has existed for some years in the form of Server Name Indication (SNI). SNI is an extension to the SSL protocol, or more accurately its successor, the TLS protocol, which allows the site name to be included as part of the TLS negotiation so that the server can present the correct certificate.

Unfortunately, one widely-used platform had no support for SNI: Windows XP. With the ending of support for Windows XP, adopting SNI suddenly becomes a much more acceptable proposition.

Cheaper HTTPS hosting

The practical benefit of this is that hosting providers such as ourselves can offer much cheaper hosting of HTTPS sites, and that’s exactly what we’re doing. Buy one of our SSL Certificates and we’ll add an SNI-based HTTPS service to your Hosting Account at no extra charge.

We’ve just rolled out a number of improvements to our server monitoring service. This service allows customers to receive SMS, email and prowl alerts about individual services.

Shared monitors for managed servers

Firstly, customers of our managed hosting service can now get access to the monitors that we have in place for your services through our control panel. Not only does this allow you to immediately check that we’re monitoring the right things, but you can add yourself to the alert list and be notified directly at the same time that we receive an alert.

We’ll be rolling this out to existing managed hosting customers in due course, but drop us an email if you’d like to be enabled quickly.

Satellite monitoring nodes

Secondly, we can now deploy “satellite” monitoring nodes, allowing us to deploy a monitoring server behind your firewall that can report status back to our central monitoring system. This makes it possible to monitor machines and services that are only accessible from behind your firewall.

New monitor types

Thirdly, we’ve added some new monitor types:

• DNS Black list monitoring – get an immediate alert if your mail server ends up on a black list
• HTTP Status Code – check that a URL is returning a specific HTTP code
• TCP connection – check that a server is accept TCP connections on an arbitrary port

More flexible alert lists

Finally, we’ve made alert lists more flexible, allowing you to add multiple groups of contacts to each monitor.

All of our servers come with free ping monitoring included. Enhanced monitoring of individual services can be added for just £5+VAT per month, and is included for managed hosting customers.

It is now possible to register domains directly within .uk, and not just under second level domains such as .co.uk, .org.uk and .me.uk.

Holders of existing .co.uk domains (or .org.uk if the .co.uk is not registered) are given the right to register the corresponding .uk domain. For example, if we owned example.co.uk, we would be automatically entitled to register example.uk.

If you already hold a .co.uk or .org.uk domain, either with us or with another registrar, and would like to register the corresponding .uk domain with us, then please contact support. Tell us the domain or domains you want to register, and for how long (up to 10 years) and we’ll do the rest!

If there is no existing .co.uk, org.uk, etc. domain which corresponds to the .uk that you want, then you can go ahead and register the domain with us in the normal way.

The new domains cost the same as the other domains within .uk: £6.50 for 1 year, £9 for 2 years, £21.50 for 5 years, or £39 for 10 years (prices include VAT). They come with all the standard benefits of Mythic Beasts domain registrations: DNS hosting including IPv6, SPF and TXT records, DNS API and Dynamic DNS.

It’s a Wednesday, which means more new top-level domains! This week’s new gTLDs are .camp, .education, .glass, .institute and .repair.

To celebrate all the domain name possibilities, we’re running a one week promotion on new registrations for all new gTLDs launched so far this year, with 33% off one year registrations, and discounts on longer registration periods too.

A full list of discounted domains is available on our Domains page.

The promotion will end at midnight on 9th April, so you can get next week’s new domains at the reduced price if you’re quick.

We’re pleased to announce that we now support Direct Debits as a payment
method. By setting up a Direct Debit, payment for any invoices on your account
will automatically be taken from your bank account a few days after the invoice
is issued.

To set up a Direct Debit on your account, click here and log in with your account details.

The addition of Direct Debits also allows us to support another new feature:
automatic renewal of domain registrations. If you select this option, your
domains will automatically be renewed for one year 21 days before expiry, and charged
automatically to your Direct Debit.

You can configure the renewal behaviour of your domains using the Services tab on our control panel.

Some months ago we announced that we were planning an even cheaper version of our entry-level VPS Lite virtual servers.

It took a little longer than planned, but we’re now pleased to announce the launch of our IPv6-only VPS Lite, for the ludicrously low price of £5+VAT/month (or even less if you pay annually). This virtual server comes with 4 billion IPv6 addresses, but no IPv4 connectivity.

The world is running out of IPv4 addresses, and whilst we’ve got an allocation that isn’t going to run out any time soon, issuing an IPv4 address with every server we sell will ultimately be a barrier to our growth. If you’re happy to have a server without an IPv4 address, we’re happy to give you a discount, and that’s exactly what we’ve done with our IPv6-only VPS Lite.

IPv6 usage is currently running at about 3% and doubling roughly annually, so now is a great time to get familiar with IPv6.

Whilst these servers probably aren’t suitable for fronting a website just yet, we’ve already got a number of customers who run IPv6-only backend networks, with everything behind their load balancers on single-stack IPv6.

Although these Virtual Servers themselves don’t have IPv4 connectivity, the host server does, which means that you can get to the admin console, virtual serial console and VNC over an IPv4 connection.

If you’re a technology professional and have no idea what any of this means, we suggest you start your training by placing an order here.

Given just how much of our lives involves using apps, websites or embedded computers, you might think that an initiative to teach children the basics of how to create software and not just how to use it would be uncontroversial.

Well, that’s the stated goal of Year of Code, and whilst you might be able to find fault with its execution, that’s not the angle that Jeremy Paxman chose to take when interviewing Year of Code’s director, Lottie Dexter, on Newsnight last week. Instead, Paxman decided to ridicule the very notion using the curious argument that because he couldn’t understand some computer code, it was therefore meaningless, and by implication, worthless. That he can’t get his head around what code is, let alone what it means, rather confirms the importance of this initiative.

Here at Mythic Beasts we have some pretty strong views on starting coding young, so Pete took his Raspberry Pi and attempted to explain what coding is in terms that even Jeremy might understand, through the medium of a musical e-Card and via a few lines of Perl that can generate just about every pop hit ever. To read Pete’s views, or just to see a video of him playing the piano, click here.

We’ve just rolled out some improvements to our monitoring service. All server products, including virtual servers, get access to our basic ping monitoring service, allowing you to receive SMS and email alerts if your server goes off-line. For £5/month you can add enhanced monitoring, which allows you to confirm that individual services such as a web server are working correctly. Customers of our Managed Hosting service not only get access to enhanced monitoring, but also get the benefit of having our staff respond to the alerts for them.

The new features are:

Temporary silencing of alerts

You can now silence alerts for a set period. This is handy if you’re doing maintenance, and don’t want to be constantly pestered by alerts, but also don’t want the risk of forgetting to turn the monitor back on again afterwards.

Prowl notifications

Prowl is a notification system for iOS, allowing you to receive alerts on an iPhone or iPad. The advantage of Prowl notifications over SMS is that they’re not limited to 141 characters, so we can include a more verbose message, including direct links for silencing the alert. They’re also delivered over the internet, rather than the mobile network, so will work if you have a wifi connection, but no mobile signal.

Support for an Android equivalent (such as Notify My Android) is on the to-do list.

Improved email alerts

The email alerts previously included the same dense text that we use for SMS alerts. The new style notifications are now more verbose, and include links for silencing the monitor, and in the case of web alerts, a link to the page that failed.

Monitoring of arbitrary TCP ports

We provide monitors for most common services, including HTTP, SMTP, IMAP and POP3. You can now also monitor any TCP port. This check simply confirms that the host is accepting connections on this port, and then closes the connection.