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.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays