| openSUSE Documentation Chapter 22. The Domain Name System / 22.5. The Configuration File /etc/named.conf | ||||
|---|---|---|---|---|
 | 22.4. Starting the Name Server BIND | 22.6. Zone Files |  | |
| openSUSE Documentation Chapter 22. The Domain Name System / 22.5. The Configuration File /etc/named.conf | ||||
|---|---|---|---|---|
| 22.4. Starting the Name Server BIND | 22.6. Zone Files | | |
All the settings for the BIND name server itself are stored in the file
/etc/named.conf. However, the zone data for the domains
to handle, consisting of the hostnames, IP addresses, and so on, are stored
in separate files in the /var/lib/named directory. The
details of this are described later.
/etc/named.conf is roughly divided into two areas.
One is the options section for general settings and
the other consists of zone entries for the
individual domains. A logging section and
acl (access control list) entries are optional.
Comment lines begin with a # sign or //. A
minimal /etc/named.conf is shown in
Example 22.2, “A Basic /etc/named.conf”.
Example 22.2. A Basic /etc/named.conf
options {
directory "/var/lib/named";
forwarders { 10.0.0.1; };
notify no;
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};filename";
Specifies the directory in which BIND can find the files containing the zone
data. Usually, this is /var/lib/named.
ip-address; };
Specifies the name servers (mostly of the provider) to which DNS
requests should be forwarded if they cannot be resolved directly.
Replace ip-address with an IP address
like 10.0.0.1.
Causes DNS requests to be forwarded before an attempt is made to resolve
them via the root name servers. Instead of forward
first, forward only can be written
to have all requests forwarded and none sent to the root name servers.
This makes sense for firewall configurations.
ip-address; };
Tells BIND on which network interfaces
and port to accept client queries.
port 53 does not need to be
specified explicitly, because 53
is the default port. Enter 127.0.0.1
to permit requests from the local host. If you omit this
entry entirely, all interfaces are used by default.
Tells BIND on which port it should listen for IPv6 client requests. The
only alternative to any is none. As
far as IPv6 is concerned, the server only accepts a wild card address.
This entry is necessary if a firewall is blocking outgoing DNS requests. This tells BIND to post requests externally from port 53 and not from any of the high ports above 1024.
Tells BIND which port to use for IPv6 queries.
net; };
Defines the networks from which clients can post DNS requests.
Replace net with address information
like 192.168/16. The
/16 at the end is an abbreviated expression for
the netmask, in this case, 255.255.0.0.
Controls which hosts can request zone transfers. In the example, such
requests are completely denied with ! *. Without
this entry, zone transfers can be requested from anywhere without
restrictions.
In the absence of this entry, BIND generates several lines of statistical
information per hour in
/var/log/messages. Set it to 0
to suppress these statistics completely or set an interval in
minutes.
This option defines at which time intervals BIND clears its cache. This
triggers an entry in /var/log/messages each time it
occurs. The time specification is in minutes. The default is 60 minutes.
BIND regularly searches the network interfaces for new or nonexistent
interfaces. If this value is set to 0, this is
not done and BIND only listens at the interfaces detected at start-up.
Otherwise, the interval can be defined in minutes. The default is sixty
minutes.
no prevents other name servers from being informed when
changes are made to the zone data or when the name server is restarted.
What, how, and where logging takes place can be extensively configured in BIND. Normally, the default settings should be sufficient. Example 22.3, “Entry to Disable Logging” shows the simplest form of such an entry and completely suppresses any logging.
Example 22.4. Zone Entry for example.com
zone "example.com" in {
type master;
file "example.com.zone";
notify no;
};
After zone, specify the name of the domain
to administer (example.com)
followed by in and a block of relevant options
enclosed in curly braces, as shown in Example 22.4, “Zone Entry for example.com”.
To define a slave zone,
switch the type to
slave and specify a name server that administers
this zone as master (which, in turn, may be a slave of
another master), as shown in Example 22.5, “Zone Entry for example.net”.
Example 22.5. Zone Entry for example.net
zone "example.net" in {
type slave;
file "slave/example.net.zone";
masters { 10.0.0.1; };
};The zone options:
By specifying master, tell BIND that the zone is
handled by the local name server. This assumes that a zone file has been
created in the correct format.
This zone is transferred from another name server. It must be used together
with masters.
The zone . of the hint type is used
to set the root name servers. This zone definition can be
left as is.
example.com.zone or file
“slave/example.net.zone”;
This entry specifies the file where zone data for the domain is located.
This file is not required for a slave, because this data is fetched from
another name server. To differentiate master and slave files, use
the directory slave for the slave files.
server-ip-address; };This entry is only needed for slave zones. It specifies from which name server the zone file should be transferred.
This option controls external write access, which would allow clients to
make a DNS entry—something not normally desirable for security
reasons. Without this entry, zone updates are not allowed at all. The
above entry achieves the same because ! * effectively
bans any such activity.
