|Written by Dru Lavigne, DNSstuff Contributing Writer|
|Wednesday, 25 April 2007|
|When configuring DNS for a network, there are several things an administrator can do to increase the security of the DNS servers. These include: Restricting Zone TransfersA DNS zone is the database containing the DNS records for a network. Every DNS zone needs a primary DNS server and at least one secondary DNS server. It is important that each of the DNS servers contains the most recent version of the zone; the process that accomplishes this is known as a zone transfer.It is good security practice to restrict zone transfers to the IP addresses of the DNS servers in your own network. For example, on the primary DNS server, input the IP addresses of the secondary DNS server(s)–this will prevent zone transfer requests from DNS servers or clients outside of your own network. On the secondary DNS server(s), input the IP address of the primary DNS server—this will prevent them from accepting zone information from DNS servers outside of your own network.Implementing Split DNSMost networks provide an internal DNS server which contains the DNS records for all of the hosts within that network. From a security perspective, you probably don’t want the world at large to know how many internal hosts you have and what their hostnames are, especially if those hostnames are descriptive. However, you do want the world to be able to find the DNS records for your web and mail servers.Split DNS means that the zone on your external DNS server contains just the DNS records for those hosts you want the world to access—in other words, this server only contains a small sub-set of your DNS zone. The internal DNS server contains the full zone. It is important that the DNS server configurations ensure that the internal and external DNS servers do not share their zone information via zone transfers.Using Separate NetworksWhere you place your DNS servers is also an important consideration. Placing all of your DNS servers on the same network or subnet is a bad idea, something that Microsoft learned when they fell victim to a DNS attack in 2001. Having DNS located on geographically dispersed networks greatly increases your DNS’ fault tolerance.It is an easy matter for both yourself and an attacker to determine if your network is vulnerable to this type of attack. Here is the DNS lookup for microsoft.com:How I am searching:Searching for microsoft.com NS record at j.root-servers.net [184.108.40.206]: Got referral to G.GTLD-SERVERS.NET. (zone: com.) [took 84 ms]Searching for microsoft.com NS record at G.GTLD-SERVERS.NET. [220.127.116.11]: Reports ns1.msft.net. [took 84 ms]Response:
This output shows that there are 5 DNS servers as there are 5 NS records. Note that every single DNS server is on a separate network: the first is on network 18.104.22.168, the next on 22.214.171.124, the next on 126.96.36.199, the next on 188.8.131.52, and the last on 184.108.40.206.Implementing TSIGTSIG is short for Transaction SIGnatures and it provides an additional mechanism for securing zone transfers. An attacker could spoof an IP address, meaning he could bypass your zone configuration restrictions in order to inject false DNS records into your zone or to transfer your zone information. TSIG requires your DNS servers to use a shared key; since the attacker would not have a copy of this key, his transaction request would be refused.Here are instructions for setting up TSIG on BIND and Windows 2000. Note that Microsoft refers to TSIG as Secure Dynamic Update.Configuring DNSSECWhile TSIG will require the DNS servers to authenticate to each other before they complete a transaction, it won’t protect you should an attacker compromise a DNS server in order to gain access to the key.DNSSEC stands for DNS SECurity Extensions. It provides additional security measures; for example, it uses public key cryptography instead of shared secrets for authentication and each transaction packet is digitally signed. In other words, every zone has its own key pair. The DNS servers for that zone use the private key to sign data and any DNS client can use the zone’s public key to verify that that data did indeed come from your zone. This can help prevent the return of false data introduced by an attacker.DNSSEC is available with Windows 2003 and BIND versions 8.2 and higher. DNSSEC.net has a large repository of resources regarding DNSSEC.
DNS Security BasicsPosted: July 9, 2007 in DNS