Because DNS servers are frequently exposed to open-ended networks, such as the Internet, they are subject to a wide variety of attacks. For example:
Attacks targeting the name server software allowing an intruder to compromise the server and take control of the DNS host Denial-of-service attacks directed to a single DNS server affecting an entire network by preventing users from translating host names into IP addresses Spoofing attacks trying to induce a DNS server to cache false resource records leading users to unintended sites Information leakage from zone transfers exposing internal network information that could be used to plan and execute future attacks A DNS server could be an unwitting participant in attacks on other sites
As any software application, DNS software evolves with each version release. Essentially, all older DNS versions have widely known vulnerabilities that attackers will exploit. In most cases, vulnerabilities that appear in one version are patched in subsequent releases. Running the latest version of DNS software does not guarantee security; however, it will minimize the likelihood of exploitation.
Auditors should be mindful there are steps that can be taken to secure a DNS server that only as to deliver DNS to a single audience and it can be optimized for that particular function. It is useful to use separate DNS servers configured to play specific roles. It is a useful procedure to have different security policies applied to servers respective to their function. For example, having an external DNS server used only as an external name server is a sound business procedure. This DNS server should provide resolution for zones for which it has authoritative information. In other words, it provides DNS services for Internet or open-ended networks and your internal network's users.
Exterior DNS servers should not contain any information about your internal network addressing or topology. It should be located in the Demilitarized Zone, DMZ, meaning it is behind a packet screen firewall facing the open-ended network and in front of the application firewall that protect the sensitive interior network. Architectures of this nature look like a sandwich with the DMZ located between the slices. DMZs are the areas where Web servers, outside e-mail services, and name servers reside.
Having an internal DNS server is commonly used to provide name resolution services to internal network clients. This DNS server is configured to provide query answers from trusted internal hosts and not from the Internet. It is located behind the packet screen, the DMZ, the application firewall as a member of the internal network. Adopting these security procedures will result in the external DNS server configured to provide little resolution service other than answering queries for which it is authoritative. Internal DNS servers can be protected by restricting the server to respond only to known and trusted hosts. In this fashion, if the resolving server was compromised or its cache corrupted, the outside DNS server's authoritative zone information would not be affected, thereby limiting the potential for damage. In this same vein, if the internal DNS server were also configured to be authoritative for internal zones only, a compromise of the external DNS server would not affect the normal name service operation of the internal network.
As a matter of network security and protection, organizations operate their DNS servers on dedicated hosts. Hosts that run the DNS services do not provide other services; consequently, there is no need for them to respond to non-DNS traffic. In such a dedicated DNS host configuration, it reduces the possibility of the DNS server being compromised by a weakness in any other piece of software located on the same host as the DNS. As a further sound security procedure, administrators disable or remove any unnecessary software or hardware features from the DNS host. The logic supporting this procedure is if unnecessary software and hardware are not present, attackers cannot exploit them.
For DNS servers providing external name resolution, everything but traffic from the Internet to port 53 UDP and port 53 TCP on the DNS server can be safely filtered and denied entry. Similarly, internal network DNS servers can be filtered allowing only internal clients access to ports 53 UDP and TCP on the name server and allowing the internal DNS server to make outbound queries to other internal DNS servers.
TCPdump is a network information capture program developed at Lawrence Berkeley National Laboratory. It is a UNIX-based program consisting of an executable with a network capture driver program. The purpose of this utility is the interception, capture, and display of information packets passing through the network. If TCPdump were installed on computer connected to the target network, it will capture all passing information packets. The Windows version of TCPdump is called Windump. [8]
Attackers will typically attempt to exploit packet-screening flaws.
Zone transfers are used to transfer DNS information from one DNS server to another. Restricting zone transfers is a significant step in security DNS services. Implementing restrictive zone transfers has the secondary benefit of preventing others from taxing your system's resources as it prevents intruders from gaining a list of the contents of DNS zones. Zone transfers are the delivery of the cached information held in the DNS service. Attackers obtaining zone transfers from your internal DNS server will allow them to see the IP addresses as well as the architecture of your internal network. Denying attackers this type of information raises your internal network's security. An attacker who is able to complete a zone transfer can use that information to identify new targets on your internal network such as routers, mail servers, other DNS servers, file servers, databases, and anything else in your DNS records.
A common administrator mistake is to restrict zone transfers from the primary master DNS server only, while neglecting to restrict transfers from slave servers. Because it is possible to obtain a zone transfer from a slave server, it is important that auditors ensure that all authoritative DNS servers have restrictions placed on zone transfers.
In BIND 8 or 9, use the allow-transfer substatement:
options {
allow-transfer {192.168.4.154;};
};
or specific to a zone:
type master;
zone "my example.com" {
file "db.myexample.com";
allow-transfer {192.168.4.154;};
};
