[AfrICANN-discuss] The Implementation Challenges for DNSSEC

[Anne-Rachel Inné]

The Implementation Challenges for DNSSEC
 By Rod Rasmussen <http://www.securityweek.com/authors/rod-rasmussen> on Nov
24, 2010
 Share<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>
  Buzz  <http://www.google.com/buzz/post>
     0diggsdigg
 <http://feeds.feedburner.com/securityweek>

*Trouble Ahead - The Implementation Challenges for DNSSEC*

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.

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.[image: Is DNSSEC Worth It?]

*About DNSSEC *

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.

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.

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.

*The Root Signing *

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?

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. yourcompany.com 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.

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.

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.

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?

*DNS – From Simple to Complex *

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.

[image: Managing DNSSEC]

A case in point: The UK TLD inadvertently failed
authentication<http://www.nominet.org.uk/registrars/systems/serviceannouncements/?contentId=7872>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?

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!

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).

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.

* Rolling Keys *

If DNSSEC is complex and offers opportunities for failure, then logic
dictates the best
strategy<http://www.securityweek.com/five-strategies-flawless-dnssec-key-management-and-rollover>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.

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.

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.

*Incompatible Keys *

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.

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.

*Registrars *

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.

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 ICANN’s
Security and Stability Advisory
Committee<http://www.icann.org/en/committees/security/sac044.pdf>
.

* Registries *

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.

Are we having fun yet?

* Verification *

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.

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:

• http://dnsviz.net/

• http://dnssec-debugger.verisignlabs.com/

• https://www.dns‐oarc.net/oarc/services/odvr

• http://www.bortzmeyer.org/tests-dns.html

• https://addons.mozilla.org/en-US/firefox/addon/64247/

* Is DNSSEC Worth It? *

With all of the implementation headaches for DNSSEC, that begs the question…
is it worth it? The short answer is: *yes*, *no* and *maybe* – all of which
we will explore in the next two articles in the series on DNSSEC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/africann/attachments/20101125/a0a8b112/attachment-0001.htm