لطفا منتظر باشید ...
Core DNS
Configuration
DNS configuration may be thought of as
consisting of two tasks: Configuring the DNS server itself (which is called named in the
case of BIND), and administering your domain. This section covers the most
common options for the first task, and the next section, "
couple of special configurations that may be of interest to yourunning a local
DNS server for its cache and integrating BIND with a DHCP server.) Basic DNS
configuration requires that you set basic configuration options, that you
locate other DNS servers (especially the root servers), and that you tell the
server about the zones you intend to administer. All but the smallest domains
require a secondary name server. In theory, you could simply copy the
configuration files to exactly duplicate the configuration, but it's usually
better to set up the secondary server to automatically mirror the first one's
files.
The BIND Configuration File
Most basic BIND configuration options appear
in the main BIND configuration file, named.conf . This file
usually resides in /etc , but some distributions' BIND packages don't provide a default file
in that location. You can usually find a sample file somewhere in the BIND
documentation directory (often /usr/share/doc/bind-version ).
a short but complete named.conf file.
Listing 18.1 A sample named.conf file
options { directory "/var/named/"; auth-nxdomain yes; forwarders { 10.232.7.98; 10.232.45.1; }; forward first; }; zone "." { type hint; file "named.ca"; }; zone "threeroomco.com" { type master; file "named.threeroomco.com"; }; zone "1.168.192.in-addr.arpa"{ type master; file "named.192.168.1"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; };
The named.conf file is broken
up into sections. In the case of
these are options and several zone sections. The options
section sets global options such as the directory in which zone configuration
files are stored. The zone
sections define specific zonesthat is, domains or other logical groupings of
hostnames or IP addresses. Most lines in named.conf
end in semicolons ( ; ). This is a
requirement of the file format, so you should be careful to follow it lest BIND
become confused. Much of what named.conf
does is to point BIND to files that provide more information about specific
zones. These files reside in /var/named
(or whatever location you specify with the directory
option).The following sections describe the contents of named.conf in more detail.
Locating
Other Name Servers
One of the first tasks you must perform when installing a DNS
server is to obtain a list of root name servers. There are several ways to
obtain this list. Possibilities include: The file may ship with your BIND package, probably under the name
named.ca or db.cache under the /var/named directory. This file might be
outdated, though, so you may want to check for a more up-to-date file using
either of the following two methods. You can obtain the file via FTP from
filename named.ca . If your system has the dig
program installed, you can type dig @a.
root-servers.net . ns > named.ca to retrieve the file and
call it named.ca .The second and third options both require that your system
have access to a working DNS server. If your network has no such server, you
can try obtaining the file on a computer attached to another network, or
temporarily set your future DNS computer to use another system for name
resolution, as described in
that your /etc/named.conf file
includes a reference to the root server list. The root server list is specified
in the zone "."
section, using the file option,
as shown in
the root zone file matches the one listed in named.conf .
(Technically, hostnames all end in periods, so the root zone is indicated by a
bare period.)
Setting
Up a Forwarding Server
The default function of BIND is to perform lookups in one of
three ways, in sequence:1. If
BIND is configured as the authoritative server for an address, the server
responds with the address set in its configuration files.2. If
the request is for an address in the program's cache, the server returns that
address. This feature improves performance, as noted earlier, and reduces
network traffic.3. If
the requested address isn't in BIND's cache, the server queries a root name
server, and other name servers, as described earlier. This recursive lookup
usually takes just a few seconds at worst, but it is slower than a cached
lookup.BIND supports a fourth option, though: It can query a DNS
server and let that server do the tedious recursive lookup. When so configured,
BIND tries this option after checking its local cache but before performing a
full recursive lookup. The idea is that a name server running on a small
network that has access to a larger, but still somewhat local, name server may
produce quicker lookups if it can rely upon the cache and faster network
connections of that larger DNS server. For instance, if you operate a home or
small office network that's tied to the Internet via a dial-up or
satellite-based connection, you might want to configure the server to forward
DNS requests to your ISP's DNS server. Connections such as dial-up and
satellite broadband have high latencies, so the multiple queries of a full
recursive lookup can take several seconds to perform.Why not simply tell your local computers to use your ISP's
server directly, though? Perhaps you want to run your own local DNS server to
handle your local systems' names, or perhaps you want the benefit of a cache
that's even closer to your systems than is your ISP's server. Also, a few ISP's
DNS servers are unreliable, so having your own configured as a fallback can
improve the reliability of your network connection.In any event, a forwarding configuration like this is created
with the forwarders and forward first options, as shown in
one or more DNS servers that yours is to query for information before trying to
perform a recursive lookup. The forward
option can take one of two values only
or first . If you specify forward only , BIND will rely exclusively
upon the specified remote DNS server; BIND will not perform a recursive search
of its own. By contrast, forward first
causes BIND to attempt a lookup through the specified remote DNS servers, but
if that lookup fails (say, because the remote DNS servers aren't responding),
BIND proceeds with a normal recursive lookup. In both cases, BIND still relies
upon its own zone configuration if it's been told it's authoritative for a
zone, as described shortly.
Setting
Up Zones
When you set up BIND, you must tell it how to handle requests
for specific domains, subdomains, and IP address ranges. These different groups
of names and addresses are referred to as zones.
A zone may be either a domain or subdomain (as in the threeroomco.com zone in
(which are specified by zone names ending in in-addr.arpa ).
A small DNS server will set up a handful of zones: The root zone A zone
identified by a single period ( . )
refers to the root of the name space. This zone definition uses the type hint option to tell BIND to defer to
the name servers listed in the file specified by the file option, as described earlier. Your local domain Unless
you're running a caching-only name server, you'll want to configure BIND to
handle a zone that corresponds to your domain or subdomain.
configuration. Reverse DNS zones Although DNS
is most commonly used to look up an IP address from a hostname, the reverse
lookup is also possible. This is known as a reverse
DNS lookup, and it's handled by zone names that end in in-addr.arpa . Preceding this string in the
zone name is a partial IP address, in reverse order. For instance, the entry
for the 192.168.1.0/24 network is called 1.168.192.in-addr.arpa ,
as shown in
a configuration file that provides additional information about the zone. Zone
types may be any of the following: master A master server is one that contains the original
authoritative control file for a zone. If you're configuring a DNS server for a
small network, you'll probably configure its local domain's zones as masters.
another DNS server. The slave is still considered an authoritative source for
that zone, though. The next section, "
options in more detail. A single BIND server may function as a master for some
zones and as a slave for others. It's usually simplest to set up one master and
a matching slave, though. stub This
configuration is much like a slave configuration, except that the stub server
copies only NS recordsthat is, name server specifications. You'd use this
option if you want to configure a separate DNS server for a subdomain. For
instance, if threeroomco.com
has a subdomain called sub.threeroomco.com ,
and if you want to run a separate DNS server for sub.threeroomco.com , you could include a sub.threeroomco.com zone in
the threeroomco.com
BIND configuration and give it a stub
type that points to the sub.threeroomco.com
DNS server. Alternatively, you could use one DNS server to handle the entire
domain, including the sub.threeroomco.com
subdomain. This would require no special zone entry for sub.threeroomco.com . forward
Like a forward option in the options section, a forward zone type tells BIND to pass on
requests for information on a zone to another DNS server. Essentially, BIND
issues its own DNS request to the specified servers, then responds with the
results of this query. To be effective, you must include a forwarders option to tell BIND to what
remote DNS servers to forward requests. hint This
zone type is unique to the root name server specification. You use it to tell
the system where to find a list of root name servers. BIND should then try to
update that list from one of the root name servers itself.A simple configuration, such as that shown in
may include all of the preceding zone types.
Configuring
a Slave Server
If you're running your own DNS servers for a
registered domain, you must configure two DNS servers. This is normally handled
by making one server a slave of the other. The slave server stores its zone
information in separate files, just like the master server. The main difference
is that the slave server automatically retrieves the zone files from its master
server. You tell the slave how to do this by changing the zone configuration in
/etc/named.conf . For instance, suppose you want to set up a server to act as a
slave to the one configured through
zone configuration for the threeroomco.com domain on the slave
might resemble the following: zone "threeroomco.com" { type slave; file "named.threeroomco.com"; masters { 192.168.1.50; } };
This tells the slave to obtain its
configuration file for threeroomco.com from the DNS server
at 192.168.1.50. If the slave is to be a slave for multiple domains, you should
include several such definitions. You can include several DNS servers in the masters list,
if you have more than two DNS servers for the domain; separate the IP addresses
with semicolons ( ; ). (In fact, one slave can synchronize itself from another slave.) If
the server is a slave for several zones, each zone can synchronize against a
different master. You might use this feature if you're administering several
domains, each of which should have its own master, but for which a single
shared slave is acceptable.Remember to configure slave zones for both
forward lookups (as in the threeroomco.com zone) and reverse
lookups (as in the 1.168.192.
in-addr.arpa zone in
should not configure a slave DNS server to use slave zones for the root name
servers or for the localhost reverse lookups ( 0.0.127.in-addr.arpa in
as a slave, you should see the zone files specified in the zone options
appear. If you don't, check the log files on both the master and slave systems
for clues to what went wrong. One possibility is that the master might be
configured to refuse zone transfers. This may be done as a security measure to
keep outsiders from retrieving information on all your domain's local
computers. If you want to restrict zone transfers on either your master or your
slave DNS servers, you can do so with the allow-transfer option,
which can go in either the options section or a specific zone section. For instance, you might use
the following settings to restrict transfers to computers on the 192.168.1.0/24
network and to 172.19.98.23: allow-transfer { 192.168.1/24; 172.19.98.23; };
