aTech Media

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.

Here's a depressing statistic: 65% of people have received poor customer service online. This presents both danger and opportunity for businesses...

The Danger

64% of people would not return to a company online that provided bad customer service, no matter how much they enjoyed the product or service on offer.

With online shopping in the UK topping £50bn in 2012, this means over £20bn could be lost as a result of customer dissatisfaction. This number is staggering. Even if it’s only half true, it is still a huge amount of money being lost by online businesses.

The challenge is that often online prices reduce margins and yet customer service can be time consuming and expensive to provide.

The Opportunity

The growth of online retail in the UK has brought with it opportunities as well as problems. Businesses that are able to adapt and offer outstanding service online, with great products at great prices, are more likely to win and retain business. 94% of people would recommend a company if they had a good customer service experience with them, and 93% of people said it makes them loyal to a company.

The Problem

The Internet empowers businesses to provide good customer service quickly and easily, so why are so many falling short? Outdated and disorganised methods of responding to customers are causing the problem, resulting most commonly in these mistakes:

• A slow response; 50% of people say companies have left them waiting, and if that’s not infuriating enough…
• 31% have been completely ignored after submitting a query to an online customer service department. That is simply not good enough. Businesses need to be armed with an on-the-ball customer response team otherwise everything will fall apart.
• 36% have been given a response to a customer service query made on the web that doesn’t solve the problem. These people might as well have been ignored – what’s the use in a response that doesn’t at least seek to solve the problem, no matter how friendly and professional it is? Speaking of which…
• 11% have received a rude response. There is never a good reason for this. Your customer service team need to be able to keep its cool in even the most heated situations.
• Failing to respond to customers effectively using social media is reputation-suicide. 35% of Brits have used social media to badmouth a company’s customer service capabilities. Ideally, you don’t want it to come to this, and by resolving the above mistakes there’s a better chance it won’t. If it does happen, you need to ready with a capable and good-humoured team that can deliver positive customer service in a public environment.

The Solution

There's nothing stopping these businesses streamlining their customer service process to enable them to efficiently handle more queries with the same number of staff. Online helpdesks like our own Sirportly allow your customer service team to connect with customers wherever they are, seamlessly integrate social media services and stay in control of customer support data. This will help them cut out unnecessary mistakes and keep customers happy, ultimately encouraging loyalty to your business and positive word of mouth.

Related Articles

• Rude, sloppy and slow: Just another online service experience
• 10 interesting digital marketing stats we've seen this week
• Online retailers could lose £20bn in UK through poor customer service
• Lack of customer support could lose UK online businesses £0bn

We're introducing two new code review features into Codebase today; comments on individual lines in a commit and merge requests.

Merge Requests

Merge requests allows a feature branch to be reviewed in a formal way before being merged into a mainline branch. You'll find this helpful if you tend to work with feature branches and have someone responsible for checking over changes before merging deploying them to live or staging environments.

The merge request view enables you to see the all of the changes that would be made by merging the two branches. If the branches can be merged without any conflicts then you'll be offered a button to automatically merge pressing this will take care of the merging for you.

We've needed to move some items in the repository navigation to make way for merge requests, so the "Branches" and "Tags" tabs can now be found linked from our new, enhanced "Browsing" menu. Merge Requests can be found in the tabs at the top of the repository browser.

Inline Commenting

Codebase has allowed you to comment on commits for some time, but sometimes you need to comment on a specific line of code, maybe to highlight its genius, or deride it's madness. Now you can, just hit press the comment icon next to a line of code in a commit or diff to add a comment to that line.