Jeremy Hitchcock is CEO and owner of Dyn Inc., a technology services provider that focuses on DNS services. Mr Hitchcock is also member of the ICANN Security and Stability Advisory Committee (SSAC), which advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems.

Date added: July, 2010

July 15, 2010 at 2050 UTC will be a time that many DNS people remember. The DNS Root is now signed and validatable. Over the next few weeks, TLDs which are already signed will be submitting their DS records to the root to support end-to-end validation for about 10% of all top level domains, including one of the largest gTLDs, .org. While DNSSEC as a concept has been around for more than a decade, the root signing has culminated in the last two years.

This is a great milestone and statement about legitimacy of DNSSEC as a core DNS technology. DNSSEC is analogous to the development and rollout of HTTPS where an entire infrastructure must be created before the benefit of validated names can become a reality. Unlike HTTPS, DNSSEC has the opportunity for much more. As a milestone, there is both work behind and ahead of us. A quick summary of what is to come:

Signing infrastructure

Now that there is a signed root, the march continues for TLDs to sign their zone. Every month, another 1-3 zones are newly-signed. At the same time, TLDs are adding the necessary extensions for their registrants and registrars to provide DS records.

Major registrars are beginning to provide the necessary functionality and education around DNSSEC for the registrants who want DNSSEC. Work is progressing here.

With the timeline for first half of 2011 for signing .com, the largest and most difficult zone to be signed next year, plus the other gTLDs who will sign before then, the timeline is set for when DNSSEC becomes a major reality.

Validating infrastructure

Validation is where the most active phase of work will take place. ISPs around the world provide the recursive/caching lookup services to actually validate DNSSEC data. Some ISPs, like Comcast, have run extensive trials and are leading the way and sharing their results and experiences. It is hopeful that others will follow their foot steps, bringing DNSSEC to their entire user population by the end of 2011.

Operating systems have support for DNSSEC but it's not on by default. With the signing infrastructure more complete, there will be a greater reason to enable DNSSEC for sending mail, VoIP, or browsing the web. The user experience has not been fully envisioned so this will be an exciting place to watch.

The real step here is when there is a padlock or secure icon in a web browser to provide DNSSEC feedback. There is already a Firefox extension that supports DNSSEC and there are rumors of a Chrome extension. When these security features make it to other browsers and rolled into the core functionality is unknown but it's on the horizon.

Where do we go from here and extended uses

The great news is that end-to-end DNSSEC is now a reality and that people benefit from DNSSEC today. Applications and software are making it easier for domain owners to publish DNSSEC and Internet users to consume DNSSEC.

Getting everything signed and validating is now part of the infrastructure of the Internet. What is entirely unknown is what applications or services will be created on top of DNSSEC. What can you do with an authenticated, converging, distributed key-value store?

Close

Warren Adelman is responsible for day-to-day operations, resource management, process improvement and corporate strategic planning for Godaddy.com, which has grown to include more than 43 million domain names under management. In addition to his role at Go Daddy, Warren is an active member of the ICANN Accountability and Transparency Review Team.

Date added: September, 2010

The Internet is Becoming More Secure

At the 38th ICANN meeting in Brussels, the .ORG registry announced DNSSEC was officially live. Soon after, .US, .EU and .BIZ started supporting DNSSEC. By 2012, most of the popular TLDs are expected to be supporting the technology.

At Black Hat 2010, Dan Kaminsky, a security researcher known for his work on DNS Cache Poisoning, showed DNSSEC can be implemented in less than 5 minutes using DNS software and GoDaddy.com. You can watch the video here.

While DNSSEC adoption is a big step in helping protect the Internet, it's only a start.

Business Has Changed

E-commerce has changed how we conduct business. Before the Internet, deals were completed with a face-to-face meeting, a handshake and an agreement. People represented themselves in person.

Today, consumers go to merchants and businesses online, making the relationship anonymous from both sides. That anonymity creates opportunities for criminals looking to take advantage of any flaw or weakness they can. Every day, there are new stories about credit card fraud, phishing and identity theft online.

