10 Things You Should Know About Securing Dns
10 Things You Should Know About Securing Dns
1. Use DNS forwarders
A DNS forwarder is a DNS server that performs DNS queries on behalf of another DNS server. The primary reasons to use a DNS forwarder are to offload processing duties from the DNS server forwarding the query to the forwarder and to benefit from the potentially larger DNS cache on the DNS forwarder.
Another benefit of using a DNS forwarder is that it prevents the DNS server forwarding the requests from interacting with Internet DNS servers. This is especially important when your DNS server is hosting your internal domain DNS resource records. Instead of allowing your internal DNS servers to perform recursion and contacting DNS servers itself, configure the internal DNS server to use a forwarder for all domains for which it is not authoritative.
2. Use caching-only DNS servers
A caching-only DNS server is one that is not authoritative for any DNS domains. It’s configured to perform recursion or use a forwarder. When the caching-only DNS server receives a response, it caches the result and returns the answer to the system issuing the DNS query to the caching-only DNS server. Over time, the caching-only DNS server can amass a large cache of DNS responses, which can significantly improve DNS response times for DNS clients of that caching-only DNS server.
Caching-only DNS servers can improve security for your organization when used as forwarders that are under your administrative control. Internal DNS servers can be configured to use the caching-only DNS server as their forwarders and the caching-only DNS server performs recursion on behalf of your internal DNS servers. Using your own caching-only DNS servers as forwarders improves security because you don’t have to depend on your ISP’s DNS servers as forwarders when you’re unsure of the security configuration of your ISP’s DNS servers.
3. Use DNS advertisers
A DNS advertiser is a DNS server that resolves queries for domains for which the DNS advertiser is authoritative. For example, if you host publicly available resources for domain.com and corp.com, your public DNS server would be configured with DNS zone files for the domain.com and corp.com domains.
What sets the DNS advertiser apart from any other DNS server hosting DNS zone files is that the DNS advertiser answers queries only for domains for which it is authoritative. The DNS server will not perform recursion for queries to other DNS servers. This prevents users from using your public DNS server to resolve names in other domains. This increases security by lessening the risks associated with running a public DNS resolver, which include cache poisoning.
4. Use DNS resolvers
A DNS resolver is a DNS server that can perform recursion to resolve names for domains for which that DNS server is not authoritative. For example, you might have a DNS server on your internal network that’s authoritative for your internal network domain, internalcorp.com. When a client on your network uses that DNS server to resolve the name techrepublic.com, that DNS server performs recursion by querying other DNS servers to get the answer.
The difference between this DNS server and a DNS resolver is that a DNS resolver is a DNS server that is dedicated to resolving Internet host names. A resolver could be a caching-only DNS server that isn’t authoritative for any DNS domains. You can make the DNS resolver available to only your internal users, you can make it available only to your external users to provide a secure alternative to using a DNS server outside of your administrative control, or you can allow both internal and external users access to the DNS resolver.
5. Protect DNS from cache pollution
DNS cache pollution is an increasingly common problem. Most DNS servers are able to cache the results of DNS queries before forwarding the response to the host issuing the query. The DNS cache can significantly improve DNS query performance throughout your organization. The problem is that if the DNS server cache is “polluted” with bogus DNS entries, users can subsequently be forwarded to malicious Web sites instead of the sites they intended to visit.
Most DNS servers can be configured to prevent cache pollution. The Windows Server 2003 DNS server is configured to prevent cache pollution by default. If you’re using a Windows 2000 DNS server, you can configure it to prevent cache pollution by opening the Properties dialog box for the DNS server and clicking the Advanced tab. Select the Prevent Cache Pollution check box and restart the DNS server.
6. Enable DDNS for secure connections only
Many DNS servers accept dynamic updates. The dynamic update feature enables these DNS servers to register DNS host names and IP addresses for hosts that use DHCP for host IP addressing. DDNS can be a great boon in reducing the administrative overhead for DNS administrators who otherwise would need to manually configure DNS resource records for these hosts.
However, there can be a major security issue with DDNS updates if they are allowed unchecked. A malicious user can configure a host to dynamically update DNS host records of a file server, Web server, or database server and have connections that should be destined to those servers diverted to his machine instead of the intended target.
You can reduce the risk of malicious DNS updates by requiring secure connections to the DNS server in order to perform the dynamic update. This is easily achieved by configuring your DNS server to use Active Directory integrated zones and requiring secure dynamic updates. All domain members will be able to dynamically update their DNS information in a secure context after you make this change.
7. Disable zone transfers
Zone transfers take place between primary and secondary DNS servers. Primary DNS servers that are authoritative for specific domains contain writable DNS zone files that are updated as needed. Secondary DNS servers received a read-only copy of these zone files from primary DNS servers. Secondary DNS servers are used to improved DNS query performance throughout an organization or over the Internet.
However, zone transfers are not limited to only secondary DNS servers. Anyone can issue a DNS query that will cause a DNS server configured to allow zone transfers to dump the entirety of its zone database files. Malicious users can use this information to reconnoiter the naming schema in your organization and attack key infrastructure services. You can prevent this by configuring your DNS servers to deny zone transfer requests or by configuring the DNS servers to allow zone transfers only to specific servers in the organization.
8. Use firewalls to control DNS access
Firewalls can be used to gain access control over who can connect to your DNS servers. For DNS servers that are used only for internal client queries, configure firewalls to block connections from external hosts to those DNS servers. For DNS servers used as caching-only forwarders, configure firewalls to allow DNS queries only from those DNS servers that use the caching-only forwarders. An especially important firewall policy setting is to block internal users from using the DNS protocol to connect to external DNS servers.
9. Set access controls on DNS registry entries
On Windows-based DNS servers, you should configure access controls on the DNS server-related Registry settings so that only the accounts that require access to them are allowed to read or change those Registry settings.
The HKLM\CurrentControlSet\Services\DNS key should be configured to allow only the Administrator and System account access, and these accounts should have Full Control permissions.
10. Set access control on DNS file system entries
On Windows-based DNS servers, you should configure access controls on the DNS server-related file system entries so that only the accounts that require access to them are allowed to read or change those files.
The %system_directory%\DNS folder and subfolders should be configured to allow only the system account to access the files, and the system account should be given Full Control permissions
About the Author
Anuj Sharma(System Administrator)