Blogs

Happy 30th birthday to the GNU project!

According to their announcement commemorating the event on the GNU.org site, September 27th, 1983 was the day that Richard Stallman first announced the GNU project to the public.

Today the open source software movement that GNU pioneered is vibrant, thriving, and global.   It counts among its members a multitude of individuals and project groups motivated by an amazing variety of values and goals.  Millions every day use open source software directly and innovation and competition from open source have spurred improvement even in projects that don’t share the open source philosophy.

At ISC we’re proud to be part of the open source movement that the GNU Project trailblazed.  We’d  like to salute our colleagues (and respected elder siblings) at GNU and congratulate them on their past 30 years of remarkable achievement.  Well done, GNU, and thank you for all that you have done to make the world a better place.

ISC is excited to announce the release of BIND 9.9.4, featuring Response Rate Limiting (RRL), security patches, and bug fixes for DNSSEC, RPZ and configuration modules. The latest dot release ensures the stability, robustness and security of your critical Internet infrastructure.

Response Rate Limiting (RRL)

A DNS DDoS attack works by forging queries that look like they came from the victim’s server, making it appear to be requesting a high volume of information. RRL enables server administrators to limit the rate at which their server will send replies to forged queries, thereby preventing it from contributing to the attack.

“Our users have been asking for RRL to be incorporated into BIND,” said Kannan Ayyar, President of Internet Systems Consortium, “and we recognize the important role it plays in DDoS mitigation. With DDoS attacks increasing in both number and severity, we felt it was important to integrate RRL into a supported release.”

“We have been testing RRL in limited release, and are now confident that it is ready for general use in BIND installations,” said Scott Mann, ISC’s VP of Engineering. “Third-party additions like RRL are possible because BIND is open source software. Now that it is fully implemented, we look forward to enhancing and building on RRL in future releases.”

For more information on RRL, visit the following links:

• DDoS Defense Module for BIND DNS – RRL (Webinar)
• A Quick Introduction to Response Rate Limiting
• Cache poisoning gets a second wind from RRL? Probably not.

Commercial support for BIND and additional RRL functionality, RRL Classifier, is available to The DNS Company subscription customers; visit The DNS Company’s BIND Solutions to learn more.

For questions, suggestions and discussions relevant to BIND, participate in our community mailing list, available at https://www.isc.org/community/mailing-list/.

BIND 9.9.4 is available for download at our Downloads page.

You may have heard recently that Response Rate Limiting (RRL) has re-opened the door on cache poisoning attacks (see CVE-2013-5661).

ISC acknowledges that RRL can increase the effectiveness of cache poisoning attacks and appreciates the detailed research that uncovered it.  This is, however, only one piece in the larger context of competing security concerns, and each operator will need to find their own balance of protection.

For those unfamiliar with it, RRL is designed to reduce the effectiveness of reflected denial of service (DoS) attacks which leverage DNS servers to amplify the attack.  DNS servers are frequently used as amplifying reflectors in DoS attacks because attackers can send a small UDP query with a forged source address to the DNS server and get it to respond with a much larger answer to the target of the DoS.  RRL reduces the effectiveness of these attacks by detecting when a large amount of similar traffic is being sent to a single target and suppressing responses.

This could, of course, potentially be used to create a different kind of DoS attack against a target if an attacker chooses to ask the same kinds of questions that the target is likely to ask.  If this were done against all of the servers authoritative for a zone then an attacker could potentially prevent the target from getting any answers at all for the zone.

In order to combat this risk, RRL was designed with a concept called “slip”.  Slip comes into play after RRL starts suppressing responses, and works by allowing a specified fraction of responses to “slip” through the suppression.  These responses contain none of the actual answer data, but do have the truncation (TC) bit set in the header of the response in order to tell the client to retry over TCP.  This enables legitimate clients to get answers via TCP, which has a lot more overhead than UDP but is not vulnerable to source address forgery.

ISC’s RRL implementation will debut in our upcoming 9.9.4 release.  Like the redbarn.org patches that preceded our implementation, we have chosen a default slip value of “2″, meaning that TC answers will be sent to the client/target 1 time in 2.  The other half of the time the queries will go unanswered.

It is these unanswered queries that create the increased opportunity for cache poisoning by giving an attacker a larger time window in which to get a forged reply with poison data to the victim.  The data that we’ve seen indicates that for a reasonably-configured resolver it takes, on average, more than sixteen hours of 100Mbps of forged answers in order to get the resolver to accept a poisoned answer.  During this time, the resolver is both being flooded with traffic and assumed to be unable to resolve the name in question.  Both of these are usually fairly visible events.  We have not seen any analysis of the expected time for a “stealthy” cache poisoning attack, but we expect it to be significantly longer.

The researchers who discovered this have recommended a slip value of “1″, sending a TC answer for every response that RRL decides needs to be suppressed.  This reduces the effectiveness of cache poisoning attacks while increasing the effectiveness of using DNS to amplify DoS attacks.

Note that this analysis only applies to queries and responses that are affected by RRL, while anything that causes the legitimate packets to be dropped, even simple traffic congestion, will benefit someone attempting cache poisoning.  Therefore, modifications to the behavior of RRL can have, at best, a limited effect in defending against cache poisoning. The best defense is for authoritative server operators to sign their zones with DNSSEC, and for resolver operators to validate responses.

