Tax doesn’t have to be taxing (part 1 aka the #VATMESS)

December 12th, 2014 by

We were planning to announce upgrades to our Virtual Servers today, but unfortunately we’ve had to spend time dealing with the #VATMESS

One of these coins is worth something. The other carries an obligation for a decade of document storage, 80 tax returns and tax rates for nearly 30 different countries. Guess which one we prefer?

At the moment, VAT on “e-services” sold within the EU is paid based on where the supplier is, so if you’re a small UK company selling, say, hosting services, you pay UK VAT to HMRC, irrespective of where the customer is.

If you’re a large company selling lots of such services then you’ll be paying enough VAT that it’s worth your while to move your operations to the member state with the lowest VAT rate, which is Luxembourg.

Of course, big companies avoiding tax is Evil, Bad and Wrong, so the EU has taken action.

The very short summary is, if you’re a non-VAT-registered customer in an EU state other than the UK, then we’re going to have to start charging you VAT at your local rate, rather than the UK rate. Good news if you’re in Luxembourg, bad news if you’re in Hungary.

The rather longer rant summary is that we’ve been forced to waste a significant amount of time understanding and complying with new regulations for VAT on electronic services which come into force on 1st January 2015.

Whilst cutting down on large companies undertaking VAT rate tourism might seem like a nice idea, charging VAT based on where the customer of an online service is creates a whole bunch of new problems:

1. How do we establish where a customer is based?

The guidance tells us that we need two non-contradictory pieces of evidence to establish the customer’s location, the most readily available being the billing address and the customer’s IP address. Setting aside the unreliability of geolocating IP addresses, what happens when a customer is enjoying their right to roam the EU freely and places an order whilst in another country?

Well, the guidance tells us we can use:

  • location of the bank (we don’t collect this information)
  • the country code of SIM card used by the customer (not applicable)
  • the location of the customer’s fixed land line through which the service is supplied to him (not applicable)
  • other commercially relevant information (suggestions on a postcard)

In the event that we succeed in obtaining the necessary evidence, we’re legally required to hang onto it for 10 years.

2. How do we find the correct VAT rate for a state?

Presumably, recognising that a huge proportion of companies in the EU now need to regularly lookup current VAT rates for different states, the EU will have created a convenient web service providing this information in a computer-readable format?

Well, the guidance sends you to this site which allows you to select “all states” and has an “Export selection” button. Looks promising until you try it and discover that it buries the data in a generated PDF.

Fortunately, some helpful soul has created what we actually want: a simple JSON feed.

Unfortunately, that site makes the amateur mistake of thinking that ISO 2 digit country codes will be enough to cope with all the VAT rates in the EU, forgetting that the Portuguese Azores and Portuguese Madeira have their own VAT rates, but not their own country codes. As it happens, the EU site listed above also denies knowledge of the VAT rates applicable in these regions.

3. How do we report and pay our VAT?

HMRC are proud to tell us that they’re saving us the burden of registering for VAT in each member state in which we do business by letting us use MOSS, their “One Stop Shop”, but we still now have to complete two separate quarterly VAT returns and, of course, the quarters don’t even align.

Bulk upload of our VAT data is supported using that well known open data-interchange standard: a spreadsheet. A particular highlight is that: “When completing HMRC’s spreadsheet you can’t use country codes (for example GB, UK, NL or DE) or country descriptions (for example Great Britain, the UK or The Netherlands). You must only use the following EU country names:”. That’s right, HMRC have eschewed ISO country codes for its preferred list of country names and spellings, and not even for the obvious reason that some states have multiple rates: Portugal is only listed once.

Tax doesn’t have to be taxing … but it is

The net result of these new rules is that it’s now much harder for us to sell to consumers in other EU states than it is for us to sell to consumers outside of the EU – surely the exact opposite of what the single market is supposed to achieve?

The amount of our business that is affected by these new rules is tiny, as most of the EU business we do have is to VAT-registered entities to whom an entirely different set of rules apply. The amount of profit we make in a year from the affected services is almost certainly less than the upfront compliance cost, if not the ongoing cost, so we have seriously considered simply refusing to sell to consumers in other EU states, although it has been suggested that this could be illegal under EU law!

It could be worse

These VAT changes are a nuisance for us, but we’re already well above the UK VAT threshold so already have processes in place to deal with the burden of UK VAT reporting. For very small companies, as we were not so long ago, these changes are absolutely horrific as there is no VAT threshold for inter-state VAT. The government accepts that requiring all businesses to operate UK VAT would be an unreasonable and stifling burden on small businesses, which is why we have a VAT threshold (currently £81k). But there is no such threshold for inter-state VAT, despite it being significantly more complicated to administer.

There is a growing storm of angry micro-businesses who, through virtue of not being VAT-registered, weren’t notified of the upcoming changes. Indeed, it seems that HMRC’s assessment of the impact of these changes not only vastly underestimated the cost of implementing them, but also completely forgot about several hundred thousand micro businesses that would get shafted by these changes.

(HMRC’s original impact assessment stated that “businesses currently unregistered in the UK who choose to register for MOSS in the UK will also have to obtain a UK VAT registration and their UK supplies will therefore also become liable to VAT”, meaning that if you sold a single e-service to an EU consumer you were pretty much obliged to start operating UK VAT too. HMRC have back-tracked on this by publicly endorsing the practice of splitting EU from UK revenue – despite revenue splitting normally being considered an illegal VAT-evasion practice)

Get your site ready for IPv6: a step-by-step guide

September 15th, 2014 by

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 http://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.

New improved IPv6 site tester

September 5th, 2014 by

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:

Screen Shot 2014-09-05 at 10.02.00

 

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.

HTTPS: the new default?

August 8th, 2014 by

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:

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.

More monitoring service improvements

June 30th, 2014 by

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.Managed Monitor screenshot

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.

.uk domains now available

June 10th, 2014 by

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.

Up to 33% off new domain registrations

April 2nd, 2014 by

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.

2nd Apr 9th Apr 15th/16th Apr
.camp .coffee .photo (15th Apr)
.education .florist .holiday (16th Apr)
.glass .house .marketing (16th Apr)
.institute .international
.repair .solar

Direct Debits and Domain Auto-Renewals

March 21st, 2014 by

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.

IPv6-only Virtual Servers

February 24th, 2014 by

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.

Meaningless codes

February 13th, 2014 by

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.