Build Trust of Users

Whether you provide Internet content, backbone or retail offerings, the primary goal is to build confidence. This can be done through value-rich products, stellar customer service, helpful information or whatever "key ingredient" that makes you or your business successful online. It doesn't matter if you are a multinational corporation or a home based business - trust is an essential component to retaining visitors. Trust not only makes your business grow, but also helps strengthen the Internet community at large.

Unfortunately, there is no "magic bullet" when it comes to building trust with your customers. But when DNSSEC is used in conjunction with other security enhancements, it helps create that consumer confidence we are all working so hard to obtain.

Still Work to Do

While a lot has been accomplished for DNSSEC this summer, it's only the tip of the iceberg.

Without providing education for the masses and ensuring its implementation is easy, DNSSEC is nothing more than a good intention.

There's no doubt DNSSEC conversations are happening among companies' technical staff, but how many CEOs and Presidents are asking what DNSSEC is and whether or not they need it? There is much work ahead. But through a blend of promotion, education and adoption, DNSSEC can someday play a key role in online security.

Close

Olaf M. Kolkman is director of NLnet Labs, a charity chartered to develop open source software and open standards for the Internet; the organization that developed DNSSEC aware nameservers NSD and Unbound.

Date added: September, 2008

DNS is one of the essential protocols on the Internet. It is used in almost every interaction that uses names in identifiers: Email, Web, SIP based Voice over IP, Web services, Spam filtering, Internet messaging, and many more. Yet the DNS system has not been designed with security in mind; over 3 decades ago, resiliency and scalability where the important components to focus on. Given that the DNS is the largest distributed lookup system on the Internet one could claim that the protocol designers were successful.

However, the fact that security was not high on the todo list has come back to bite us. The fact that essential components in the DNS architecture called caches are subject to so called "poison attacks" has been known for almost 2 decades now [1]. As a result of a cache poisoning attack, e-mails can be redirected and copied before they are delivered to their final destination, voice over IP calls can be tapped by third parties, and -- given the circular dependency of the certification on the DNS -- SSL certificates may not be as protective as one would hope.

The Domain Name System has become a utility that people depend on when moving about on the Internet. It is a core part of the Internet Infrastructure and trust in the DNS is necessary, albeit not sufficient, for trust in the Internet.

DNSSEC was designed to deal with cache poisoning and a set of other DNS vulnerabilities such as "man in the middle" attacks and data modification in authoritative servers. Its major objective is to provide the ability to validate the authenticity and integrity of DNS messages in such a way that tampering with the DNS information anywhere in the DNS system can be detected. This is the kind of protection that DNS desperately needs.

Unfortunately it is because of the distributed nature of the DNS that DNSSEC needs to be deployed by a significant amount of DNS data providers before its utility becomes useful. Custodians of the DNS infrastructure such as TLDs and the root system should provide a breeding ground on which DNSSEC can take off, while ISPs and enterprise DNS administrators prepare their DNS infrastructure to validate signed data.

Obviously this is not going to be a project with immediate return on investment, it is a long term strategy to allow us to put similar trust in the Internet as we did 10 years ago.

[1] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 1989, http://www.cs.columbia.edu/~smb/papers/ipext.pdf

Close

Roland M. van Rijswijk is technical product manager at SURFnet, The Netherlands National Research and Education Network. He is -- amongst other things -- responsible for SURFnet's DNS infrastructure and the deployment of DNSSEC on this infrastructure.

Date added: January, 2010

DNSSEC: Checking if DNS points in the right direction

Introduction: the problem

The Domain Name System is one of the foundations of the Internet. It plays a key role in making sure that we can find what we're looking for on the net. It is a highly resilient and vastly distributed system. An apt analogy is to say that DNS provides the road signs for the Internet.

Unfortunately, security was not a design criterion when the DNS protocol was developed. DNS turns out to be vulnerable to all sorts of attacks, which impact its availability and integrity. Especially the latter category is very tricky: what if DNS gives us an answer that points us in the wrong direction? Well, this is exactly what turns out to be possible. A DNS resolver (that part of the DNS that takes care of finding answers to your questions) can be tricked into accepting falsified answers to its queries. And even worse: in 2008 Dan Kaminsky showed the world that it is possible to "poison" the cache of a DNS resolver with falsified information at any point in time independent of when the resolver starts looking for answers to queries it receives. These attacks enable hackers to misdirect all the thousands of users that connect to a specific (ISP) DNS resolver. In effect, it allows the hackers to point the Internet's road signs in the wrong direction.

DNS is literally everywhere (in your phone, your laptop, your car, the ATM you use and perhaps even your fridge), and this issue affects anything that uses DNS. So users may end up on phishing sites instead of their online banking site. Or their e-mail can be re-routed, their VoIP calls can be eavesdropped on, etc.

Restoring DNS integrity: DNSSEC

The only viable solution to restore DNS integrity is to use DNSSEC. DNSSEC uses digital signatures to guarantee the authenticity of DNS answers. In effect, it allows a resolver to validate the digital signature on an answer it has received thus proving that the answer does indeed come from the owner of the DNS zone that was queried.

Thus, DNSSEC puts a seal of authenticity on the Internet's road signs allowing those that read these signs to check that they are the real deal.

So let's deploy DNSSEC?

Well, it is not that simple. As was already mentioned in the introduction, DNS is highly resilient and vastly distributed. This has two consequences:

1. Because it is highly resilient, it is very fault-tolerant, and because it is very fault-tolerant many organisations do not invest much in DNS management; far too often the DNS server is "that old workstation that sits in the corner of the IT department's office" and is managed by the junior sysadmin fresh out of school
2. Because it is vastly distributed, there are many parties involved in introducing DNSSEC

As it turns out, it is a lot harder to manage a DNSSEC signed zone than it is to manage an ordinary DNS zone. System administrators suddenly have to deal with things like key management, key rollover, communicating key material to parent zones, etc. So right now, DNSSEC is not for everyone. The situation is improving, though. There's a lot of work being put into creating good tools that make managing DNSSEC signed zones a lot easier, both by the open source community as well as by commercial vendors.

And let's not forget that DNS has two sides: the authoritative side, which provides the answers and the resolving side that asks the questions. So deploying DNSSEC not only means signing zones, it also means checking the signatures on a resolver. Deploying DNSSEC on a resolver is a lot easier than signing zones, so this is something that can already be done on a larger scale. Although the root zone is not signed yet, initiatives such as DLV by ISC and ITAR by IANA make it viable to deploy validating DNS resolvers.

SURFnet's take on DNSSEC

In order to allow our end-users to benefit from the deployment of DNSSEC we have enabled DNSSEC validation on our resolvers. This means that our resolvers always validate queries for domains that have been signed using DNSSEC. Thus, users automatically benefit whenever a new domain is signed using DNSSEC.

We are currently working on integrating DNSSEC support into our managed DNS system. This system allows the institutions connected to our network to manage their DNS zones using a web portal. By integrating DNSSEC support into this platform, we make it easy for them to sign their domains without having to take care of all the complex management necessary to operate a DNSSEC signed zone.

What can you do?

The first step that almost anyone can take is deploying a validating resolver. Almost all currently available resolver software supports DNSSEC validation. Right now, you would still have to use interim solutions like DLV or ITAR to bootstrap the trust chains in your resolver, but soon that will be a thing of the past when the signed root zone becomes publicly available.

The next step is to learn how to operate a DNSSEC signed zone. There are many online resources available to help you with this and more and more companies are offering training programs.

Finally, you should find a good tool to help you manage your zone and start signing.

About SURFnet

SURFnet develops and operates innovative services for higher education and the research community in The Netherlands. We focus on network infrastructure, authentication and authorisation services and multimedia platforms for online collaboration. About one million end-users access our services on a daily basis. SURFnet is part of SURF, an organisation in which universities, polytechnics and research institutions collaborate on groundbreaking ICT innovation. SURFnet has been a leader in ICT innovation in The Netherlands for over 20 years.

Close

Paul Vixie is President of Internet Systems Consortium (ISC), a non-profit corporation dedicated to developing and maintaining open source reference implementations of core Internet protocols. ISC maintains the BIND nameserver software; a DNSSEC DLV Registry; and the distributed collection of F-root DNS servers worldwide.

Date added: August, 2008

DNSSEC is a colossal flop, but not a mistake. It's an embarrassment, but we'd do it all again if we had to. It's late -- it was started years before the IPv6 effort but is (believe it if you can) even less finished and less deployed than IPv6. It's ugly and complicated and if we knew then what we know now we'd've scrapped DNS itself and started from scratch just to avoid the compromises we've made. But we didn't know then, etc., and what we have to do now is avert our gaze and fully deploy this ugly embarrassing thing.

Let me explain.

In distributed systems like DNS, there are two ways data can be corrupted and therefore two ways that corruption can be prevented. End to end, and hop by hop. In 2008 the blogs are awash with articles about Dan Kaminsky's latest DNS flaw, which is in the hop by hop part of the system. Protecting against hop by hop damage desperately wants a protocol change, which we can't find a way to do without breaking backward compatibility to hundreds of millions of DNS clients and name servers. UDP port randomization is ugly and expensive and is at best a statistical stopgap that doesn't really get us out of the woods. But in 2008 it's all we can think of, so we're doing it.

But everything we've learned about telecommunications in the last few decades is that networks should be stupid and endpoints should be smart. Why are we trying to protect the hop by hop part of this, which is the network, rather than protecting the end to end part, which is the endpoints?

Ugly old DNSSEC signs data when it comes into the system, and validates it when it comes out the other side. Any hop by hop damage or attacks will be seen by smart endpoints as bright glowing failures. This is important for two reasons.

First, because the attacks or damage you're hoping to avoid might not be happening in the hop closest to you, and the folks farther away might be less careful about their hops than you are about yours. (The least reliable part of the internet is OPN's -- Other People's Networks.) Second, because there are some very interesting hop by hop protections which rely on the end to end nature of DNSSEC for distributing their private keys. In other words if we had deployed DNSSEC before 2008, Dan Kaminsky would have had a hard time finding a problem, but if he had still found one, we could have solved it with SIG(0).

So, if DNSSEC could help us so much, why don't we have it? Four reasons:

1. There's a significant last-mover advantage. Early deployers spend a lot of time and maybe some money and get no benefit except their training and the knowledge that somebody's got to be first or nothing ever gets done.

2. The root zone is tied up in all kinds of politics. Maybe ICANN has permission to sign it, maybe they don't. A lot of people seem to be more worried about an ICANN/USG empire than they are about the security of DNS, and those people have the power to slow things down, even prevent movement. And without a signed root zone, DNSSEC is all dressed up with noplace to go.

3. It's been thirteen years since the first DNSSEC mailing list was set up and about four times in those thirteen years IETF has declared victory only to discover that the stuff didn't work well outside the lab. Credibility is quite deservedly low. Saying "this time for sure!" only works N times.

4. There's no value chain. Registries don't make more money when they implement DNSSEC, nor do registrars, nor do registrants, nor do end users. The only incentive is by vendors who may hope to recoup their investment in implementing this stuff by selling software, devices, and support to folks who may want to deploy it. This is a very weak story.

In spite of all that, I'm asking your indulgence. Be an early deployer, help create a validator population and a secure zone population that others will see and be heartened by. Give the last-movers their advantage, take your payback in the form of satisfaction and early-adopter expertise.

Close

Anne-Marie Eklund-Löwinder is Quality & Security Manager at .SE, the organization responsible for the Swedish ".se" TLD.

Date added: September, 2008

There's more to DNSSEC than a signed zone

As the world's very first Top Level Domain, Sweden offered DNSSEC as a service for the .se ccTLD. In 1999, we started by running a project that led to signing the .se zone in September 2005. After a quiet period of three months, we released several test domains with signed delegations. Since everything proceeded as planned, the key administration was gradually integrated into the existing registry system, and domain name holders were themselves able to administer their DNSSEC keys through "Keyman", a secure key management system that we developed in-house.

