As the industry-wide paradigm shift to cloud computing and software-as-a-service gradually continues to make the transition from buzz to reality, security and availability continue to emerge as the main barriers to customer adoption. A recent ISACA survey of over 1,800 US IT professionals found that only 17 percent believe the benefits of cloud computing outweigh the risks. Only one in 10 respondents said they would consider using software-as-a-service (SaaS) for mission-critical applications.

While some of this hesitance can probably be attributed to an overabundance of caution and the general human tendency to be wary of change, some security concerns are well-founded.

Companies entrusting their sensitive data to a SaaS provider need to be reassured that the data cannot be accessed by unauthorized third parties, such as employees and other customers of the provider, whether at rest or in transit. Data leakage has always been a potential issue at the low end of the hosting market – budget customers on shared servers – but the co-tenancy sometimes involved in cloud computing carries the perceived risk of bringing the problem to enterprises. SaaS providers need to be open and transparent with their customers about their security precautions, such as their encryption and access control regimes, as well as their layers of physical security.

There are other concerns, such as distributed denial-of-service attacks. As DNS service providers and others can attest to, when you have many thousands, or millions, of customer accounts running on the same infrastructure, you increase the risk of that infrastructure becoming the target of an attack. It's the old all-your-eggs-in-one-basket problem. To a DDoS-attacker focused on extortion, political retribution or simple vandalism, a broad customer base looks more like a convenient, aggregated attack surface. They can channel their resources on a narrower choke point, getting their message across by attempting to cause maximum collateral damage.

Of course, the opposite case can also be made: securing systems can be an expensive proposition, and companies can actually benefit from the substantial economies of scale that SaaS providers offer in terms of cost and security. Benefits include the availability improvements brought about by consolidated patch management, the economics enabling a much more diverse technology base that is less vulnerable to exploits, and the ability to quickly respond to DDoS attacks by reallocating resources.

It's important that both SaaS providers and their customers do not overlook reliable DNS provision as a key component of their overall security strategy. Companies can often blow their budgets on a super-redundant hosting infrastructure and forget about DNS – the only way their customers can actually reach it. Far too many times DNS is allowed to become the weak link in the chain, making it an ideal target for would-be attackers. All DNS services must come with a Service Level Agreement (SLA). Accepting anything less than 100% up-time for that SLA means you are accepting downtime for your business.

SaaS customers, however, often forget about DNS. Signing up for Google Apps, for example, is fairly straightforward and free, so it's easy to be quickly lured into a false sense of security, believing that your critical applications now reside on one of the world's largest and most robust data centers. This is of course not completely true. While cloud services such as Google Apps have brought many efficiencies to enterprises, they usually do not natively support DNS resolution. If you've forgotten to effectively provision your DNS, and it goes down, so does your Google Apps.

For a SaaS provider, surveys showing customer reluctance to adopt your services should of course be of some concern. But this hesitance also provides cloud computing companies with excellent opportunities to differentiate their services. When customers make buying decisions with security and availability as their primary concern, there's a clear incentive for SaaS companies to compete on security – a rising tide that carries all boats with it. 

Afilias plans to deploy Domain Name System Security Extensions in 13 more top-level domains 

DUBLIN, IRELAND  – 23 August 2010 – Afilias, a global provider of Internet infrastructure services, today announced that it will deploy Domain Name System Security Extensions (DNSSEC) across its registry platforms, signing 13 more top-level domains (TLDs) and increasing DNSSEC deployment among domain registries by 50 percent.

“Afilias has been a leader in DNSSEC deployment, including working closely with .ORG to plan, design and implement the .ORG DNSSEC strategy as early as 2007,” said Ram Mohan, Executive Vice President and Chief Technology Officer for Afilias. “We are pleased to introduce DNSSEC across our registry and DNS platform, protecting TLDs in our care from DNS cache poisoning and man-in-the-middle attacks, while maintaining consistency and convenience for registrars and their customers."

