Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

6.2. DNS Security Principles

DNS security can be distilled into
two maxims: always run the latest version of your chosen DNS software
package, and never provide unnecessary information or services to
strangers. Put another way, keep current and be stingy!

This translates into a number of specific techniques. The first is to
limit or even disable
recursion,
since recursion is easily abused in DNS attacks such as
cache poisoning. Limiting recursion is
easy to do using configuration-file parameters; disabling recursion
altogether may or may not be possible, depending on the
nameserver's role.

If, for example, the server is an external DNS
server whose sole purpose is to answer queries regarding its
organization's public servers, there is no reason
for it to perform lookups of nonlocal hostnames (which is the very
definition of recursion). On the other hand, if a server provides DNS
resolution to end users on a local area network (LAN), it definitely
needs to recurse queries from local hosts but can probably be
configured to refuse recursion requests, if not all requests, from
nonlocal addresses.

Another way to limit DNS activity is to use split DNS services
(Figure 6-2). Split DNS, an example of the
split services concept I introduced in Chapter 2 in the section "Deciding
What Should Reside on the DMZ," refers to the
practice of maintaining both public and
private databases of each local name domain
(zone). The public-zone database contains as little as possible: it
should have NS
records for publicly accessible nameservers, MX records of external SMTP (email)
gateways, A records (aliases) of
public web servers, and entries pertinent to any other hosts that one
wishes the outside world to know about.

Figure 6-2. Split DNS

The private-zone database may be a superset of the public one, or it
may contain entirely different entries for certain categories or
hosts.

The other aspect to DNS
"stinginess" is the content of zone
files themselves. Even public-zone databases often contain more
information than they need to. Hosts may have needlessly descriptive
names (e.g., you may be telling the wrong people which server does
what), or too granular contact information may be given. Some
organizations even list the names and versions of the hardware and
software of individual systems! Such information is almost invariably
more useful to prospective crackers than to its intended audience.

Maintaining current software and keeping abreast of known DNS
exposures is at least as important as protecting actual DNS data.
Furthermore, it's easier: the latest version of BIND
can always be downloaded for free from djbdns
from http://cr.yp.to. Information
about general DNS security issues and specific BIND and djbdns
vulnerabilities is disseminated via a number of mailing lists and
newsgroups (some of which are listed at the end of this chapter).

There are actually third and fourth maxims for DNS security, but
they're hardly unique to DNS: take the time to
understand and use the security features of your software, and,
similarly, know and use security services provided by your
DNS-registration
provider. Network Solutions and other top-level
domain registrars all offer several change-request security options,
including PGP. Make sure that your provider requires at least email
verification of all change requests for your name domains!