<h2 class="page-title">The Implementation Challenges for DNSSEC</h2>
<div class="meta">
<div class="submitted">
<div style="float: left; margin-right: 5px;">
By <a href="http://www.securityweek.com/authors/rod-rasmussen">Rod Rasmussen</a> on Nov 24, 2010 </div>
<div style="float: left; margin-top: 3px;">
<a style="text-decoration: none;" name="fb_share" type="button" href="http://www.facebook.com/sharer.php?u=http%3A%2F%2Fwww.securityweek.com%2Fimplementation-challenges-dnssec&t=The%20Implementation%20Challenges%20for%20DNSSEC%20%7C%20Information%20Security%20News%2C%20IT%20Security%20News%20%26%20Expert%20Insights%3A%20SecurityWeek.Com&src=sp"><span class="FBConnectButton FBConnectButton_Small" style="cursor: pointer;"><span class="FBConnectButton_Text">Share</span></span></a>
</div>
<div style="float: left;">
<a style="text-decoration: none;" title="Post on Google Buzz" class="google-buzz-button" href="http://www.google.com/buzz/post"><span dir="ltr" class="buzz-small"><span class="buzz-small-1-ltr buzz-small-1"> </span><span class="buzz-small-2-ltr buzz-small-2">Buzz</span><span class="buzz-small-3-ltr buzz-small-3"> </span></span></a>
</div>
<div style="float: left;">
</div>
<div style="float: left;">
<span> </span><span class="db-wrapper db-clear db-compact"><span><span class="db-container db-submit"><span class="db-body db-compact"><span class="db-count">0</span><span class="db-copy">diggs</span><a class="db-anchor">digg</a></span></span></span></span>
</div>
<div style="float: left;">
<a href="http://feeds.feedburner.com/securityweek" target="_blank" style=""><img style="margin-top: -7px; margin-left: 5px;" src="http://www.securityweek.com/images/RSS-Icon.png"></a>
</div>
</div>
</div>
<p style="text-align: center;"><strong><em>Trouble Ahead - The Implementation Challenges for DNSSEC</em></strong></p>
<p>There has been a lot of recent buzz surrounding implementation of
Domain Name System Security extensions (i.e., DNSSEC). The latest
example: verification and signing of DNSSEC for the .IN (India) and
.ASIA top-level domains (TLDs), which are being pitched as major
enhancements to global security for much of Asia.</p>
<p>Yet massive industry-wide confusion, continued lack of awareness for
DNSSEC outside the DNS industry, a plethora of DNSSEC verification
techniques and standards, and arguments over which to use, tell a
different story. This also leads to some key takeaways for anyone
looking at implementation today. We will take a closer look at the
history and reasons for the existence of DNSSEC and some of the key
implementation roadblocks in this first of a three-part series on DNSSEC
deployment.<img src="http://www.securityweek.com/sites/default/files/Challenges-DNSSEC.jpg" alt="Is DNSSEC Worth It?" title="DNSSEC Implementation Challenges" style="float: right; margin: 4px;" height="133" width="200"></p>
<p><strong>About DNSSEC </strong></p>
<p>DNSSEC is supposed to protect the Domain Name System (functionally,
the Internet’s phone book) from several authentication exploits,
primarily cache poisoning. These attacks can allow malicious entities to
intercept Internet users’ requests to access a website, e-mail, or
other services, and redirect or eavesdrop on the users without their
knowledge. They are invisible to the users and leave them no ability to
reassert control – potentially costing organizations millions of dollars
in lost reputation, recovery costs and more. DNSSEC introduces digital
signatures to the DNS infrastructure and is supposed to automatically
block cache poisoning by authenticating the identity of a given domain
or hostname.</p>
<p>The technology grabbed major headlines in 2008 when security
researcher Dan Kaminsky exposed a serious flaw in the DNS that allowed
cyber criminals to easily launch cache poisoning attacks against DNS
software used by a majority of recursive nameservers. Using such
attacks, cybercriminals could impersonate websites, intercept e-mail or
steal passwords to hacks into corporate networks. This thrust DNSSEC,
which had been around for close to a decade, into the spotlight.
Industry leaders and professionals rallied around it as a solution to
potentially endless DNS cache poisoning attacks.</p>
<p>Unfortunately, years later, wide-spread DNSSEC adoption is still far
from completion, even for critical domains and services. A recent
Forrester Research survey commissioned by VeriSign found that only 43
percent of nearly 300 global network operations or IT security
influencers/decision-makers had “heard of DNSSEC and know what security
problems it solves.” This is despite the fact that over half admitted
they had experienced some sort of “DNS attack” and over a third had been
hit with what is called a DNS “man-in-the-middle” cache poisoning
attack, exactly what DNSSEC defeats. So the need is there, but
awareness and action lag.</p>
<p><strong>The Root Signing </strong></p>
<p>One of the key issues that had held up deployment is that DNSSEC
relies on exchange of digital signatures and certificates for
verification of trusted domains up and down the entire “chain of trust”
from the root of the Internet. And until the root servers, which sit at
the top of the DNS hierarchy were signed, the system did not really work
very well – at least without some major band-aids that most operators
were unwilling to adopt. Hence the elaborate ceremony at a high security
data center in Culpeper, Virginia, this past July for signing of the
root zone. So we are all ready to go now, right?</p>
<p>Not so fast. This really only marks the beginning of deployment. As
we saw at the start of the article, .IN and .ASIA were just signed this
month, with other major TLDs coming online with DNSSEC over the past few
months. Some of the biggest TLDs like .COM, .NET, .UK and many others,
aren’t signed yet. As a result, subdomains like www. <a href="http://yourcompany.com">yourcompany.com</a>
cannot be fully authenticated to the root. Or at least there is not a
major benefit if they are, and there may be failures that lead to
further issues – more on this in my next article.</p>
<p>But while delays in the signing of top-level domains have slowed
DNSSEC, that’s not the hard part of deployment. In fact, all of these
TLD zones should be signed by sometime early next year. And then the
real challenge will be upon us: the zillions of domain names, and
hostnames within the zones.</p>
<p>So are organizations and businesses positioning themselves to take
advantage of DNSSEC? Yes and no. For example, our research shows that
many .GOV domains are adopting DNSSEC, mainly driven by government
mandates. But dig a little deeper and you will find that actively
managing DNSSEC at many of these organizations remains a challenge,
creating errors and omissions, and not fully delivering the benefits of
signing.</p>
<p>Yet in a very real sense, this is exactly the time to plan or begin
implementation if you want to be in a position to take advantage of the
technology. So what are some of the major the pitfalls, and how can
they be avoided?</p>
<p><strong>DNS – From Simple to Complex </strong></p>
<p>DNS management is well understood and fairly straightforward in the
networking world. However, one of the first major pitfalls is that
unlike traditional DNS management, DNSSEC implementation is complex.
There are not many simple tools or straightforward “how-to” manuals
available to help. This is changing, but we are still talking about
“bleeding edge” technology here, and that means risk.</p>
<p><img src="http://www.securityweek.com/sites/default/files/Weakest_Link.jpg" alt="Managing DNSSEC" title="DNSSEC Resources" style="float: left; margin: 4px;" height="232" width="261"></p>
<p>A case in point: The UK TLD inadvertently <a href="http://www.nominet.org.uk/registrars/systems/serviceannouncements/?contentId=7872" title="DNSSEC validation issue">failed authentication</a>
for several hours this past September, because they did not complete
the simple process of syncing up ZSKs (Zone Signing Keys) on all their
hardware. Then Belgium accidentally did a similar thing for several
hours in October due to basic operational errors – they let their DNSKEY
expire and didn’t have a backup live. Both of these failures ran the
risk of taking these countries domains off the Internet. Lesson one:
this ain’t easy. Lesson two: if the guys that actually get paid big
bucks to run DNS for entire countries are struggling, how will someone
like a mid-sized bank be able to cope?</p>
<p>So how does it work in a nutshell? DNSSEC adds private/public key
validation via four new resource record types added to the standard DNS:
Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation
Signer (DS), and Next Secure (NSEC), though there are a few flavors of
NSEC now. Using a chosen algorithm and tool, a private key is used to
generate public keys to populate these various records. Public keys for
a zone (domain/hostnames/TLDs/etc.) are stored as DNSKEY records. After
signing each record with private keys, signatures are stored as RRSIG
records. These records must appear in a zone’s DNS along with other
sundry records for management like well-considered TTL values. During
the signature process a DS record is generated that needs to be
published by the parent zone to create a “chain of trust”. For a domain
name, a DS record has to be added to the registry’s zone – typically by
a registrar. This is not your father’s DNS system!</p>
<p>Larger enterprises are clearly the ones who will most benefit from
DNSSEC, and also have the best resources available for implementation.
But as these organizations begin to roll their own deployments, they
would be wise to consider partnering with an expert consultant to help
guide the process (services are offered by such companies as Afilias,
Neustar and VeriSign, among others), or leverage one of the free
toolkits that have begun to pop up (such as Kaminsky’s recently released
Phreebird).</p>
<p>Hardware and DNS changes The next pitfall is fairly mundane, but of
extreme importance. If you’re running your own DNS implementation, you
need to properly handle the increased overhead required to run DNSSEC on
your infrastructure. You also have to tighten up your DNS change
management practices. DNSSEC requires larger packets, and therefore
more memory and processor horsepower than standard DNS. Networking gear
also has to support TCP DNS packets, a switch from the existing
standard of UDP packets. These are all typical “gotchas” for
implementation. In addition, all changes to zones must be accounted for
with a new signing every time. These are good examples of reasons to
consider outsourcing your DNS when changing over to DNSSEC.</p>
<p><strong> Rolling Keys </strong></p>
<p>If DNSSEC is complex and offers opportunities for failure, then logic dictates the best <a href="http://www.securityweek.com/five-strategies-flawless-dnssec-key-management-and-rollover" title="Five Strategies for Flawless DNSSEC Key Management and Rollover">strategy</a>
is to set it and forget it. Yet proponents of rock-solid security
recommend rollover of ZSKs every quarter, and KSK (Key Signing Key)
every two years, meaning you have four to five chances for things to go
wrong per year. And… your registrar and the root domain should each do
the same. Now you are at about a monthly opportunity for disaster, only
a few of which you control. The reason for this is the belief that
“bad guys” out there will be trying to decrypt your keys, and the longer
your key stays the same, the better odds they have of doing so.</p>
<p>Perhaps the best way to view this is through analogy. How often do
you rekey the door locks on your business? Most likely, the answer is:
only when there is an issue or event that warrants it. This is also the
best approach to DNSSEC at this stage; organizations would be wise to
roll over their signature keys whenever an event, such as the firing of
an employee that knows the keys, warrants a change.</p>
<p>If you are worried about bad guys guessing your keys (and that’s a
pure speculation problem at this point), then monitoring of your DNS
queries for signs of someone trying to systematically try to “pick your
lock” is advised. You should be monitoring your DNS logs for all kinds
of other security reasons anyway, so this provides a good excuse for
investing in that capability if you do not have it already.</p>
<p><strong>Incompatible Keys </strong></p>
<p>Another key-related pitfall? It turns out that since the DNSSEC
key-signing standards themselves are not yet finalized, and are evolving
to take advantage of newer cryptography methods, many of the algorithms
for generating signature keys are not fully compatible. In other
words, one particular key signing technology doesn’t work with another
particular DNSSEC implementation – which is a horrible thing to find out
after you have just completed deployment.</p>
<p>While the newer standards are backwards compatible (or are supposed
to be) that doesn’t help when you choose a newer method to sign, and a
major ISP or key partner uses an older method to authenticate. Errors
then ensue where people are not able to reach your domain since the
authentication fails. Since authentication on resolution still isn’t
really being done “for real” (I’ll touch on that chicken-and-egg problem
in a later installment), the recommendation now is to choose one of the
newer methods that provide stronger crypto and better security, as
those will likely be the methods that receive wide adoption on the
resolver side when those finally roll out.</p>
<p><strong>Registrars </strong></p>
<p>Another pitfall derives from the fact that DNSSEC is still very new,
and as a result, not many registrars support the technology as yet. One
primary reason is the economics. With domain names selling for a few
dollars per year, and the extraordinary variety and volume of domains
that don’t engage in e-commerce or sensitive communications (two main
security drivers), there is little incentive today for registrars to
absorb the costs and administrative overhead required to support DNSSEC.
DNS providers are much more likely to be in front of the curve on
DNSSEC, but options are limited.</p>
<p>However, there is a silver lining: hunting for a new registrar or
DNS provider also provides the opportunity to select one that offers
two-factor authentication and additional domain locking services. And
if you are not doing multi-factor authentication for domain management
already, you are missing one of the single biggest security holes
around. Additional information on this can be found in the recently
published report from <a href="http://www.icann.org/en/committees/security/sac044.pdf" target="_blank" title="A Registrant’s Guide to Protecting Domain Name Registration Accounts">ICANN’s Security and Stability Advisory Committee</a>.</p>
<p><strong> Registries </strong></p>
<p>Assuming your registry supports DNSSEC, you are still not out of the
woods. When you sign your own DNSSEC records for your domain, you still
need your registry to publish the “DS Record” in THEIR zone for your
domain. This is what ensures the “chain of trust” from the root on down
to individual hosts – higher authorities validate your records from
their perspectives. That is all well and good, but not all registries
support all signing methods. Thus you need to ensure that the signing
method you want to use is supported by the registry (and of course the
registrar) for your domain’s TLD.</p>
<p>Are we having fun yet?</p>
<p><strong> Verification </strong></p>
<p>The final takeaway from all of this? If there is opportunity for
DNSSEC deployment to break your connectivity, you’d better be absolutely
sure to verify that your DNS records are publishing properly. The U.S.
government recently went through this exercise and, much to its
chagrin, found that many of its records were wrong.</p>
<p>Fortunately, there are a number of free tools and websites that make
it easy to check the status and accuracy of DNS records, including the
following:</p>
<p style="padding-left: 30px;">• <a href="http://dnsviz.net/" title="http://dnsviz.net/">http://dnsviz.net/</a></p>
<p style="padding-left: 30px;">• <a href="http://dnssec-debugger.verisignlabs.com/" title="http://dnssec-debugger.verisignlabs.com/">http://dnssec-debugger.verisignlabs.com/</a></p>
<p style="padding-left: 30px;">• <a href="https://www.dns">https://www.dns</a>‐<a href="http://oarc.net/oarc/services/odvr">oarc.net/oarc/services/odvr</a></p>
<p style="padding-left: 30px;">• <a href="http://www.bortzmeyer.org/tests-dns.html" title="http://www.bortzmeyer.org/tests-dns.html">http://www.bortzmeyer.org/tests-dns.html</a></p>
<p style="padding-left: 30px;">• <a href="https://addons.mozilla.org/en-US/firefox/addon/64247/" title="https://addons.mozilla.org/en-US/firefox/addon/64247/">https://addons.mozilla.org/en-US/firefox/addon/64247/</a></p>
<p><strong> Is DNSSEC Worth It? </strong></p>
<p>With all of the implementation headaches for DNSSEC, that begs the question… is it worth it? The short answer is: <strong>yes</strong>, <strong>no</strong> and <strong>maybe</strong> – all of which we will explore in the next two articles in the series on DNSSEC.</p>