DNSSEC development began in the early1990s, but only recently became ready for broad deployment as an additional security measure to protect the DNS from cache poisoning exploits. Recently referred to as the Kaminsky bug, this exploit can allow malicious entities to intercept Internet users’ requests to access a website, and redirects or eavesdrops on these users without their knowledge, and with no ability to reassert control. DNSSEC introduces digital signatures to the DNS infrastructure and automatically ensures that users’ are not hijacked and taken to an unintended destination.

To deploy DNSSEC for these additional TLDs, Afilias is introducing a new global strategy, launched under its “Project Safeguard” initiative.  Project Safeguard includes a registry and DNS infrastructure upgrade across Afilias’ global technology platforms to support DNSSEC. It also includes a year-long registrar training initiative to address technical issues concerning implementation of DNSSEC in registrar-registry transactions.

As part of Project Safeguard, Afilias conducted research across domain name registrars to understand the issues they face with DNSSEC deployment. Afilias’ Registrar DNSSEC Readiness Report found that:·       

• Registrars think DNSSEC is a good idea, but are not yet fully prepared to offer consumer services.  80 percent of registrars believe that top-level domain (TLD) registries should offer DNSSEC. However 90 percent of registrars currently feel completely unprepared or only somewhat prepared to actually offer DNSSEC services to their customers as this time.        
• 69 percent of Registrars plan to offer DNSSEC services in 2011 or beyond. 32 percent have no plan to introduce DNSSEC within the next 12 months.      
• Consumer demand is the biggest challenge for registrars. 56 percent cite a lack of consumer demand as their biggest challenge impeding their DNSSEC implementation.       
• Registrars also cite issues with deploying DNSSEC technology:  For example, nearly 20 percent cite the management of DNSSEC keys as their number one concern, followed by more than 18 percent that cite overall DNSSEC technology and expertise.  

“Our goal is to help registrars navigate the challenges of enabling the next generation of Internet security with DNSSEC, by providing a simple and singular enablement process to easily deploy DNSSEC across Afilias-supported domain registries,” said Mohan. “The Project Safeguard initiative should ease the technical burden of DNSSEC deployment and could spur user adoption."

Afilias will deploy DNSSEC first in the .INFO domain in September, to be followed by TLDs that it supports in Asia, the Latin America/Caribbean, and Europe. Based on the proven strategy for the .ORG registry’s successful DNSSEC deployment effort, Afilias will adopt a similar, careful, step-by-step approach.  This strategy will include a “friends and family period” which will coincide with registrar outreach.

About Afilias

Afilias is a global provider of Internet infrastructure services that connect people to their data. Afilias’ reliable, secure, scalable, and globally available technology supports a wide range of applications including Internet domain registry services, Managed DNS, and services in the RFID and supply chain market with its Afilias Discovery Services. For more information on Afilias please visit www.afilias.info.

###

DNSSEC statistics source: DNSSEC Deployment Initiative https://www.dnssec-deployment.org/wp-content/uploads/2010/06/TLD-deployment-Table1.pdf  As of 13 August 2010 26 TLDs had deployed DNSSEC. 

If the rise of phishing has taught us anything, it's that on the Internet, if a digital asset has value, there's somebody out there who wants to steal it. Whether it's a bank account password, a credit card number, a PayPal login, or even a magic sword in an online game, there's a fraudster somewhere trying to misappropriate it for his or her own nefarious purposes.

Domain names have always been a target for such criminals. Companies and individuals doing business online have few assets more valuable than their domain name. It may cost $10 or less to register one, but the domain name is the glue that connects a company to its customers; revenue and brand equity depend upon its security.

Domain theft is not a new phenomenon, of course. Sex.com, for example, was hijacked all the way back in 1995, when there was only one registrar. Its true registrant had to spend years in court to retrieve it. In more recent years, high-profile domains such as Panix.com, Baidu.com and even ICANN.org have been temporarily stolen by attackers using social engineering to exploit process vulnerabilities at domain name registrars.