The bottom line is that there is no clear “right” answer here.  Both concerns are valid and the mitigation for one increases the risk of the other.

We believe, based on what we know of the current state of the internet, that a slip value of “2″ is closer to the theoretical “sweet spot” in addressing both risks than a slip value of “1″ is, which is why we are keeping “2″ as our default.  Since RRL is not enabled by default even when it is compiled in to BIND, and the slip value is a configurable option, we believe that this provides the most useful default value while giving individual operators the freedom to choose the risk balance that they are comfortable with.

Finding the right risk balance also includes considering the effect that other features (e.g. DNSSEC) have on amplification potential and resistance to cache poisoning.

Those who are interested in learning more about how we got into this situation and where we ought to go from here may want to check out Paul Vixie’s blog post “On the Time Value of Security Features in DNS“.

Internet Systems Consortium (ISC) announces that the RRL module, currently the most effective defense against the use of DNS in Distributed Denial of Service attacks, is now part of the upcoming BIND release.

A DNS DDoS attack works by forging queries that look like they came from the victim’s server, making it appear to be requesting a high volume of information. RRL enables server administrators to limit the rate at which their server will send replies to forged queries, thereby preventing it from contributing to the attack. The frequency of DNS DDoS attacks has been increasing, rising by 20% in Q2 of 2013. In an average attack 50 million packets per second are beamed at the victim. As attacks increase, RRL is the best defense available.

“Our users have been asking for RRL to be incorporated into BIND,” said Kannan Ayyar, President of Internet Systems Consortium, “and we recognize the important role it plays in DDoS mitigation. With DDoS attacks increasing in both number and severity, we felt it was important to integrate RRL into a supported release.”

“We have been testing RRL in limited release, and are now confident that it is ready for general use in BIND installations,” said Scott Mann, ISC’s VP of Engineering. “Third-party additions like RRL are possible because BIND is open source software. Now that it is fully implemented, we look forward to enhancing and building on RRL in future releases.”

For more information on RRL, visit the ISC Knowledgebase at https://kb.isc.org/article/AA-01000, or sign up for a webinar listed at our events page.

Commercial support for BIND and additional RRL functionality is available to DNSco subscription customers; visit DNSco’s BIND Solutions to learn more.

Internet Systems Consortium (ISC) announces that it has sold its security-related assets to Farsight Security, Inc., (“Farsight”) a new company started by ISC founder, Paul Vixie. The DNSDB and SIE services developed by ISC over the past five years will now be provided by Farsight.

“Paul Vixie has been the driving force in Internet security innovation at ISC for many years,” said Kannan Ayyar, President of Internet Systems Consortium. “We are pleased that he will be taking these technologies forward and providing ongoing leadership in the security space. We look forward to his continued innovation there. Paul Vixie has been part of ISC for 18 years; with this new venture he has ended all of his involvement with ISC. We are grateful for his many contributions and share his excitement about Farsight.”

This is the second time this year that ISC has divested certain assets to a commercial for-profit entity. ISC is doing this to increase clarity and focus for its non-profit Internet mission, which includes running F-Root, providing hosting and Internet services for non- profits, researching and developing new ideas for the Internet and of course providing free world-class nameserver and DHCP software for the benefit of the Internet.

In April of this year, ISC launched DNSco (http://dns-co.com), a wholly-owned subsidiary delivering a full suite of commercial services for BIND and ISC DHCP. Farsight, unlike DNSco, is a privately held company that is independent of ISC.

“Farsight security technologies and service delivery capabilities are the result of years of research at ISC,” said Paul Vixie. “During that time we iterated on a range of business models and technology prototypes yielding best-in-class Internet security solutions that will help make the Internet a safer place.”

About ISC

Internet Systems Consortium is a non-profit 501(c)(3) public benefit corporation widely known for world-class Internet software engineering and network operations. ISC produces only open-source software with emphasis on Internet core technology, of which BIND and ISC DHCP are the two best-known examples. ISC’s Managed Open Source process ensures the quality of this software while keeping it open and available.

ISC operates high-reliability global networks of DNS root servers (F-root) and authoritative DNS servers (SNS@ISC) both for non-profit and for commercial enterprises. ISC is also very involved in ongoing Internet protocol and standards development, particularly in the areas of DNSSEC and IPv6. ISC is supported by donations from generous sponsors, by program membership fees, and by increasing revenues from for-profit subsidiaries. For program or donation information, please visit our website at http://isc.org.

About Farsight Security, Inc.

Farsight is a privately held Delaware corporation exclusively focused on the development of leading edge security solutions for ISPs, network and system security solution providers, governments, and medium to large commercial companies. Leveraging its superior telemetry data collection and processing capabilities, Farsight provides its clients with cloud-based, real-time network observability and reporting solutions.

Like ISC before it, Farsight is committed to sharing its security-related telemetry data with security industry partners and academic researchers at nominal, non-discriminatory subscription rates. In support of its mission as a clearing house for such data, Farsight invites network operators and commercial clients to provide additional telemetry data, which will increase the volume, quality and accuracy of its data provision services thus improving the overall safety of the Internet as a viable commercial marketplace.

Further information about it can be found at http://www.farsightsecurity.com