IP of the hardcode server in the applications

As a result of the Dynamic attack, many major websites were down, including Twitter – browsers could not resolve servers’ IP addresses because the authoritative name server (Dyn) was down. I’m not sure if this could be dealt with globally – there has been an interesting discussion on Reddit about my proposal to increase TTL – how resolution policy and algorithms can be improved, why lower TTL is not always applicable etc.

But while twitter.com was down, the mobile app wasn’t working either. And while we don’t have any control over the browser, we certainly do have control over the mobile app (the same goes for desktop apps, of course, but I’ll mostly talk about mobile apps as being more dominant) . The reason the app was down as well is that it is probably also using the twitter.com domain (e.g. api.twitter.com) as well. And that’s the right way to go, except in those rare situations where DNS fails.

In these cases, you can hard-code a list of server IP addresses into your application and revert to it if queries based on the domain name fail (for example after 3 attempts). If you change your server’s IP addresses, you just update the app. It doesn’t matter that there is an unpredictable delay (until everyone updates) and some clients don’t have a proper IP address – it’s a fallback mechanism at the edge.

This is not, of course, my idea – it has been used by distributed systems like Bitcoin and BitTorrent – for example, when trying to join the network, the Bitcoin client or BitTorrent DHT tries to connect to a node of bootstrap in order to get a list of peers. There is a list of domain names in client applications that resolve using circular DNS to one of the many known seed nodes. However, if DNS resolution fails, clients have a small set of hard-coded IP addresses.

As this post points out, you may have multiple fallback strategies. Instead of, or better yet, in addition to hard-coding the IP address, you can have a backup domain name. foo.com and foo-fallback.com, managed by different DNS providers. This way your application will have a 3 step fallback mechanism – 1. try the primary domain 2. try the fallback domain 3. try the fallback IP addresses.

Events like the Dyn attack are (hopefully) rare, but can be costly for businesses. Adding fallback mechanisms to at least some of the client software is quick and easy and can reduce damage.