|
Capacity and scalability are necessary in managing DNSSEC and D/DoS. Capacity, necessary for maintaining operations during D/DoS attacks, is also necessary for increased traffic due to DNSSEC deployment. Scalability is highly important, as DNSSEC is deployed not only will greater traffic levels will be encountered, greater demand will be placed on the DNS platform.
In the interest of understanding both capacity and scalability CommunityDNS conducted tests to assess the readiness of the two main DNS server platforms, BIND and NSD and how they would handle the added workload imposed on standard server hardware as well as expose any limitations. To be fair the same tests were conducted on CommunityDNS’ platform. “Details of the study may be found here [PDF].”
Tests applied to the BIND, NSD and CommunityDNS platforms consisted of high volumes of queries being applied to the three different DNS platforms, using four zone sizes in both unsigned and signed environments. The zone sizes represented were:
7,691 | 240,419 | 19,405,229 | 57,873,014 |
It should be noted that neither BIND nor NSD could handle the zone file of 57,873,014 names. It should also be noted that as testing began CommunityDNS’ platform had excess capacity whilst peaking at queries per second. The testing infrastructure was changed, moving to a complete GB platform in switches and routers and moved to CAT-6 cabling. Tests were rerun using the new network infrastructure, achieving greater results.
Capacity Processing: Results of the testing revealed:
Zone File Size | 7,691 | 240,419 | 19,405,229 | 57,873,014 |
Capacity Processing Statistics | BIND: CDNS processes 131% more q/sec for unsigned and 164% for signed. NSD: CDNS processes 31% more q/sec for unsigned and 34% for signed. | BIND: CDNS processes 226% more q/sec for unsigned and 282% for signed. NSD: CDNS processes 55% more q/sec for unsigned and 73% for signed. | BIND: CDNS processes 110% more q/sec for unsigned and 250% for signed. NSD: CDNS processes 45% more q/sec for unsigned and 68% for signed. | BIND: Was unable to load the file of this size. NSD: Was unable to load the file of this size. |
Processing Peaks (Unsigned) | BIND: 53,600 NSD: 94,400 CDNS: 124,000 | BIND: 37,500 NSD: 79,000 CDNS: 122,300 | BIND: 57,500 NSD: 83,000 CDNS: 121,000 | BIND: 0 NSD: 0 CDNS: 120,500 |
Processing Peaks (Signed) | BIND: 39,000 NSD: 71,000 CDNS: 103,000 | BIND: 28,000 NSD: 61,700 CDNS: 107,000 | BIND: 25,500 NSD: 53,300 CDNS: 99,300 | BIND: 0 NSD: 0 CDNS: 89,300 |
Scalability: Examining scalability revealed that for zone file sizes from 7,691 to 19,405,229, scalability for unsigned zones were 2.4% degradation for CommunityDNS, -7.2% degradation for BIND and 12.1% degradation for NSD. When examining scalability for the same zone sizes in a signed environment there was a 3.6% degradation for CommunityDNS, 34.6% degradation for BIND and a 30.9% degradation for NSD.
So when looking at operational stability of DNS platforms during D/DoS attacks or with the migration to signed zones, both capacity and scalability are important to ensure operational resilience. Details of the study may be found here [PDF].
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byCSC
Chuck,
Thanks for posting your scaling statistics regarding CommunityDNS nameserver. As I understand it today, CommunityDNS is only available to those who utilize your DNS infrasture / network as well. I don’t believe you’re comparing apples to apples, you’re trying to pick on BIND and NSD. There are other closed source nameservers that perform as well as CommunityDNS such as Secure64 and Nominum. Certainly, any nameserver goes fast and scales when it is integrate into the OS and hardware.
Also, who performed this testing? Was this completed by a neutral third party?
Regards,
Tom Daly
Tom,
Thank you for your reply.
When it comes to DNS, DNS is simply DNS. A query is a query. When a typical Internet user wishes to access a site, all they care about (and rightly so) is getting to their intended site. It doesn’t matter if a particular DNS platform is open-sourced or non open-sourced. To the end user DNS is simply DNS and a query is a query, so in that regard the test is indeed comparing apples to apples.
As for the title of your response, should CDNS be open-source? Should everything be open-source? Having run an organization based completely based upon open-source I appreciate the value of what open-source brings to the table. However, from the perspective of security and maximum resilience it is best practice for organizations to utilize both open-source and non open-source platforms. So from that perspective it is in the best interest that the Internet community have the ability to utilize DNS platforms that are built upon both open-source AS WELL AS non open-source platforms; a belief long held by CommunityDNS.
We have seen where platforms have simply been overrun by DoS and DDoS attacks, basically rendering a DNS node inoperable, thus impacting queries of legitimate users of the Internet. With DNSSEC additional demands will be at play here. While DNSSEC is a necessary step forward we (the community) need to understand the implications of what DNSSEC will have on not only our communications infrastructure (such as bandwidth and network infrastructure) but also what affect DNSSEC will have on the respective platforms; at different levels of demand. Therefore capacity and scalability of DNS platforms are important. Through this study we not only were able to identify thresholds across the platforms, we were also able to identify where network hardware/infrastructure held back query potential; thus having to upgrade the test environment’s network hardware components to those supporting GB ports and CAT-6 cabling. We were also able to illustrate the impact different zone sizes had on each of the respective platforms; whether unsigned or signed.
While we have seen tests run regarding BIND and NSD, we have not seen similar tests incorporating other DNS platforms. In this study CommunityDNS conducted the test because we had access to all three platforms and could thus conduct identical tests on each of the platform’s software, each running on the same basic-level server, using the same network. We knew, going in, that in conducting identical tests we would be exposed by what the data revealed. To be honest we actually expected to perform better when handling signed zones of 58 million names, so this test was revealing to us as well. We would definitely embrace an independent party to step up and conduct the same tests on BIND, NSD, CDNS as well as the platforms of other DNS providers (both open-source and non open-source), but to date no one has stepped up to the plate. Know of any independent third parties willing to step up?
Regards,
Chuck