<span class="Apple-style-span" style="font-family: Arial; font-size: 12px; color: rgb(62, 62, 64); "><h2 style="font-family: Arial; font-size: 12px; margin-top: 6px; margin-right: 0px; margin-bottom: 12px; margin-left: 0px; color: rgb(0, 62, 92); ">
<span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Verdana, Arial, Helvetica, sans-serif; font-weight: normal; "><div class="auth-picture" style="float: left; margin-top: 0px; margin-right: 8px; margin-bottom: 8px; margin-left: 0px; ">
<img src="http://www.securityweek.com/sites/default/files/imagecache/auth_story/pictures/picture-6.jpg" alt="" title="" class="imagecache imagecache-auth_story" width="68" height="67" style="border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; "></div>
<h2 class="page-title" style="margin-top: 0px; font-size: 22px; ">Don't let DNS be your single point of failure</h2><div id="node-68" class="node clear-block" style="display: block; margin-top: 0px; margin-right: 0px; margin-bottom: 1.5em; margin-left: 0px; ">
<div class="meta" style="line-height: 1.667em; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(153, 153, 153); height: 25px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; font-size: 12px; clear: both; ">
<div class="submitted" style="display: block; float: left; "><a href="http://www.securityweek.com/content/dont-let-dns-be-your-single-point-failure">http://www.securityweek.com/content/dont-let-dns-be-your-single-point-failure</a></div>
<div class="submitted" style="display: block; float: left; "><br></div><div class="submitted" style="display: block; float: left; "><br></div><div class="submitted" style="display: block; float: left; "><br></div><div class="submitted" style="display: block; float: left; ">
<br></div><div class="submitted" style="display: block; float: left; "><a href="http://www.securityweek.com/content/dont-let-dns-be-your-single-point-failure"></a>By <a href="http://www.securityweek.com/authors/ram-mohan" style="font-weight: normal; text-decoration: none; color: rgb(0, 118, 180); ">Ram Mohan</a> on Apr 13, 2010 <span id="sharethis_0"><a class="stbutton stico_default" title="ShareThis via email, AIM, social bookmarking and networking sites, etc." href="http://www.securityweek.com/content/dont-let-dns-be-your-single-point-failure" style="font-weight: normal; text-decoration: none; background-image: url(http://w.sharethis.com/images/share-icon-16x16.png?CXNID=1000014.0NXC); background-attachment: scroll; background-origin: initial; background-clip: initial; background-color: initial; color: rgb(0, 118, 180); padding-top: 1px; padding-right: 5px; padding-bottom: 5px; padding-left: 22px; background-position: 0px 0px; background-repeat: no-repeat no-repeat; "><span class="stbuttontext" style="line-height: 17px; ">ShareThis</span></a></span> <a name="fb_share" type="icon_link" href="http://www.facebook.com/sharer.php?u=http%3A%2F%2Fwww.securityweek.com%2Fcontent%2Fdont-let-dns-be-your-single-point-failure&t=Don't%20let%20DNS%20be%20your%20single%20point%20of%20failure%20%7C%20SecurityWeek&src=sp" style="font-weight: normal; text-decoration: none; color: rgb(0, 118, 180); "><span class="FBConnectButton_Simple" style="background-image: url(http://static.ak.fbcdn.net/images/connect_favicon.png); outline-style: none; outline-width: initial; outline-color: initial; text-decoration: none; background-repeat: no-repeat no-repeat; "><span class="FBConnectButton_Text_Simple" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 20px; padding-bottom: 1px; ">Share</span></span></a> <a href="http://twitter.com/home?status=http%3A/%2Fwww.securityweek.com/content/dont-let-dns-be-your-single-point-failure+Don%27t+let+DNS+be+your+single+point+of+failure" class="tweet" rel="nofollow" target="_blank" style="font-weight: normal; text-decoration: none; color: rgb(0, 118, 180); "><img src="http://www.securityweek.com/sites/all/modules/tweet/icon.png" alt="Tweet This" title="Tweet This" width="16" height="16" style="border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-bottom: -2px; "> Tweet This</a></div>
</div><div class="content clear-block" style="display: block; line-height: 20px; "><p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">DNS is the address book for the Internet. It’s the way for users, customers and partners to find your online presence and communicate and transact with it. Without DNS, the Web, e-mail, hosted applications, and virtually every mission-critical thing done online would become unusable. Yet, because DNS mostly “just works,” many organizations treat the protection of their DNS infrastructure as an afterthought even though they know, or should know, that it represents the lynchpin of almost everything they do online. In fact, most senior level executives cannot say what their DNS availability strategy is – even senior level technology executives.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Just as you would not consider running an Internet company using only one connectivity provider or one Web server, you should not keep all your DNS eggs in one basket. Even if your organization rarely sees targeted attacks against it, it is increasingly common to see collateral damage during large Internet attacks – notice the number of recent incidents of popular social media sites being degraded by attacks against a single user. Sharing infrastructure, such as name servers, with the victim of an attack can cause innocent third parties to suffer. The bad guys today, in command of botnets sometimes comprising tens of thousands of nodes, have more than enough bandwidth at their command to disrupt all but the best-provisioned Internet presence.<img src="http://www.securityweek.com/sites/default/files/Weakest_Link.jpg" alt="DNS Infrastructure" title="DNS Weakest Link" width="261" height="232" style="border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; float: right; margin-top: 5px; margin-right: 5px; margin-bottom: 5px; margin-left: 5px; "></span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">When it comes to ensuring the availability of your DNS, diversity should be your motto. Diversity is a simple concept that can be baked into the design of any architecture and can be applied at every part of the DNS infrastructure from software to hardware to the providers you deal with.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">If you haven’t already created a DNS strategy that ensures you don’t have a single point of failure, here are three things you can do today to boost your reliability and increase your availability.</span></span></p>
<p style="padding-left: 30px; "><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; "><strong>1. Define a SLA for your DNS systems</strong></span></span></p><p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">If you are a large enterprise your IT staff are either running your DNS service in house, have contracted an outsourced managed DNS provider, or are using some combination of the two. A smaller organization may be sparing expense by relying on popular free or bundled DNS services.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Regardless of whether you run your DNS outsourced or in-house, it is essential to create a Service Level Agreement (SLA) for your DNS service and ensure that your IT staff and/or outsourced provider adhere to meeting it.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Do not settle for anything less than “five nines” or 99.999% uptime for your DNS systems. After all, if your DNS goes down no Internet traffic gets to your machines and none of your e-mail or essential services work either. A 99% SLA uptime equates to 14.4 minutes of downtime per day, and 7.2 hours of downtime per month. That is almost an entire work day per month lost!</span></span></p>
<p style="padding-left: 30px; "><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; "><strong>2. Introduce geographic and topographic diversity among your DNS machines</strong></span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Relying upon a single server in a single physical or logical location is an extremely risky proposition. If that name server should lose connectivity, be hit by denial of service attack or even natural disaster, it essentially takes every other DNS-reliant system down with it.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Your DNS should have sufficient geographical and topographical diversity in the physical location to protect from these sorts of attacks. Particularly, you should consider varying your DNS servers across multiple power grids and continents.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">The DNS root server operators and top level domain (TLD) operators, managers of possibly the most-attacked pieces of Internet infrastructure, have reduced geographical diversity to an art. While the DNS is often conversationally described as having “a root”, there are in fact 13 DNS root servers, in theory, each with a single IPv4 address. In practice, there are over 200 nodes in the root server network, located at data centers everywhere from New York to Moscow to Johannesburg to Reykjavik, each advertising the same 13 addresses using IP Anycast. TLD operators work on a similar principle, and manage large IP Anycast networks with advertised and unadvertised TLD root servers, setup in the locations where traffic tends to converge the most. That's massive topographical diversity, and it makes it very difficult for the whole system to fall to an attack. Criminals regularly throw enormous distributed denial of service attacks at the root and TLD servers and these operators have responded by hardening their networks and adding significant geographic and topographic diversity.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">For organizations with more modest needs, there's probably little need for a 200-node DNS network, but distributing zone data between more than one location on more than one subnet and using more than one resolution provider, can immediately mitigate the risks of downtime from DNS outages.</span></span></p>
<p style="padding-left: 30px; "><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; "><strong>3. Deploy diversity in your DNS software</strong></span></span></p><p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">The lack of heterogeneity in software is an over-familiar problem to security administrators, the dominance of Windows in desktop operating systems being the prime example. It may or may not be the case that Microsoft's software is less secure than other OS developers', but it is certainly the case that it is attacked more often and is found more vulnerable precisely because its popularity nears ubiquity. From a security perspective, software monocultures are risky.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">BIND is by far the most popular DNS software, and as such it has had its fair share of vulnerabilities, some of them very serious. In recent years, the Kaminsky bug, which would have enabled widespread DNS cache poisoning, was considered so severe that providers had to patch their name servers in secret before the nature of the vulnerability was disclosed.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">While the Internet Systems Consortium does a great job of patching newly found security holes in BIND, there will always be a window of vulnerability whenever a new zero-day problem is discovered. Just as it is good practice to have more than two browsers installed or your desktop in the event of prolific attacks against un-patched vulnerabilities in one, it is good practice in DNS infrastructure to spread the risk between more than one type of name server software.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">In addition, you should consider this same effect to critical zero day exploits that may affect your other software applications from your Operating System to your Network Monitoring Tools. If you use more than one type of software you can always remove one of them while it is being patched, reducing your vulnerability to exploits.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">The diversity principle can be applied in almost every area of an online organization: personnel, network and server hardware providers, power supplies, connectivity providers, all the way down to your power cable supplier. In the end, like everything in Internet security, it's all about balancing the cost of security against the cost of downtime when the security fails. But the key point is that DNS is every bit as important – if not more so – and every bit as vulnerable as any other part of your system architecture.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">These three actions - defining an SLA, adding geographic and typographic diversity to your nodes, and deploying software diversity – can ensure greater availability and reliability. The more diverse your architecture, the greater your availability.</span></span></p>
<p><span style="font-size: small; "><span style="font-family: tahoma, arial, helvetica, sans-serif; "><strong>Related Column by Ram Mohan</strong>: </span><a href="http://www.securityweek.com/content/first-step-internets-next-25-years-adding-security-dns" title="Adding Security to DNS" style="font-weight: bold; text-decoration: none; color: rgb(0, 118, 180); ">First Step For The Internet's next 25 years: Adding Security to the DNS</a></span></p>
<p style="text-align: center; "><span style="font-size: small; "><span style="color: rgb(51, 51, 153); "><em><strong><span style="color: rgb(0, 51, 102); "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Ram </span></span></strong><strong><span style="color: rgb(0, 51, 102); "><span style="font-family: tahoma, arial, helvetica, sans-serif; ">Mohan is the Executive Vice President and Chief Technology Officer at Afilias, a global provider of Internet infrastructure services including domain name registry and DNS solutions. Ram also serves as the Security & Stability Advisory Committee's liaison to ICANN’s Board of Directors and has helped direct and write numerous policies effecting domain name registration and DNS security. </span></span></strong></em></span></span></p>
</div></div></span></h2></span>