It's surprising, given that domain name hijacking predates the creation of the competitive registrar market itself, that the industry has not done more in the last decade to mitigate the risks. ICANN's Security and Stability Advisory Committee (SSAC) noted as recently as last year that "pure play, secure registration service providers are rare, in part due to the fact that evaluating security measures does not play as prominent a role in customer decisions when choosing a registrar as it should."

However, registrant apathy regarding security may already be changing, according to a recent survey of savvy registrants.

There are three areas where registrars, in general, have room for improvement when it comes to security.

1. Better Authentication

The simple username/password authentication approach so common at Registrars has repeatedly been found vulnerable to social engineering attacks and should not be considered strong enough security for high-value domain name accounts. This is especially true when automated password reminders are available. If all an attacker needs to do is compromise a password or e-mail address in order to have complete control over a domain portfolio, registrants have the right to ask for stronger authentication.

Nowadays, it's common practice for large financial institutions to allow, or even require, multi-factor authentication before giving customers access to valuable assets. But it's not just banks. After the phishing black market put a dollar value on World of Warcraft accounts, the game's developer had to start offering players one-time password tokens, in the form of key fobs, as a second authentication factor, to decrease fraud.

When you think about it, the fact that magic swords are sometimes offered a greater degree of protection than domain names is pretty crazy.

2. Notifications

When someone logs into a registrar domain account they are given virtually the “keys to the kingdom” for that organization’s entire domain portfolio and DNS settings. If domain account access is compromised, then all it takes for the criminal is to login to the registrar account, change the registrant and other contacts associated with the domain, and then either change the DNS information to point to a new site or transfer the domains to a completely different registrar where it is difficult for to reclaim the names.

It is time registrants get routinely notified when such changes are made to their domain name portfolio, whether via e-mail, text or perhaps even telephone for the most critical items. The best scenario is to notify two or more authorized employees to provide for shift changes and/or redundancy. Social engineering is the attack of choice for hijacking domains, and it's harder to impersonate two people than one.

Because e-mail accounts are easier to compromise than phone numbers, using out-of-band communications channels, such as telephone or SMS text message, could also increase security.

3. Access Control

Usually, authenticated registrants have global privileges: they can change name servers, transfer out domains or cancel renewals, for example. The risk of domain hijacking could be further mitigated by employing more granular access controls once a customer has been "authenticated". Many registrants may wish to use a higher level of security on their primary domains, limiting critical privileges to certain high-status users. The learning curve here could be eased somewhat by the fact that existing registrar Whois records already usually describe at least three roles – the administrative, technical and billing contacts.

Registrars should enable Registrants to designate different contacts for different authority levels. This would accord Registrants the choice of better protection.

 

None of these measures need to be a drain on registrars' margins. Indeed, once in place, these will save money that is now spent resolving disputes after the fact by making criminal activity more difficult. Further, with domain name registrants increasingly looking at registrars' security provisions before they make their purchasing decisions, the opportunity presented by value-added premium services, designed for security and marketed to customers with high-value domain portfolios, should be obvious. Criminals look for the softest targets; with a little effort in just 3 areas, registrars can significantly improve the security they provide for registrants.

For more reading on this topic, see SSAC’s advisory to registrars on improving security: SAC040

(Disclosure: I am one of the charter members of SSAC)

Hosting companies face many challenges today, from differentiating their services in a crowded market with decreasing margins, to an increasing pressure to defend against growing sets of attacks against their infrastructure. As more and more services drift into the cloud, up-time is becoming one of the most critical factors for customers choosing a web host. A hosting company’s record of reliability can often be the deciding factor for a customer to choose one service over another. Recently at HostingCon, Afilias was able to talk to hosting companies about their current DNS problems and why they need to now look at advanced DNS solutions to improve reliability or to seek new revenue with premium DNS offerings.

