Illustration: Alex Nabaum

To measure the effects of ENUM, my company has studied the DNS server implementations that telephone companies commonly use: BIND Version 9.3.0 from the Internet Systems Consortium Inc., Daniel J. Bernstein's DJBDNS, PowerDNS's PowerDNS, and Nominum's ANS, or Authoritative Name Server.

Two of them, PowerDNS and DJBDNS, do not support the latest security protocols for DNS, nor can they be dynamically updated, so they might be unsuitable for ENUM use in any case. In our first tests of the others, we attempted to load 200 million NAPTR records onto 32-bit servers, each with 2 gigabytes of main memory, half the maximum they can use. Only ANS was able to load the data, so we retreated to 50 million records, and then 10 million, to get results for more than one software program. At this size, the most popular DNS software, BIND, could answer just 143 queries per second. DJBDNS answered 6992 queries per second, and ANS answered 45 135 queries per second. While there is no absolute metric for success here, it's obvious that we need to continually reduce the cost of DNS operations if we are to see the same results in VoIP.

Why did BIND do so poorly? We believe the primary reason is that while it does well for names such as www.ieee.org with three labels, it is significantly challenged by ENUM names, which, by virtue of having dots separating each of the digits in the name, have at least a dozen labels. Similarly, when it comes to dynamic update, BIND achieved 69 updates per second, whereas ANS achieved 467 updates per second, and both need further controls to allow a balance between network control (updates) and network user performance (queries).

Moving to computers with 64-bit processors—which allows for much larger memory spaces—helped, but it wasn't a panacea. In tests on a 64-bit Opteron processor, with test data of 10 million names, organized into groups of 10 000, BIND delivered 3805 queries per second and ANS 57 000 queries per second. Interestingly enough, BIND performance degraded by a factor of 50 when ENUM data were organized into separate groups as they might be for public ENUM.

The tests suggest some necessary improvements for ENUM deployments: they may not be sufficient if ENUM data grow to 10 or 20 NAPTRs for every number instead of the one NAPTR per name used in these tests, or if a new security protocol, DNSSEC, is used and adds its significant overhead to queries. Using existing DNS servers, ENUM is cumbersome to set up and manage. Replacing the DNS protocols with another protocol is not the problem, but re-engineering the way they're implemented in a network is. We at Nominum estimate that a service provider with 200 million records would need to install up to 20 times as many servers if it stayed with an in-memory database and the memory limitations of 32-bit processors. Even with 64-bit machines, there are other challenges, such as the right balance between update speed and query speed.

If these issues aren't faced, Internet users are likely to face higher costs and decreased quality of service, delayed call connections, and dropped calls. Alternatively, the provider could opt for a scalable solution, such as Nominum's. (Of course, we believe that our solution is preferable.) This isn't merely a service provider's problem—it's everyone's problem. We all would like to be able to dial a phone number without worrying about what kind of service the recipient has. The Domain Name System needs to be upgraded with software tested against the high-volume, constantly changing loads of ENUM. Only by strengthening these DNS capabilities will we be ready for the demands of ENUM and other new network technologies. As the demands we face are new, so must our approach be new.