eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
After a series of service outages drew sharp attention to a server-based system that was built more than 10 years ago, WiscNet decided it was time to look into options for replacing its aging Domain Name System.
WiscNet-the education and research network provider for K-12 schools, colleges and universities in Wisconsin-is running a DNS system that was developed years ago by engineers who have long since moved on.
It’s a credit to these engineers’ scripts and open-source BIND (Berkeley Internet Name Domain) implementation that DNS has worked for so long with so little development work at WiscNet. Moving the BIND servers onto modern hardware has helped mitigate risk, but outages occur from time to time.
So, WiscNet administrators asked, “Should the infrastructure be updated?”
To help answer that question, Wisc??ÃNet and eWeek Labs co-hosted a DNS Demonstration Day on Jan. 8 that brought together three DNS appliance vendors with WiscNet engineers and officials. Also present at the event were state network representatives from Michigan, Ohio and Missouri, as well as engineers from the University of Wisconsin-Madison campus, where the event was hosted. (WiscNet and eWeek Labs first worked together in 2003, when six anti-spam vendors were brought in to prove their mettle at screening junk e-mail for WiscNet clients.)
In preparation for the event, Wisc??ÃNet officials, working with eWeek Labs, developed an RFP that would go out to DNS appliance vendors.
WiscNet services more than 1,200 zones and more than 54,000 DNS records for its school district, college and university customers across the state. WiscNet has a redundant pair of DNS servers and a stealth master DNS server in Madison, as well as a pair of servers in Milwaukee. With this setup, WiscNet provides reliable DNS service to its customers by reducing the risk of simultaneous outages.
But WiscNet technical support staffers also need the ability to create accurate reports that show all domains belonging to a WiscNet customer organization. In addition, they would like to be able to delegate some zone administration tasks to local administrators rather than have all DNS changes implemented through WiscNet staff.
Most important for WiscNet is the need to have DNS expertise readily available to correct DNS problems or to restore service when servers go down.
Test Plan
Wiscnet’s technical leaders identified the key problems with their DNS and surveyed seven other state network providers about the systems they use to provide DNS. All but one use BIND running on a Unix system; the exception was a large state university that had recently implemented one of the DNS appliances that we ended up testing.
The RFP was sent out to DNS appliance vendors in December. The vendors whose responses best fit WiscNet’s needs were Alcatel-Lucent, BlueCat Networks and Infoblox. Working with WiscNet officials, eWeek Labs developed 14 demonstration objectives that the participants would be expected to fulfill during a 75-minute presentation using their equipment (see chart, Page 38).
Each solution had its pluses and minuses (see review, Page 38), but at the end of the day, the vendor representatives failed to convince the audience that their products’ benefits outweighed the costs and learning curves that would be required to implement them.
All the agencies, including WiscNet, use engineers-and help desk staff trained by these engineers-to keep the DNS systems up and running. And, during the evaluation, the IT professionals from WiscNet and the other state agencies considered whether a DNS appliance trumped a network engineer and Perl scripts for providing name resolution services.
Event attendees were definitely leaning toward passing up the appliances. Yet the dilemma for WiscNet remains: With network engineers ensconced in “other projects” and the DNS infrastructure limping along-not failing, but certainly not the picture of efficiency and health-how much longer can DNS go on?
Network managers and IT executives should consider the degree to which risk avoidance plays a role in making decisions about where to expend engineering resources in network maintenance. As one participant put it, when a DNS appliance is used, the vendor support staff becomes your organization’s DNS expert.
The positive side of this is that there are some expert people working for the vendors whose solutions we tested. Further, vendor support staffers resolve DNS issues on a regular basis, whereas respondents to the WiscNet survey indicated their engineers dealt with DNS problems episodically.
The negative side to having the vendor become your DNS expert is the cost of a support contract. This is both an insurance cost and a line item charged directly to DNS support-a cost that is likely not as obvious when hidden in a staff engineer’s salary.
In the end, the day ended with many questions unanswered-and many new ones asked.