What we’ve been saying for some time now was confirmed by many of the hosting companies visiting and exhibiting at HostingCon. Over the last year we’ve seen an increase in size and number of attacks against the DNS. Both continue to grow as criminals seek any way to exploit vulnerabilities in networks. DDoS attacks against DNS infrastructure as well as sophisticated DNS hijacking attacks are now top of mind for most hosting companies.

Recent research from Arbor Networks shows that the risk of DDoS attack is by far the most worrying problem facing companies today, with 35% of organizations classifying such attacks as their biggest fear. The same research shows that over a quarter of all DDoS attacks target application-layer protocols such as DNS, with the largest attacks amounting to almost 50 Gigabytes per second (Gbps).

Here are some suggestions we have for hosting companies to not only improve their DNS architecture, but also how they can utilize a more superior and reliable DNS network to expand the services they currently offer today:

Add a secondary DNS provider to shoulder the load

An attack against a single hosting customer can severely impact performance and availability for a hosting company’s entire network, especially when a DDoS flood is large and targets a shared network bottleneck such as DNS resolution. Every customer who puts content online, blogs, or shares links to your hosted sites in social media, creates a target that could put your entire customer base at risk.

The risk of taking out an entire set of customers based on the target of just one popular or controversial customer, presents a greater need for hosting companies to harden their DNS infrastructure from attack. Rather than bearing the added capital expense of building out a bigger DNS network, simply integrating a second DNS provider to serve part of your DNS traffic can alleviate bottlenecks in your current DNS infrastructure and give you an entire second network to rely on incase of a crippling DDoS attack.

Indeed, we’ve even seen some customers reap additional positive outcomes of integrating a secondary DNS provider. This approach allows them to seamlessly take out any or all of their own DNS nodes for planned or unplanned maintenance or even deploying critical patches.

Strengthening your network with Anycast

Of course, the DDoS problem is not confined to DNS alone. DNS is just one piece in the overall architecture of a hosting company. However, DNS is one area that is often not provisioned as well as other, more obvious, pieces of potentially vulnerable infrastructure. The risk of attacks taking down DNS for all hosting customers can be substantially mitigated by building out a robust DNS infrastructure that uses a diverse selection of technology providers and is globally distributed using IP Anycast.

Anycast enables companies to advertise the same IP address from multiple nodes, deployed on different parts of the Internet, simultaneously. In the DNS context, this allows companies to present a more localized way to resolve domain names, reducing latency and increasing performance for end users, while mitigating the impact of one node going down for maintenance or due to attack.

Don’t run a monoculture – integrate diversity

The number of vulnerabilities found in ubiquitous data center hardware and software platforms is forever increasing, and is expected to double this year compared to 2009. Companies that have adopted software monocultures, or failed to incorporate enough vendor diversity in their DNS architectures, could find themselves more at risk from exploitation. By also introducing some of Afilias’ principles of DNS Diversity, where each node is provisioned by more than one connectivity provider, and uses more than one vendor for each of its operating system, name server, server hardware and network infrastructure needs, single points of failure in your DNS are virtually eliminated.

Premium DNS is a selling feature

Advanced DNS not only does not need to be a cost center, it should also be viewed as an opportunity to increase revenues. As your customers’ businesses depends more on their Web services, they are aware of just how critical the availability of their website actually is. Customers that want to safeguard their e-commerce revenue will pay for Service Level Agreements (SLA) and guarantees on their DNS resolution. Even a marginal increase in your per month hosting fee could be just enough to differentiate a premium DNS package, and collectively across your customer base can present an easy added revenue stream to help your bottom line this year.

How can better DNS be easy for hosting companies?

DNS shouldn't have to be a choke-point or vulnerability in a hosting architecture. Nor should it be a headache for network administrators to provision, manage and secure. With Afilias’ new FlexDNS Platform, we're offering hosting companies or other resellers three easy ways (Web portal, AXFR, or an API) to integrate with a massively diverse, flexible and distributed DNS network that guarantees 100% availability. Using Anycast, the Afilias network provides bulletproof DNS resolution from widely dispersed nodes on multiple continents, using multiple backbone providers and a diverse array of technology providers, creating a level of robustness and redundancy that would be prohibitively expensive for many hosting companies to deploy themselves in-house.

