Securing DNS Servers - Part 2

Last week’s blog article discussed some of the security issues surrounding DNS servers. This article wraps up the topic by offering some tips on securing your server. The good news is most of these problems have been solved and you can take steps to secure your name server and your zone data. Although there is no panacea (see Why the DNS is broken, in plain language), taking these steps will reduce the pool of problem name servers on the Internet.

1. Stay up to date

Make sure your name servers are running the latest version available. Many of the cache poisoning attacks have been fixed in later versions of DNS software. For example, recent versions of ISC BIND added relevancy checks for information in DNS replies, randomized source ports, etc.

2. DNS security

DNS Security Extensions (DNSSEC) adds the ability to ensure authentication and integrity of DNS records through the use of signed DNS zones. With DNSSEC, each record in a zone is signed (and the absence of a record is detectable) and a chain of trust from the root name servers to the zone is used to authenticate the replies as coming from an authorized name server. DNSSEC prevents your domain from being spoofed to DNSSEC-aware resolvers, eliminating cache poisoning attacks. The two draw backs to DNSSEC are that it adds some maintenance overhead for updating zones and keeping the signatures up to date; and not all top level domains (TLDs) are providing for the DNSSEC chain of trust. The second issue has been addressed using other techniques such as DNSSEC Look-aside Validation. A good getting started guide is available: DNSSEC in 6 minutes

3. Turn off public recursive querying

Turning off public recursive querying will not only make you a good net citizen by taking you out of the pool of possible amplification attack servers, it will also close off the theft of service problem described above. To accomplish this, simply add access control over which IPs can query your server. First, you will went to limit general queries to only those IPs which should be able to use you server for DNS resolution (internal network, customers, etc). If using ISC BIND, this can be done in your named.conf’s options section:

options
{
...
allow-query
{
trusted;
};
allow-query-cache
{
trusted;
};
allow-recursion
{
trusted;
};
...
}

acl "trusted"
{
localhost;
192.168.0.0/16; // Internal IPv4
3ffe:470:1f01:642::/64; // Internal IPv6
130.215.24.0/24; // DMZ
};

This will limit the machines allowed to query your name server for any information to those listed in the “trusted” ACL. Second, you will want to open up queries for the zones which your name server publicly publishes:

zone "example.com"
{
...
allow-query
{
any;
};
...
};

This allows queries to the example.com zone from any host on the Internet.

Once these restrictions are in place, test on both a non-trusted machine and a trusted machine. The trusted machine should give an accurate response. The non-trusted machine should get a response indicating that the query was refused and recursion was not available:

> dig A google.com @your-name-server.example.com
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27272
...
;; WARNING: recursion requested but not available
...

4. Turn off AXFR

Finally, to prevent information leakage, you should limit zone transfers to only those machines which provide secondary service to your zones. To accomplish this, add ACLs to turn off zone transfers and then turn them on for each individual zone. For example, with ISC BIND:

options
{
...
allow-transfer
{
none;
};
...
};

zone "example.com"
{
...
allow-transfer
{
10.210.100.1;
3ffe:470:1f01:642::1;
};
...
};

This turns off all zone transfers for all zones served by your name server and then allows example.com to only be transfered by IPv4 address 10.210.100.1 and IPv6 address 3ffe:470:1f01:642::1.