In February 2007, DNSSEC was launched as an additional service to domain holders through services from some of .SE's registrars. The aim is that .SE's DNS service should be not only highly robust and available, but also trustworthy. .SE's vision for 2011 is that DNSSEC shall be a natural part of the DNS, used by all important .se domains and supported by several applications.

Planning and Development

To provide DNSSEC as a service, several issues have to be considered. Many of them are the same, regardless if it's a TLD that provides the service or a small DNS Name Service Provider just hosting DNS for a few domains.

Systems, policies, and routines for key management and signing of the DNS data, have to be developed. When .SE developed its service, the main goal was to maintain the high availability on its ordinary DNS services and at the same time get a highly secure new DNSSEC service. Since no suitable software was available for key management and zone signing at that time, .SE was forced to develop its own system.

Another challenge for .SE -- as a pioneer -- has been to get the market for DNSSEC started. Back in 2006, .SE did a market survey among .SE registrants and found a very positive attitude towards the use of DNSSEC technology. This attitude has been confirmed in the ongoing contacts and discussions with registrants since then.

This means we had a TLD providing DNSSEC and customers desiring it. But that still isn't enough. Each registrant also needs a DNS Name Service Provider. This is because DNS as well as DNSSEC are administered in a distributed way. The task for a TLD is to provide the addresses to the registrants' DNS Name Servers. It's not the TLD's responsibility to handle the registrants DNS data.

The DNS Name Service Provider is the party that actually handles the registrant's DNS and DNSSEC data. Today, most registrants don't run their own DNS Name Server. They are often run by an external DNS Name Service Provider which could be a registrar, a web host, an outsourcing partner, etc. Only a few of them are actually offering DNSSEC services today, which is an obstacle for the deployment of DNSSEC.

Because of the complexity of DNSSEC, the DNS Name Service Providers need easy to use and reliable administrative tools. For the deployment of DNSSEC, a good supply of commercial and open source tools is crucial. There are already some tools available, and .SE has good experience with some of them, but more scalable and better tools are still needed.

Creating user value

DNSSEC is probably not the solution to any of the top priority security issues on the Internet, like malicious code and malware such as trojans and worms, distributed through phishing websites and spam. But it is an interesting new layer of infrastructure which provides a solution in the long run. DNSSEC also increases the possibility to support different defense layers. And like all new infrastructures, the value of DNSSEC increases with the number of users participating.

The real value of DNSSEC is obtained when Internet users actually validate answers from DNS lookups, to ensure that they originate from the right source and haven't been altered in transit. Validation can be handled in different ways. One common wish is that the validation should be performed by the end user's application and that the end user should be informed of the result -- similar to the small padlock icon that is shown in the web browser, when a secure SSL session is established. Applications already exist that do DNS lookups together with DNSSEC validation, but DNSSEC is not yet supported by most common applications.

Validation can also be done by the user's local DNS resolver. For the ordinary broadband customer, this resolver is typically provided by the user's ISP. For the Swedish DNSSEC project, it has really been encouraging that the major Swedish ISPs have turned on DNSSEC validation in their resolvers and are actually doing the validation for their customers. This is a good start, while waiting for DNSSEC support in end-user applications.

Another conceivable use for DNS -- now it may be signed -- could be as a repository to store a variety of other security attributes used by other applications, since the data may be protected from tampering.

The years to come

.SE will continue its work on making DNSSEC a natural part of DNS, used by all important .se domains and supported by useful applications. To get there, we will continue to develop the market, systems and applications. The market development will comprise activities to stimulate our registrars to offer DNSSEC services and to promote the use of DNSSEC tools among DNS Name Service Providers. Together with other TLDs, we will also continue our system development, to make key management and the zone signing process easier and more effective. Finally, we shall also promote applications that have great benefit from using DNSSEC.