Almost exactly nine years ago, the .INFO domain first started accepting registrations.  This was an historic event as it was the first time a new generic top-level domain (TLD) was launched to an existing domain marketplace and, in fact, was the first new TLD to be added since .com.  We’ve seen (and provided technology to power) many other TLD launches since then, with many business models.  As you seek to introduce your own new TLD however, you should carefully evaluate the different launch models that have been tried before and determine which one will work best for your specific TLD.

Trademark Protection
All new TLDs will require some form of trademark protection to ensure that Intellectual Property (IP) holders’ rights can be protected prior to live, public registrations.  Afilias has implemented a number of different types of trademark protection plans from pre-registration without trademark verification, to those with extensive application and verification processes.  We’ve seen the best success with a very focused trademark pre-registration period that has clear trademark parameters and works with a known trademark verification agent to weed through all of the submissions.  We also recommend that all registries lock pre-registered trademark domains for up to 60 days following their registration award to allow for any potential UDRP claims that IP owners may wish to file.  

Landrush
Landrush will be the most critical time for your TLD as it places the heaviest load on the technical registry system.  We’ve seen in excess of 300,000 names coming in through initial landrush opening minutes, so you want to be very careful about who you select as your registry partner.  You should make sure that their registry has been tested to withstand a significant landrush load.

In addition, you will have to make some policy decisions about how you want landrush to work. In almost all cases you should avoid pre-registration fees with a “chance” at getting your name. These can be viewed as lottery-based systems that can subject your organization to new legal restrictions.  We highly recommend that clients not charge for applications, but only for awarded names.

Regardless, you need to decide if you will open the floodgates all at once, or if you want to have multiple, specialized application periods (see below) in advance of the “public” opening.

Premium Names and Auctions
In recent years TLDs like .info, .mobi, .asia and .me have seen good success by reserving premium names, which are highly desirable generic or category terms.  In .info’s case, we reserved a number of country domains and have awarded them for use by their respective governments (some great examples are spain.info and germany.info).  Other TLDs have used reserved name lists for auctions following landrush.

Premium or other reserved names can fit well into your new TLD’s strategy, particularly if you will be representing a certain category or key community where they will present more value.  An auction approach helps to raise the price, and therefore perceived value of these names, and can help put your registry on a sound financial footing more quickly.  

RFPs
If auctions are not to your taste, other domains have also seen success by simply launching a period where interested users can respond to a “request for proposal” with a business and launch plan for a highly desirable name.  As a registry, you can offer additional promotion, partnerships or advertising to help assist with the launch of these sites, which can also act as great brand ambassadors for your fledgling TLD.

 

Each new TLD will have its own priorities. However, at the end of the day, you need a plan that will get lots of names into your target market quickly, generate awareness of your TLD (so it will be viewed as a legitimate place to visit by Internet users), and demonstrate actual use in the market (i.e. real sites and e-mail).  Your launch plan is critical to establishing these building blocks quickly. If you are not a TLD expert, consider teaming up with someone who has been there before.

Afilias' James Galvin will be moderating a panel entitled: e-Crimes and Malicious Use in the DNS: Implications and Observations at the IGF USA conference to be held at the Georgetown Law Center.

This session covers some of very real time examples of the fight against DNS‐related abuse such as phishing, malware and fraudulent uses of domain names. The panel will also comment on the scope and growth expected in various kinds of fraud and abuse as the domain name space continues to grow exponentially.

• ‹ previous
• 72 of 78
• next ›

Afilias' James Galvin will be the main speaker at this Information Systems Security Association event on DNSSEC. The seminar will highlight the advances being made in DNS security, particularly in the adoption and availability of DNSSEC, the DNS Security Extensions. The event will be held at the Camden Court Hotel in Dublin. More info and registration details can be found at the link above.

