By Mike Mullins
Domain name system (DNS) servers are the heart of any network. Without one, you can't resolve an Internet address, and customers can't send e-mail to you or browse your Web site. DNS servers are vulnerable to a multitude of attacks, which come in several forms.
Old software, both operating system and name server software, has many publicized vulnerabilities. Your DNS server OS should be patched and run only the latest stable release of your flavor of DNS server software.
A new software version doesn't guarantee security, but it does minimize exploitation through known attacks.
Spoofing and poisoning
Hackers commonly use dynamic updates to fool a properly configured DNS server into accepting bad entries. You can foil such attacks easily by implementing Transaction Signatures (TSIG) and packet filtering updates from authorized DNS servers.
Disabling the fetching of glue records (DNS lookup of Host A records) and restricting addresses that can make a recursive query to the DNS server can further reduce the risk of DNS server poisoning.
Denial of service
Denial of service (DoS) attacks targeted at your DNS server can isolate your network from the world and the world from your network. To prevent DoS attacks, eliminate single points of failure in your DNS architecture. Do not place all of your DNS servers on the subnet with your network or place them behind a single-threaded Internet connection.
In addition to providing security, having a DNS server in a physically diverse location also provides better response to customers who are trying to reach your network. This is an excellent opportunity to build a business partnership and exchange colocated services at a physically diverse site.
To further improve your resistance to DoS attacks, at a minimum, implement two DNS servers: an internal and an external one.
The internal DNS server should provide name resolution only to internal clients. Configure it as a recursive server (i.e., it asks another DNS server for information). However, it should answer queries only from your internal hosts—not from the Internet.
Restrict your external DNS server to nonrecursive requests (i.e., it won't ask another DNS server for information), and have it advertise to the Internet as authoritative for your DNS zones. Furthermore, restrict inbound access from the Internet to TCP/UDP port 53.
Note: DNS queries will use TCP port 53 for query responses that won't fit in a single UDP packet. Zone transfers should be further restricted within the name server configuration.
Strengthen DNS security
By restricting zone transfers between authoritative servers, you eliminate nonessential traffic between DNS servers; in addition, you can also prevent hackers from listing the complete contents of your network.
A zone transfer contains a wealth of information for someone targeting your network for hacking. If you have a slave DNS server, don't forget to secure it as well. If you must allow zone transfers, implement authentication via TSIG and cryptographically sign files between authoritative servers.
After you've secured and configured your DNS servers, and before they go live on your network, try to break into them and attempt to poison their cache with bogus records. If you're successful, go back to the configuration and packet filtering rules and eliminate the security holes.
DSN servers are extremely valuable targets for hackers. They are generally unmonitored and rarely updated. Keep that in mind when you're ready to deploy one, and give them the security attention they deserve.
Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.