We are very pleased that the IETF (The Internet Engineering Task Force) now has completed and published "NSEC3" (RFC 5155). The NSEC3 Resource Record can be used as an alternative to NSEC, to mitigate zone enumeration issues. This is an improvement of the DNSSEC standards that many TLDs have been waiting for before deploying DNSSEC. This makes us even more confident that we now will have a broad cooperation among the internet community to realize DNSSEC for the entire Internet.

Signing the root

As one of the very early adopters of DNSSEC, we are concerned about the slow progress of the DNSSEC deployment efforts. We believe that successful deployment of DNSSEC is crucial for the continued stability and security of the Internet. As this is contingent upon a signed DNS root zone, we have urged ICANN to speed up and improve its efforts to quite rapidly migrate to a signed root zone.

Bearing in mind the vulnerability in DNS detected by Dan Kaminsky, we believe that the Internet now has reached a point where DNSSEC offers a solution in the long run. The absence of a signed root zone is no longer only merely unfortunate. Rather, the absence of a signed root zone directly contributes to the development of inferior alternatives, thereby confusing the community and jeopardizing the long term success of DNSSEC deployment.

Close

Mark Beckett is VP of Marketing at Secure64 Software Corporation, a company that develops software for automating the implementation and management of domain name system security extensions (DNSSEC).

Date added: August, 2008

To those individuals that have been involved in the effort to secure the DNS since its inception, reviewing its progress to date can be depressing. Ten years, numerous RFCs and thousands of man-years later, what do we have to show for it? Miniscule adoption across the globe.

To some, this is a dismal failure. I disagree. I think we are right on track.

DNSSEC is no different than any other technology exhibiting a network - effect that is, a technology whose value increases with the number of organizations that adopt it. Think telephones, fax machines, and the Internet itself. What do we know about the adoption of these technologies?

1. Adoption over time follows an S curve in which it takes a long time to reach very small penetration, but once a certain critical mass point is reached, adoption accelerates rapidly, ultimately reaching almost 100%.
2. It can take many years to get to critical mass, but the amount of time to get there is not a reliable indicator of the technology's ultimate success.
3. Adoption initally occurs in smaller communities that can derive benefit from the technology. These small communities provide the catalyst to reach the critical mass point.
4. The lower the cost of adoption, the faster we get to critical mass.

We are now at the point where individual communities can deploy DNSSEC at a reasonable cost, derive significant benefits, and start to propel us towards that critical mass point. Here is why:

1. Awareness of DNS security issues is at an all time high. The recent DNS vulnerability disclosure and subsequent worldwide patching effort has emphasized just how critical the DNS infrastructure is. And the patch is advertised as a stopgap measure until we get DNSSEC in place.
2. Validating caching server deployment costs are down. Thanks to the recent DNS patching effort, we are now running DNSSEC-ready caching servers in virtually every one of the world's major ISPs and enterprises. The only remaining caching-side costs involve turning DNSSEC on (a one line configuration change) and seeding it with at least one trust anchor. So far, neither the administrative overhead of managing a single trust anchor nor the computational overhead of DNSSEC validation has proven to be a significant hurdle to overcome.
3. Zone signing costs are down. Commercial products are now available that automate key management, key rollover and zone signing, greatly decreasing the cost and risk associated with manual key management and zone signing. This makes it possible for organizations to deploy DNSSEC in days or weeks rather than months or years.
4. Privacy concerns due to zone walking are addressed. NSEC3 is now an RFC (5155) and is supported by both open source tools and commercial products.
5. We don't need to wait for the root to be signed. A single ccTLD trust anchor is all that is required to secure many of the DNS transactions that occur within a country (the U.S. being the single exception to this rule). Similarly, a large enterprise can deploy its own trust anchor to its caching servers in order to fully secure its internal DNS.
6. Momentum is building. DNSSEC is already deployed within Sweden, Brazil, Bulgaria and Puerto Rico. This list of ccTLDs will undoubtedly grow as the next wave of adopters moves from test systems to production. In fact, 85% of ccTLD registries surveyed in October 2007 planned to deploy DNSSEC, and 45% of these planned to deploy within two years.

