This article was originally published in TechRepublic’s Security Solutions e-newsletter.
Domain name system (DNS) servers are at the heart of network services. Without DNS, you can’t resolve an Internet address, and customers can’t send e-mail to you or browse your Web site. Unfortunately, DNS servers are also vulnerable to a multitude of attacks, which can come in several forms.
Old software—both operating system and DNS software—has many publicized vulnerabilities that can affect DNS. As a result, your DNS server OS should be patched and should run only the latest stable release of your flavor of DNS server software.
Also, keep in mind that 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 same subnet with your network or place them behind a single-threaded (non-redundant) 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 co-located 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 and not from the Internet.
Restrict your external DNS server to non-recursive 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.
DNS queries will use TCP port 53 for query responses that won’t fit in a single UDP packet. Also, 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 getting a listing of the 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 from the outside 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.
DNS 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 when you’re auditing the security of your network. Give DNS servers the security attention they deserve.