The application period for the next round of new top-level domains moved one step closer to commencement after a productive and well-attended ICANN meeting in Brussels last week.

The board resolved on Friday to dedicate its two-day retreat in September entirely to working on the issues that remain outstanding in the Draft Applicant Guidebook. The current version of the DAG, the fourth, is expected to be the final draft before applications become open to potentially hundreds of prospective new TLD registry operators.

ICANN Chairman Peter Dengate Thrush said the final Applicant Guidebook could be ready or almost ready for approval as early as December this year, when the ICANN community will meet in Cartagena, Colombia. Companies wishing to apply for their ".brand" TLD in the first round could find themselves able to do so in the first half of next year and should start their planning process now if they have not already.

However, because ICANN is a bottom-up policy-making organization, there are still issues that the community needs to resolve before the board can act. The procedures for providing intellectual property protection to trademark holders have almost been finalized, and the ICANN Governmental Advisory Committee has been asked for further guidance on how to handle its concerns about "morality and public order" in new TLDs. Registries and registrars are also continuing to make progress towards a consensus view on cross-ownership and vertical integration.

One key element of the new TLD process is the requirement that all new TLDs incorporate DNSSEC at launch.  DNSSEC took another significant step forward at this meeting with the signing of http://www.isoc.org/ as the first second level .ORG to be secured by this new security protocol.  The .org TLD is the largest TLD to date to deploy DNSSEC at the zone level; and the http://www.isoc.org/ signing paves the way for EVERY .ORG to be secured via DNSSEC.

There was also good news in Brussels for the world's over one billion Chinese speakers, as the ICANN 

Board voted to approve three Chinese-script internationalized domain names for addition to the root. The country-code managers for China, Taiwan and Hong Kong, who received standing ovations following the Board's decision, will soon be able to distribute addresses ending in their IDN scripts.  These TLDs will join several other country-specific strings that were applied for in the "fast -track" process approved at the Nairobi meeting.

Attendees at the public ICANN meeting in Brussels today heard from over two dozen companies that have implemented or are planning to support DNSSEC, the next-generation standard protocol for secured domain names. It is clearer than ever before that DNSSEC is becoming a reality.

The Public Interest Registry announced that as of this morning the .ORG top-level domain, for which Afilias provides the technical infrastructure, has finalized its deployment of DNSSEC.  Registrants of .ORG domains will now be able to generate keys and sign their zones via participating registrars. The Internet Society's ISOC.org address became the first to go live in production, signing their name with their sponsoring registrar NamesBeyond.  NamesBeyond also became the first registrar to offer complete DNSSEC deployment in production and presented an easy-to-use user interface design.

In her comments, Lynn St. Amour, the President and CEO of the Internet Society said that she was pleased to be the first organization in the .ORG  top level domain to deploy DNSSEC.  She said that implementing DNSSEC for the .ORG top-level domain was an important step in ensuring that the Internet serves as a trusted channel for communication and collaboration.

Indeed, the deployment of DNSSEC is one of the most important developments in .ORG's 25-year history and their visionary efforts have pushed an entire industry towards adoption.

GoDaddy publicized its commitment to DNSSEC at the ICANN meeting, telling a crowded meeting hall that it will offer a managed DNSSEC service to its customers later this year. An additional 11 registrars have completed operational testing to offer DNSSEC-signed .ORG domains to their customers.

With ICANN due to sign the DNS root next month, the chain of trust on the Internet is almost complete, all the way from the root to the ISP level. Comcast, which spent over two years testing its own DNSSEC validating resolvers prior to deploying earlier this year, announced today that it will also sign some 650 of its own .ORG domains.  Jason Livingood from Comcast encouraged other ISPs to begin their own DNSSEC trials and to rollout DNSSEC in their production resolvers.

While many at the ICANN meeting also heard about the technical challenges of implementing DNSSEC at the registrar and registry levels, and the competitive advantages that can come from being an early adopter, the general consensus emerged that DNSSEC is now something which every player in the domain name industry needs to address.