Does this mean that we are done? Of course not. Yes, we want the root to be signed. Yes, we want end-to-end security. Yes, we want more automated ways to maintain chains of trust. But with these recent developments, real progress can now be made. These early successes will lead to more adoption, ultimately propelling us to that point of critical mass and beyond where eveyone connected to the Internet enjoys the trust that DNSSEC can provide.

Close

Ron Aitchison is author of the book "Pro DNS & BIND", published by Apress, and President of Zytrax, a Montreal based company that specializes in wireless and wire-line IP communications.

Date added: September, 2008

DNSSEC - Prevention really is better than the disease

It seems that most domain owners are currently choosing to take the risk of being poked in the eye by the sharp stick of cache poisoning and other DNS attacks rather than implement DNSSEC. While this may currently appear a reasonable policy - DNSSEC is not a trivial implementation, there is arguably little supporting infrastructure especially signed TLDs and there appear to be limited threats - all this can change in a heartbeat. As an example you may recall that Mr. Dan Kaminsky found a pretty serious DNS problem pretty recently - but he is a good guy and told everyone. Not everyone is a good guy. In my opinion not implementing DNSSEC now is also a very short sighted policy for four reasons.

1. CYA

If you are poked in the eye with the sharp stick of cache poisoning or domain hijack you are going to be sitting there with your revenue earning web-brand reputation in the toilet, perhaps not even trusted by your close family. Just how long does it take to recover from that situation - weeks, months, years. And sooner or later someone will ask the dreaded question 'was there nothing we could have done to prevent this'. Ritual suicide may be the best option at this point.

2. One step at a time

DNSSEC implementation is not trivial - even with the increasing number of tools, both commercial and Open Source, being made available. It needs careful planning and good operational practice. Simply signing your zone and getting used to the additional time-based disciplines involved with key-rollovers gets good operational experience under your belt - even if you don't distribute trust anchors or DS records. The downsides are also modest now - your domain will not go dark if you get it wrong. When your TLD parent signs you merely need to take an additional step to join the chain and distribute updated DS records. You can even start experimenting with other users within common-interest groups or affiliations. You control the timeframe and therefore the resources being expended. Low risk, prudent implementation.

3. The Big Stick

In these times of sadly increased international tension governments are looking hard at what they can do to protect national assets in the event of cyber threats. While the US Government may well be leading the way it is by no means alone. Any government which is not seeking to protect its critical infrastructure - which typically includes much that lies in the private sector such as financial services and energy among others - is failing its citizens. How long will it be before governments mandate DNSSEC for certain industries? All you can be sure about is that if, when, it does happen it will come at the worst possible time. And you will probably have to do it much faster than you would wish. The positive side is that may get to do that great headless chicken imitation that you have been dying to show the world for years.

4. Enlightened Self-Interest (Money)

Finally and in my view the best argument for doing something now rather than later is that you might be able to save yourself a ton of money. Here's why. DNSSEC creates a trusted network of domain owners. Using this trusted network DNSSEC ensures that data stored in the DNS that is delivered to a security-aware end user came from the domain owner and was not tampered with. That is essentially what a SSL certificate does for domain based purposes such as securing web sites, ftp sites, VPNs and even email. So if, in return for joining a DNSSEC trusted domain and even being stiffed serious money by your domain registrar for doing so, it would enable you to generate unlimited self-signed SSL certificates whose status I have argued elsewhere is approaching, perhaps equivalent to, current EV SSL certificates costing perhaps $500 - $700 a pop annually you could save yourself a ton of money. Even with basic certificates at $50 - $150 a pop annually you can still saving serious cash. I'm sure there are even better cost saving ideas that could gain leverage from the DNSSEC trusted domain owners network once it is securely in place - perhaps DomainKeys secured email becomes viable.

