How to Survive a DNS Attack
by SPitBalls
On Monday, September 10, 2012, many websites were made unavailable due to an outage that affected all the name servers under one specific domain, namely domaincontrol.com.
It was initially suspected to be caused by an attack affecting that one domain, but later reported to be an issue with the provider's network. In any case, the result was the same - many customers' websites were down - unnecessarily.
The domain name system is designed to be fault-tolerant; each domain record must specify a primary name server and at least one secondary name server. Therefore, despite the DNS outage, the outage of the websites was quite avoidable.
How a Name Server Resolves Names
When given a hostname (Example: phalse.2600.com) or service name (Example: www.your-company.com) and asked for an "A" or "AAAA" record, a name server will return the corresponding 32-bit IPv4 or 128-bit IPv6 address, respectively.
The answer is cached in the client for some amount of time determined by its "Time To Live" (TTL). The default TTL is one hour (3,600 seconds) but can be overridden in the zone's SOA record or the individual resource record in the authoritative name servers.
On Mac and UNIX systems you can use the DiG command to see how much time is left.
For example:
That example shows the default TTL, so in this case the information must not have been in the cache yet or had already expired.
If you enter the same DiG command again, you will see the remaining time decreasing. So if other people are telling you that your website is down but it looks fine to you, one possibility is a problem with DNS. Using DiG, you can find out how much time is left until you won't be able to access the site either.
There is usually an OS-dependent way to flush the DNS cache, such as ipconfig /flushdns on Windows.
On a Mac or UNIX system, you typically restart the client lookup process (try ps -e | grep 'dns|named' to find it, then do a web search to find out how to restart it).
Are Your Name Servers Really Redundant?
If you configure the DNS records for a website with all name servers under one domain such as:
Then an attack or failure that affects the name servers under the domaincontrol.com domain disables all of them. This will prevent lookups from getting the IP address that corresponds to the website's domain name.
When your website goes down, the natural reaction is to blame the hosting provider. But if it was DNS that caused the outage rather than the hosting servers being down, the outage could have been avoided by taking advantage of the redundancy built into the domain name system.
If the website domain is configured with name servers under at least two different domain names, then one of the name servers should be able to resolve DNS queries even when the primary name server and all other name servers under the same domain are inaccessible.
Example of Fault-Tolerant Name Server Configuration
To avoid having a website go down due to an outage affecting one set of name servers, you should configure the name servers to avoid a single point of failure.
Here is an example of name servers configured to allow access to a site even if all servers under one domain are FUBAR:
This list of name servers includes some servers from the hosting provider, with one of those specified as the primary, and others from a free DNS service provided by a different registrar (Namecheap).
To keep the name servers in sync, you set up one name server as the master and the others as slaves. Even if the master is unavailable for some period of time, the slaves can continue to operate using the data in their cache.
As a result of the Sept. 10th outage, there were suggestions online about various places you could move your DNS services to avoid a similar outage in the future. But if you moved all of your name servers, then you are probably creating a similar single point of failure at the new service.
To avoid an outage due to an attack or even just a minor outage at one service or another, such as during a reboot, you should not move all of your name servers elsewhere. You should leave at least one alone so that you have redundant name servers from at least two different places as shown above.
So now go check your domain's WHOIS and then have some fun hacking its DNS.