Paul Vixie, the Chairman of Internet Systems Consortium, which develops BIND software told the workshop that the community was near the tipping point with the root, .ORG, .COM and .NET all being signed or going to sign soon.

ISOC, PIR and Afilias team at the signing of isoc.org this morning at ICANN 38: Brussels.
(Left to right) Back row: Roland LaPlante & Dr. Jim Galvin from Afilias. Front row: Alexa Raad, PIR CEO, Leslie Daigle, ISOC CITO, and Lynn St.Amour, ISOC CEO.

The barriers to DNSSEC adoption are quickly disappearing. There are nearly 20 top-level domains that have already deployed DNSSEC including generic TLDs like .org and .gov. This July, the DNS root will also be signed, and will begin validating DNSSEC queries. At this point, the decision for remaining TLDs to deploy DNSSEC is really no longer a question. In fact, as it stands today, all new TLDs approved by ICANN will be required to have DNSSEC deployed at launch.

Afilias already supports .ORG’s deployment of DNSSEC and provides secondary DNSSEC service for other ccTLDs. Our experience in deploying DNSSEC demonstrates that you need to plan for an increase in strain on your DNS network if your ccTLD or gTLD plans to deploy DNSSEC.

Deploying DNSSEC will have three main effects on your DNS operations:

Larger Zone File Size

For every signed domain, your zone file will now have to store and provide not only the original DNS information such as Start of Authority (SOA) and other Resource Records, but also a digital signer record (DS) to point to the Public Key as well as the actual signature record (RRsig) for each RRset in your zone file for which you are authoritative.

On average, you should expect your zone file to increase 4-6 times its current size.

More than 50% of the DNS traffic Afilias serves today already requests DNSSEC information. When you sign your zone, you will be serving signature information immediately.

Delivering a larger zone file that is serving more records for every DNS query will increase the daily strain on your DNS servers, and could result in increased response times.

Greater Bandwidth Requirements

DNSSEC-enabled responses contain more information because they are now carrying an additional set of information (signatures and keys) that go along with every DNS query. On average, a DNSSEC response is about twice the size of a non-DNSSEC response.

You will need to factor in more bandwidth and processing power to handle larger responses for each DNSSEC query that you need to serve. Some of this is dependent on the DNSSEC configuration choices you make.

While our experience shows that the bandwidth increase associated with a signed zone is not orders of magnitude higher than an unsigned zone, we recommend that you plan for at least a 2-4 times increase in bandwidth required to respond to normal DNS query volume.

Increased DNS Traffic

There are a few reasons why you may see an overall bump in DNS traffic just because you enable DNSSEC.

DNS uses UDP, a lightweight protocol, to return responses for most DNS queries. BIND 9.4.x and earlier versions limit UDP responses to 512 bytes. Since DNSSEC information is larger, responses can be truncated, thereby forcing validating resolvers to ask for the DNSSEC information again using TCP. Most signed TLDs to date report a 1-2% TCP traffic increase overall.

 

Solving for these three significant operational impacts could cost you time, money and pull your resources away from other critical projects. And, it may even deter you from implementing DNSSEC even though it has become an essential part of TLD management.

We would like to suggest a simple solution that will lighten your load: back-up your DNS with a Secondary provider.

Why? It will reduce your overall risk by offloading part of your traffic onto someone else’s network that has already planned for higher peak capacities. It provides a more economical solution by minimizing the overall expense and capital requirements to expand your existing DNS network. And more importantly it provides a virtual insurance plan against unexpected traffic spikes not just for DNSSEC, but any DNS traffic spike or malfunction whether caused by network failure, DDoS, or a natural disaster affecting the geographic location of your existing nodes.

It’s easy, it’s economical and it makes your infrastructure more resilient.

Register now for a free Web Seminar “Lessons from the Trenches: Deploying DNSSEC” on June 9, 2010, featuring leaders from the .SE registry, .ORG The Public Interest Registry, Shinkuro, and Afilias. Register now.