But wait a minute, all this requires DNSSEC infrastructure, browser changes here and secure resolvers there and...and... Not the point. The point is that if domain owners take an interest in DNSSEC now, simply start signing their domains (a low risk and sensible starting point), start demanding action the better registrars will see a market - because if they don't someone else will eat their lunch - and all that other stuff will magically fall into place quicker than you ever thought possible - just the way it did when SSL was introduced all those years ago. However, if domain owners continue to sit back and do nothing - guess what is going to happen - nothing. Until, that is, you get a government mandate slapped on your desk - or you get poked in the eye with the sharp stick of a cache poisoning attack.

Close

D. Ikonomou and P. Saragiotis are Security Experts at ENISA, the European Network and Information Security Agency. ENISA is a Centre of Expertise for the EU Member States and EU Institutions in Network and Information Security, giving expert advice and recommendations.

Date added: September, 2008

ENISA's work with DNSSEC

The European Network and Information Security Agency (ENISA) is executing a Multiannual Thematic Program (MTP) with the ultimate objective to collectively evaluate and improve the resiliency of public eCommunications in Europe. Public eCommunications network is every electronic communications network that is used for the provision of publicly available electronic communications services. Internet access and backbone networks, fixed line and mobile voice networks are examples of public eCommunications networks.

By the term resilient we characterise the networks that provide and maintain an acceptable level of service in face of faults (unintentional, intentional, or naturally caused) affecting their normal operation. Improving the resilience of a network is an issue of risk management which includes risk identification, evaluation and acceptance or mitigation. A wide accepted list of risks to the resilience of networks includes flash crowd events; cyber attacks; outages of other support services; natural disasters and system failings. The mitigation of identified risks involves technical measures such as resilient design; resilient transmission media; resilient equipment and technologies which improve resilience.

Against this background, ENISA is evaluating the impact that DNSSEC, along with other selected technologies, would have on the resilience of public eCommunications networks. DNS is a very important system for internet communications and the resilience of such networks heavily depends on the resilience of this system. DNS is used today to translate names to IP addresses (e.g. 172.16.1.3), locate application servers (gmail-smtp-in.l.google.com), host blacklist tables. DNS could also be used for the storage and lookup of phone numbers and RFID's in the near future.

In order to assess the effectiveness of the selected technologies as well as problems and gaps that could potentially compromise the availability of networks and services, at first instance a number of interviews of network operators in EU Member States will be carried out. The analysis of the inputs collected is fed to the preparation of guidelines on the effectiveness of these three technologies especially in terms of their potential to improve the resilience of public networks (but also highlighting their shortcomings). The guidelines produced will be primarily addressed towards National Regulators and policy makers but also network operators. In the case that gaps are identified, then these will be addressed by the Agency depending on how the fit in its mission.

This procedure is supported by a group of leading experts that has been assembled by the Agency. Experts from the industry, network operators and academia work together in this group to achieve the goals of the agency. This working group has already advised the Agency about the questionnaire that is used for the interviews, has identified interviewees and will assist the analysis of the collected input and the evaluation of the report.

The results of the stock taking activities carried out in the context of MTP1 as well as the possible directions in terms of recommendations that the Agency will follow in the course of next year will be presented in a workshop that the Agency is organising in Brussels on the 12th and 13th of November, 2008. At the same time the workshop will be used as an instrument to gather feedback from the relevant sector actors.

In 2009, ENISA will continue investigating possible ways for enhancing the resilience of public eCommunication networks, not limiting itself to technologies, architectures and protocols. In this context, incentives (on market and/or policy related aspects) will also be considered with a view on their impact on business practices and the associated regulatory framework.

See also, ENISA Press Release, 16th of September, 2008:

EU Agency investigates the potential to improve Internet security by protecting Domain Name Systems (DNS)

Update, January 2009

ENISA publishes report titled Resilience Features of IPv6, DNSSEC, and MPLS

Update, May 2009

ENISA publishes report titled Stock Taking Report on the Technologies Enhancing Resilience of Public Communication Networks in the EU Member States

Update, Nov 2009

ENISA publishes study on The Costs of DNSSEC Deployment

Update, Mar 2010

ENISA publishes a Good Practices Guide for Deploying DNSSEC

Close