aTech Media

We've just pushed our some Apple Touch Icons for those who enjoy popping any of our applications on the homescreen of their iOS devices.

They, along with our new status site's icons, form part of our new global identity for each of our applications.

We hope you enjoy them.

PS: some of the icons shown in my screenshot are actually for internal tools and applications so you won't necessarily be able to get to all the sites shown here ;)

Our old status site was mostly a broken disaster of an application which was hosted on an unreliable external virtual server and resulted in poor and misleading information.

We've just launched our new status site which includes much the same information in a clear and concise manner. The new status site coincides with our new infrastructure & network which went live a couple of weeks ago.

The new site, like the old, is also hosted offsite. This time it's hosted by Digital Ocean in Amsterdam which is completely independent of any of our networks.

Take a look - we'd love to hear your thoughts.

This afternoon there was an issue which affected all .io domains across the internet. As there has been no official word from ICB (the registrar which runs .io domains among others, I wanted to write a quick post to explain a) what we identified happening and b) how this affected us and what we've done to prevent future issues.

A bit of background

In order to convert a domain into an IP address, we use a system called DNS (Domain Name System). In its most basic form DNS allows names (for example codebase.atech.io) to be converted into an IP address. For example, each time you enter a domain into your browser, your computer will use your ISPs DNS servers to lookup the domain you have entered and return that information to you. In order to allow users to control their DNS, the system allows for individual domains to be delegated to other nameservers which are in the control of the domain owner. In order to determine which nameserver to use, the DNS system follows a simple path to determine the authoritative nameserver(s) for the domain. For example, imagine we are looking up www.atech.io:

1. The root nameservers (of which there are currently 13) are queried to find the nameservers responsible for the .io top level domain. The root nameservers will return a number of different nameservers which are able to tell us where to look next. In the case of .io domains there are 7 possible servers to query next.

2. We will ask one of the nameservers provided where to look for atech.io. It will return an array of nameservers to ask next. For these, you will often only see two or three possible nameservers.

3. One of the atech.io nameservers will now be queried for www.atech.io. If it exists, the appropriate record will be determined and returned to you.

Using the dig tool you can interrogate this process, an example output is shown below:

; <<>> DiG 9.8.3-P1 <<>> +trace www.atech.io
;; global options: +cmd
.           2165    IN  NS  a.root-servers.net.
.           2165    IN  NS  b.root-servers.net.
.           2165    IN  NS  c.root-servers.net.
.           2165    IN  NS  d.root-servers.net.
.           2165    IN  NS  e.root-servers.net.
.           2165    IN  NS  f.root-servers.net.
.           2165    IN  NS  g.root-servers.net.
.           2165    IN  NS  h.root-servers.net.
.           2165    IN  NS  i.root-servers.net.
.           2165    IN  NS  j.root-servers.net.
.           2165    IN  NS  k.root-servers.net.
.           2165    IN  NS  l.root-servers.net.
.           2165    IN  NS  m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 1453 ms

io.         172800  IN  NS  ns1.communitydns.net.
io.         172800  IN  NS  a.nic.io.
io.         172800  IN  NS  b.nic.ac.
io.         172800  IN  NS  ns3.icb.co.uk.
io.         172800  IN  NS  b.nic.io.
io.         172800  IN  NS  b.ns13.net.
io.         172800  IN  NS  a.ns13.net.
;; Received 354 bytes from 192.36.148.17#53(192.36.148.17) in 757 ms

atech.io.       86400   IN  NS  dns1.atech.io.
atech.io.       86400   IN  NS  dns2.atech.io.
;; Received 100 bytes from 49.212.31.192#53(49.212.31.192) in 286 ms

www.atech.io.       3600    IN  CNAME   atech-web.vips.atech.io.
atech-web.vips.atech.io. 3600   IN  A   185.22.208.202
vips.atech.io.      3600    IN  NS  dns1.atech.io.
vips.atech.io.      3600    IN  NS  dns2.atech.io.
;; Received 201 bytes from 185.22.210.2#53(185.22.210.2) in 14 ms

What happened to .io domains today?

Today, an issue occurred in step 2 of the above process. Some of these .io authoritative nameservers were unable to tell us where to look next and therefore were failing.

We don't have any specifics about why this happened and things looked to be restored after about an hour of intermittent issues. We could speculate on what caused this, but we'd rather wait for an official response.

Why did this affect us?

Although we don't use many .io domains for our services, we do use it heavily in our backend infrastructure. All our domains (regardless of their top level domain) were configured to use dns1.atech.io and dns2.atech.io as their authoritative nameservers which meant that as these other domains could not be resolved at all.

What did we do to mitigate issues like this?

Unfortunately, it does seem as though the IO nameservers aren't as reliable as those provided for other top level domains like .com or .net. Another fact which disturbs us is that during this outage there has been zero communication from the registry responsible for managing the failed nameservers.

There we have taken the decision to set all our domains to use nameservers on the .com top level domain. This means that any future issues with smaller top level domain registries will not affect all our service in such as significant fashion. We will be moving all our domains over to use a.atechdns.com and b.atechdns.com over the next few days.

After many years of moving around the place, last October we renovated and moved into a new office. At time, we forgot to share any pics or really talk about it but we've finally got around to posting some pics on Facebook.

If you're not a friend already on Facebook, why not go and "friend us" and take a look at some new office pics?

Deploy, our code deployment platform, has been growing very quickly in popularity over the last 12 months and we finally thought it was time to give its website a bit of a refresh.

The new site focuses on the feature & benefits of using Deploy and keeps things simple. Check it out!

We've got a few nice things planned for the next couple of weeks on Deploy too - including support for other "cloud" endpoints as well as a few UI tweaks.

For a while now, Amazon S3 has supported the hosting of static websites. This makes S3 an ideal platform for placing small, static websites. S3 can also be used in conjunction with Amazon Cloudfront for CDN services.

Today we're launching a feature in Deploy that will allow you to deploy to an S3 bucket directly from your repository. To add an S3 server to your project just select "Amazon S3" from the protocol list and enter your Access Key ID, Secret Access Key and Bucket Name.

Of course, your new S3 server supports Deploy's automatic deployments, and multi-server deployments to give you a supremely flexible workflow. For example, you can add your new S3 server into an existing server group for automatic deployment of your assets to S3 for use in your CDN.

We've also made a few changes to the add server interface to make it a bit more intuitive and a bit less cluttered. The top half of the page is now dedicated to server connection details and upload paths and the lower half is dedicated to optional deployment parameters such as the branch the server tracks and the server environment.

If you have any comments or suggestions about this feature, please let us know on our community site.