 |
» |
|
|
|
This section explains how to configure a primary master server
in your domain. It also describes the name server data files in
the primary master server configuration. It contains the following
sections: To Create the Data
Files for a Primary Master Server | |
Make sure the /etc/hosts file is up to date on the host that will be the
primary master server. On the host that will be the primary master, create
the /etc/named.data directory, where the name server data files will reside,
and make it the current directory: mkdir /etc/named.data
cd /etc/named.data |
Issue the following command to generate the name
server data files from the /etc/hosts file: /usr/sbin/hosts_to_named -d domainname -n network_number |
Following is an example: /usr/sbin/hosts_to_named -d div.inc.com -n 15.19.8 |
Move the named.boot file to the /etc directory: mv /etc/named.data/named.boot /etc/named.boot |
Copy the file /usr/examples/bind/db.cache.arpa to the /etc/named.data directory. This file is a list of root name servers. You
can also use anonymous ftp to get the current list of root name servers from rs.internic.net.
Instructions are included in the
/usr/examples/bind/db.cache.arpa file. Use the list of root name servers from the /usr/examples/bind/db.cache.arpa file or from rs.internic.net to update the /etc/named.data/db.cache file. The hosts_to_named program creates this file but does not add any
data to it. The format of the db.cache file is described in “The Primary Master
Server's Cache File”. If your network is isolated from the Internet, contact the
BIND administrator responsible for your domain to get the names
and addresses of the root name servers.
The hosts_to_named program creates the following data files in the directory
from which it is run. These files are described in the next few sections: db.cache (initially empty) db.domain (one file for each domain specified with the -d option) db.net (one file for each network number specified with
the -n option)
Naming these files db.name is a Hewlett-Packard convention. You can also create these files manually using a text editor.
If you choose to create them manually, you must convert all host
names to fully qualified domain names (names containing all labels
from the host to the root, terminated with a dot; for example, indigo.div.inc.com.). The hosts_to_named program completely rewrites the db.domain and db.net files. All manual modifications to these files
will be lost the next time you run hosts_to_named, except changes to SOA records. For more information, type man 1M hosts_to_named or man 1M named at the HP-UX prompt. To Set the Default
Domain Name | |
If you will be using an /etc/resolv.conf file on your host, configure the default domain
name with the search or domain keyword. See “Configuring the Resolver
to Query a Remote Name Server”. If you
will not be using an /etc/resolv.conf file, follow these steps: Set the default domain name with the hostname command, by appending the domain name to the host
name, as in the following example: /usr/bin/hostname indigo.div.inc.com |
Do not put a trailing dot at the end of the domain name. Set the HOSTNAME variable in the /etc/rc.config.d/netconf file to the same value, as in the following example: HOSTNAME=indigo.div.inc.com |
The BIND Configuration File | |
Starting with BIND 8.1.2, the BIND configuration file is /etc/named.conf which is very flexible and allows you to specify a number
of different features. The configuration file in the previous versions
of BIND was /etc/named.boot. To migrate the named.boot file to named.conf file,
see “Migrating /etc/named.boot to /etc/named.conf”. The configuration file,
/etc/named.conf consists of statements and comments. Statements
end with a semicolon. Many statements contain a block of sub-statements,
which are also terminated with a semicolon. Comments can be given
using the C syntax (with /* and */), the C++ syntax (where // starts
the comment), and the shell syntax (where # starts the comment). The following statements are supported in /etc/named.conf: The
acl statement in the /etc/named.conf file is typically used to define a named IP address
matching list for the purpose of access control, etc. This statement
is typically used inside a zone Statement. The syntax to use this statement is as follows: acl name { address_match_list }; The acl statement creates a named address match list. It gets
its name from a primary use of address match lists: Access Control
Lists (ACLs). Note that an address match list's name must be defined
with acl before it can be used elsewhere; no forward references
are allowed. The following ACLs are predefined: localhost - allows the IP addresses of all interfaces
on the system. localnets - allows any host on a network for which
the system has an interface.
acl can_query{ 1.2.3; any;}; The ACL statement, can_query, will allow queries from any host in network 1.2.3. The
include statement in /etc/named.conf inserts the specified file at the point where the include
statement is encountered in the configuration file. This statement
is used to break the configuration up into easily-manageable chunks. The syntax to use this statement is: include path_name; include /etc/security/keys.bind;
include /etc/acls.bind;
|
The ACL statement, can_query, will allow queries from any host in network 1.2.3. The
key statement in the /etc/named.conf file specifies information for use in authentication
and authorization. It checks for syntax only. The syntax to use
the key statement is as follows: key key_id {algorithm algoritm_id;
secret secret_string; }; |
The algorithm_id is a string that specifies a security or authentication algorithm.
The parameter secret_string is the secret to be used by the algorithm. The key statement defines a key ID that can be used in a server statement
to associate an authentication method with a particular name server.
A key ID must be created with the key statement before it can be used
in a server definition. The logging statement in the /etc/named.conf file specifies what the server logs and where
the log messages are sent. The logging statement also configures
a wide variety of logging options for the name server. The logging statement configures the logging system, which
send messages to one or more channels. Specifying the Number of Log File BackupsIf you specify the versions (number|unlimited) options in the logging statement, then named
will retain the specified number of backup versions of the log file
by renaming them when opening. For example, if you choose to keep 3 old versions of the file
lame.log, then just before it is opened lame.log is renamed to lame.log.2, lame.log.0 is renames to lame.log.1, and lame.log is renamed to lame.log.0. Following the logging keyword is a list of statements enclosed
in braces. The syntax for the logging statement is as follows: logging {
[channel channel_name{
(file path_name
[versions (number | unlimiter)]
[size size_spec ]
|syslog (kern | user | mail | daemon | auth | syslog |\
lpr | news | uucp | cron | authpriv | ftp| local0 |
local1 | local2 | local3 | local4 | local5 | local6 |
local7 ) | null);
[ severity (critical | error | warning | notice |
info | debug [level ] | dynamic) ; ]
[print-category yes_or_no;]
[print-severity yes_or_no;]
[print-time yes_or_no;]
};]
[category category_name {
channel_name; [ channel_name; ... ]
}; ]
. . .
}; |
Example logging StatementThis section provides an example log configuration. The default
for most categories is default_syslog and default_debug. logging{
Channel lame {
File lame-servers.log;
Size 10M; Severity info;
};
channel log { syslog local0;};
category lame-server {lame;};
category default {log;};
}; |
Channels and Channel MessagesA channel describes a destination: a file, syslog, or the
bit bucket. A channel associates output methods, format options
and severity levels with a name. This name can be used to select
how various categories of messages are logged. A channel can do the following: limit incoming messages to a given
severity level. place a limit on the size of the logging file. manage multiple versions of the logging file (to
maintain historic data). direct the logging messages to any of the syslog
facilities.
There are several default channels, and you can define more
channels in the logging statement in the configuration file. Not
that only one logging statement is used to define as many channels
and categories as you want. If there are multiple logging statements
in a configuration, the first defined statement determines the logging
configuration and warnings are issued for the others. The
severity levels include all the syslog severities as well as multiple
debug levels. These levels correspond to the different debugging
levels present in named (the BIND 8.x daemon) and are ranked so that higher
levels are less severe. Thus, a channel can be configured for debug
level 3, and it will also accept and log messages at levels 2 and
1. The default channels are shown as follows: default_syslog Sends messages to the daemon facility at severity info and
higher. (info is a predefined severity level that allows messages
of its severity level or higher to be logged to the channel.) default_debug Sends messages tot he file named.run and tracks the daemon's current dynamic
debug level. default_stderr Sends messages of severity info and higher to standard error. null Discards everything it receives.
There is a large collection of message categories listed in Table 3-1 “Channel Message Categories”. A list of channels can be assigned to each
message category; messages from that category will then be sent
to every channel in the list. The default category is a catchall used for unclassified messages
and for categories that do not have a channel list explicitly defined.
Categories are listed in Table 3-1 “Channel Message Categories”. Table 3-1 Channel Message Categories Message Category | Description |
|---|
config | High-level configuration file processing | parser | Low-level configuration file processing | queries | Incoming queries | lame -servers | Messages about lame-servers | | cname | Messages about cname records | | ncache | Negative caching | xfer-in | Zone transfers the server is receiving | | xfer-out | Zone transfers the server is sending | | eventlib | Debugging information from the event system | | packet | Dumps of packets received and sent | | notify | The NOTIFY protocol | | security | Approved/unapproved requests | | insist | Internal consistency check failures | | db | Database operations | | os | Operating System problems | | maintenance | Periodic maintenance events | | load | Zone loading messages | | response-checks | Messages arising from response checking | | default | Unclassified messages and categories that do
not have a channel list explicitly defined. |
options Statement | |
The
options statement in the /etc/named.conf file controls global server configuration options
that are used by BIND 8.1.2. This statement may appear only once
in a configuration file. If it is found more than once, the first
occurrence determines the actual options used. Also a warning is
generated if more than one statement is found. If the options statement
is not specified, the default is used. The syntax for the options statement is as follows: |
options {
[ directory path_name; ]
[ named-xfer path_name; ]
[ dump-file path-name; ]
[ memstatistics-file path_name; ]
[ pid-file path_name; ]
[ auth-nxdomain yes_or_no;]
[ deallocate-on-exit yes_or_no; ]
[ fake-iquery yes_or_no; ]
[ fetch-glue yes_or_no; ]
[ host-statistics yes_or_no; ]
[ multiple-cnames yes_or_no; ]
[ notify yes_or_no; ]
[ recursion yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { [ in_addr ; ...] ] }; ]
[ check-names (master | slave | response) (warn |fail\
| ignore) ]
[ allow-query { address_match_list}; ]
[ allow-transfer { address_match_list } ; ]
[ listen-on [ port ip_port ] { address_match_list }; ]
[ query-source [ address (ip_addr | * ) ] [port (ip_port|\
* )
] ; ]
[ max-transfer-time-in number; ]
[ transfer-format (one-answer | many-answers); ]
[ transfers-in number; ]
[ transfers-out number; ]
[ transfers-per-ns number; ]
[ coresize size_spec ; ]
[ datasize size_spec ; ]
[ files size_spec ; ]
[ stacksize size_spec ; ]
[ cleaning-interval number; ]
[ interface-interval number; ]
[ statistics-interval number; ]
[ sortlist [ ip_addr; . . . } ]
[ noforward { [domain ; [ domain ; . . . ] ] }; ]
[ no-round-robin; ]
}; |
|
Table 3-2 “HP-Specific option Statement Options” lists the various options available. Table 3-2 HP-Specific option Statement Options Option | Description |
|---|
noforward
{ [ domain; [domain; . . . ]]}; | The noforward line specifies that the DNS server will not forward
any request for something in or below the listed domains, even if
the forwarders directive exists. | no-round-robin | The no-round-robin option turns off the default round-robin, which
cycles returned IP addresses for multi-homed hosts. | alias_ip | The alias_ip directive used in ServiceGuard environment
allows named to use relocatable IP addresses. |
Table 3-3 Pathname Options Option | Description |
|---|
directory path_name; | This is the working directory of the
server. Any non-absolute path names in the configuration file will
be taken as relative to this directory. The default location for most
server output files (for example named.run) is this directory. If a directory is not specified,
the working directory defaults to ".", the directory from which
the server was started. The directory specified should be an absolute path. | named-xfer path_name; | The pathname to the named-xfer program
that the server uses for inbound zone transfers. If this is not
specified, the default is system dependent (for example /usr/sbin/name-d-xfer) | dump-file path_name; | The pathname of the file to which the
server dumps the database when it receives SIGINT signal. If this
is not specified, the default is named_dump.db | memstatistics-file path_name; | The pathname of the file to which the server
writes memory statistics on exit, if deallocate-on-exit is yes.
If not specified, the default is named.memstats. | pid-file path_name; | This is the pathname of the file to which
the server writes its process ID. If this is not specified, the
default is /var/run/named.pid or /etc/named.pid. The pid-file is used by programs that send signals to the running
nameserver. | statistics-file path_name; | This is the pathname of the file to which
the server appends statistics when it receives SIGILL signal. If
this is not specified, the default is named.stats. |
Table 3-4 Boolean Options Option | Description |
|---|
auth-nxdomain yes_or_no; | If specified as yes, then the AA bit
is always set on NXDOMAIN responses, even if the server is not actually authoritative.
The default is yes. | deallocate-on-exit yes_or_no; | If this is specified as yes, then when
the server exits, it will deallocate every object it allocated,
and then writes a memory usage report to the file specified by memstatistics-file.
The default is no because it is faster to let the operating system
clean up. However, deallocate-on-exit can be useful for detecting memory
leaks. | fake-iquery yes_or_no; | If this is yes, the server will simulate
the obsolete DNS query type IQUERY. The default is no. | fetch-glue yes_or_no; | The default is yes. The sever will fetch
glue resource records it doesn't have when constructing
the additional data section of a response. fetch-glue can be used in conjunction with recursion no to
prevent the server's cache from growing or becoming corrupted. | host-statistics yes_or_no; | If this is set to yes, then statistics
are kept for every host that the nameserver interacts with. The
default is no. Note that turning on host-statistics can consume
lots of memory. | multiple-cnames yes_or_no; | If this is set to yes, then multiple
CNAME resource records will be allowed for a domain name. The default is no.
Allowing multiple CNAME records is against the standard and is NOT
recommended. Multiple CNAME support is available because previous
versions of BIND allowed multiple CNAME records, and those records were
used for load balancing. | notify yes_or_no; | The default is yes. When set to yes,
DNS NOTIFY messages are sent when a zone for which the server is authorized
changes. The use of NOTIFY speeds convergence between the master
and its slaves. A slave server that received a NOTIFY message and
understands it will contact the master server for the zone and see
if a zone transfer is needed. If this is the case, the slave server
will initiate the zone transfer immediately. The notify option may
also be specified in the zone statement, in which case, it overrides
the options notify statement. | recursion yes_or_no; | If this is yes, a DNS query requests
recursion, then the server will attempt to do all the work required
to answer the query. If this is no, then recursion is not on, the server
will return a referral to the client if it doesn't know the
answer. The default is yes. |
The forwarding facility can be used to create a large site-wide
cache on a few servers, reducing traffic over links to external
name servers. It can also be used to allow queries by servers that
do not have direct access to the Internet, but wish to look up exterior
name anyway. Forwarding occurs only on the queries for which the
server is not authoritative and does not have the answer in its
cache. Table 3-5 Forwarding Options Option | Description |
|---|
| forward (only | first); | This option is only meaningful if the
forwarders list is not empty. The default value is first. When first is specified, the server queries the forwarders
first. If only is specified, the server will query only the forwarders. | forwarders { [ in_addr ; [ in_addr ; . . . ] ] }; | This specifies the IP addresses to be
used for forwarding. The default is empty list or no forwarding. |
The server can check domain names based on their expected
client contexts. For example, a domain name that is used as a hostname
can be checked for compliance with the RFCs defining valid hostnames. check-names (master | slave | response ) (warn | fail |\ ignore); |
The server can check names in three areas: master: check master zone files slave: check slave zone files response: check in response to queries the server has initiated.
Three checking methods are available for check-names: ignore: no checking is done. warn: names are checked against their expected client
contexts. Invalid names are logged, but processing continues normally. fail: names are checked against their expected client
contexts. Invalid names are logged, and the offending data is rejected.
The defaults are check-names master fail; check-names slave warn; and check-names response ignore. If check-names response fail is specified, the server will send a REFUSED response
code to the client. check-names may also be specified in the zone statement, in
which case it overrides the options check-names statement. (When
used in a zone statement, the area is not specified, because it
can be deduced from the zone type.) Access to the server can be restricted based on the IP address
of the requesting system. See address_match_list for details on how to specify IP address lists.
The access control options are listed in Table 3-6 “Access Control Options” below. Table 3-6 Access Control Options | Options | Descriptions |
|---|
| allow-query { address_match_list} ; | This specifies which hosts are allowed
to ask ordinary questions. allow-query may also be specified in the
zone statement. If it is specified in the zone statement, it overrides
the options allow-query statement. The default is to allow queries
from all hosts. | allow-transfer { address_match_list}; | This specifies which hosts are allowed
to receive zone transfers from the server. The allow-transfer option may also be specified in the zone statement.
If it is specified in the zone statement, it overrides the options allow-transfer statement. The default is to allow transfers from
all hosts. |
listen-on [port ip_port]\ {address_match_list}; The interfaces and ports from which the server will answer
queries may be specified using the listen-on option. The listen-on option takes an optional
port and an address_match_list. The server will listen on all interfaces allowed
by the address match list. If a port is not specified, port 53 will
be used. If no listen-on is specified, the server will listen on port 53
on all interfaces. Multiple listen-on statements are allowed. Here's an example: listen-on { 5.6.7.8; } ;
listen-on port 1234 { 11.2.3.4; 1.2/16; } ; |
Table 3-7 “Zone Transfer Options” lists the zone transfer options. Table 3-7 Zone Transfer Options Options | Description |
|---|
max-transfer-
time-in number; | Inbound zone transfers (named-xfer processes)
that run longer than the minutes specified will be terminated. The
default is 120 minutes (2 hours). | transfer-format (one-answer | many-answers ); | The server supports two zone transfer
methods. one-answer uses one DNS message per resource record transferred. many-answers packs as many resource records as possible into
a message. many-answers is more efficient, but only understood by BIND 8.1.2
and patched versions of BIND 4.9.7. The default is one-answer. The transfer-format option may be overridden on a per-server basis
by using the server statement. | transfer-in number; | The maximum number of inbound zone transfers
that can be running concurrently. The default value is 10. Increasing transfer-in may speed up the coverage of slave zones, but
it also may increase the load on the local system. | transfers-out number; | This option will be used in the future
to limit the number of concurrent outbound zone transfers. Currently,
it is checked for syntax, but is otherwise ignored. | transfers-per-ns number; | The maximum number of inbound zone transfers
(named-xfer processes) that can be concurrently transferring
from a given remote nameserver. The default value is 2. Increasing transfers-per-ns may speed up the convergence of slave zones, but
it also may increase the load on the remote nameserver. The transfers-per-ns may be overridden on a per-server basis by using
the transfers phrase of the server statement. |
The server's usage of many system resources can be
limited. If a specific limit is not supported on a given operating
system, a warning will be issued. Scaled values are allowed when specifying resource limits.
For example, 1G can be used instead of 1073741824 to specify a limit
of one gigabyte. Specifying unlimited requests unlimited use, or
the maximum available amount. default uses the limit that was in
effect when the server was started. Table 3-8 “Resource Limits Options” lists
the resource options available. Table 3-8 Resource Limits Options Options | Description |
|---|
coresize size_spec ; | The maximum size of a core dump. The default
is default. | datasize size-spec ; | The maximum amount of data memory the
server may use. The default is default. | file size_spec ; | The maximum number of files the server
may have open concurrently. The default is unlimited. Note that on some operating systems, the server
cannot set an unlimited value and cannot determine the maximum number
of open files the kernel can support. On such systems, specifying unlimited will cause the server to use the larger of the rlim_max for RLIMIT_NOFILE and the value returned by sysconf(_SC_OPEN_MAX).
If the actual kernel limit is larger than this value, use limit
files to specify the limit explicitly. | stacksize size_spec ; | The maximum amount of stack memory the
server may use. The default is default. |
Periodic Task Intervals Options:The periodic Task Intervals Options are listed in Table 3-9 “Periodic Task Intervals Options” below. Table 3-9 Periodic Task Intervals Options Options | Description |
|---|
cleaning-interval number; | The server will remove expired resource
records from the cache after the specified cleaning-interval minutes.
The default is 60 minutes. If set to 0, no periodic cleaning will
occur. | interface-
interval number; | This specifies how frequently the server
will scan the network interface list (in minutes). If this is set
to 0, interface scanning will only occur when the configuration
file is loaded. After he scan listeners will be started on any new
interfaces (provided they are allowed by the listen-on configuration).
Listeners on interfaces that have gone away will be cleaned up. | statistics-
interval number; | This specifies how frequently the nameserver
statistics will be logged. The default is 60. If this is set to
0, no statistics are logged. | sortlist { ip_addr; ...} | The sortlist line can be used to indicate networks
that are preferred over other, unlisted networks. Address sorting
only happens when the query is from a host on the same network as
the server. The best address is placed first in the response. The
address preference order is local network addresses on the sort
list, then other addresses. |
The
server statement in the /etc/named.conf file defines the characteristics associated with
remote name server. For example, if you know that a name server
is giving out bad data, you can mark it as bogus to prevent further queries to it. The server supports two zone transfer methods that can be
defined within the transfer-format phrase in the server statement. transfer-format one-answer; Each resource record gets its own DNS message. This format
is not the most efficient, but is widely understood. transfer-format many-answers; As many resource records as will fit are put into each DNS
message. This format is the most efficient and works with BIND 8.1.2.
You can specify which of the two methods to use for a server
with the transfer-format option within the server statement. If transfer-format is not specified, then the transfer-format specified by the options Statement will be used. The syntax to use the server statement is as follows: server ip_addr {
[ bogus yes_or_no; ]
[ transfers number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ keys { key_id [key_id ...] } ; ]
};
|
The
zone statement in the /etc/named.conf file is used to define a zone. It declares the zone
as one of four types: master, slave, stub, hint master-- This is the master copy of
the data in a zone. slave-- A slave zone is a replica of a master zone.
The master list specifies one or more IP addresses that the slave
contacts to update its copy of the zone. If file is specified, then
the replica will be written to the file specified. Use of file is
recommended, since it often speeds server startup and eliminates
a needless waste of bandwidth. stub-- A stub zone is like a slave zone, except
that it replicates only the name server records of a master zone
instead of the entire zone. hint-- The initial set of root name servers is specified
using a hint zone. When the server starts up, it uses the root hints
to find a root nameserver and gets the most recent list of root
name servers.
Specifying Access LimitationsSpecify any access limitations for the zone in the zone statement.
Three types of access can be controlled: updates, queries, and transfers.
The access control can be specified globally through the options
statement. The syntax to use for zone statements is as follows: zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type master;
file path_name;
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type ( slave | stub );
[ file path_name; ]
masters { ip_addr; [ ip_addr; ... ] };
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ max-transfer-time-in number; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
};
zone . [ ( in | hs | hesiod | chaos ) ] {
type hint;
file path_name;
[ check-names ( warn | fail | ignore ); ]
} ; |
Migrating /etc/named.boot to /etc/named.conf | |
To convert the BIND configuration file, /etc/named.boot to /etc/named.conf follow
the below steps. Make sure that perl is installed
on the system. The "hosts_to_named" script has to be copied to
/usr/sbin and a link should be provided from /usr/bin. A perl script "named-bootconf.pl" is available in
/usr/bin. This script is used to convert the existing named.boot
file to named.conf file. The new BIND configuration file "named.conf" can
be created in either of the two methods discussed below: If the configuration file "named.boot"
already exists, create the new configuration file executing the
command: /usr/bin/named-bootconf.pl named.boot > named.conf If a BIND configuration file does not exist: execute hosts_to_named with appropriate options
The Primary Master
Server's Boot File | |
Prior to BIND 8.1.2, the /etc/named.boot file was the configuration file used for BIND. The
boot file, /etc/named.boot, tells the primary master server the location
of all the data files it needs. The primary name server loads its
database from these data files. The hosts_to_named program creates the named.boot file. Following is an example boot file for a primary server authoritative
for the div.inc.com domain and for networks 15.19.8 and 15.19.13: ; domain source file
; type
;
directory /etc/named.data ;running directory for named
primary div.inc.com db.div
primary 0.0.127.IN-ADDR.ARPA db.127.0.0
primary 8.19.15.IN-ADDR.ARPA db.15.19.8
primary 13.19.15.IN-ADDR.ARPA db.15.19.13
cache db.cache |
Every name server must have data for the 0.0.127.IN-ADDR.ARPA domain. Hosts running Berkeley networking use
127.0.0.1 as the address of the loopback interface. Since the network
number 127.0.0 is not assigned to any one site but is used by all
hosts running Berkeley networking, each name server must be authoritative
for network 127.0.0. - ;
Lines beginning with a semicolon (;) are comments. - directory
Indicates the directory where data files are located. - primary
Designates a primary server for the domain in the second
field. The third field is the name of the file containing the data
for that domain. - cache
Indicates the location of the cache file, which
contains the addresses of network root name servers.
The Primary Master
Server's Cache File | |
The cache file, /etc/named.data/db.cache, lists the servers for the root domain. Every
name server must have a cache file. When a name server cannot resolve
a host name query from its local database or its local cache, it
queries a root server. The hosts_to_named program creates the db.cache file, but it leaves it empty. To add data to this
file, copy it from the file /usr/examples/bind/db.cache.arpa. You can also use anonymous ftp to get the list of root name servers from nic.ddn.mil. Instructions are included in the file /usr/examples/bind/db.cache.arpa. Following is an example db.cache file for a primary master server: ;
; This file holds the information on root name servers needed
; to initialize cache of Internet domain name servers
;
; last update: May 11, 1994
; related version of root zone: 940516
;
; name ttl class type data
;
. 99999999 IN NS NS.INTERNIC.NET.
NS.INTERNIC.NET. 99999999 A 198.41.0.4
. 99999999 NS NS1.ISI.EDU.
NS1.ISI.EDU. 99999999 A 128.9.0.107
. 99999999 NS C.NYSER.NET.
C.NYSER.NET. 99999999 A 192.33.4.12
. 99999999 NS TERP.UMD.EDU.
TERP.UMD.EDU. 99999999 A 128.8.10.90
. 99999999 NS NS.NASA.GOV.
NS.NASA.GOV. 99999999 A 128.102.16.10
99999999 A 192.52.195.10
. 99999999 NS NS.NIC.DDN.MIL.
NS.NIC.DDN.MIL. 99999999 A 192.112.36.4
. 99999999 NS AOS.ARL.ARMY.MIL.
AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82
99999999 A 192.5.25.82
. 99999999 NS NIC.NORDU.NET.
NIC.NORDU.NET. 99999999 A 192.36.148.17 |
|
- ;
Lines beginning with a semicolon (;) are comments. - name
In NS records, the name of the domain served by the name
server listed in the data column. A period (.) in the name column represents the root domain (the root of
the DNS name space hierarchy). In A records, the name column contains the name of the name server whose
address appears in the data column. - ttl
The optional time-to-live (ttl) indicates how long, in seconds, a server may
cache the data it receives in response to a query. - class
The optional class field specifies the protocol group. IN, for internet addresses, is the most common class.
If left blank, the class defaults to the last class specified. So,
all the entries in this example db.cache file are of class IN. - type
Type NS records list name servers. The first field in
an NS record is the domain for which the name server
has authority. The last field in an NS record is the fully qualified name of the name
server. Type A records list addresses. The first field in an A record is the name of the name server. The last
field in an A record is the internet address of the name server. - data
The data field for an NS record gives the fully qualified name of a name
server. The data field for an A record gives an internet address.
The db.127.0.0 File | |
Each name server must have an /etc/named.data/db.127.0.0 file. Hosts running Berkeley networking use 127.0.0.1
as the address of the loopback interface. Since the network number
127.0.0 is not assigned to any one site but is used by all hosts
running Berkeley networking, each name server must be authoritative
for network 127.0.0. The file db.127.0.0 contains the resource record that maps 127.0.0.1
to the name of the loopback address, usually localhost. The hosts_to_named program creates this file. ;name class type data
@ IN SOA rabbit.div.inc.com. root.moon.div.inc.com. (
1 ; Serial
10800 ; Refresh every 3 hours
3600 ; Retry every hour
604800 ; Expires after a week
86400 ) ; Minimum ttl of 1 day
@ IN NS rabbit.div.inc.com.
1 IN PTR localhost. |
|
- name
The name of the subdomain. In data files, @ represents the current origin. The current origin
is the domain configured in this file, according to the boot file.
The boot file says that the 0.0.127.in-addr.arpa domain is configured in the db.127.0.0 file. Therefore, every instance of @ in the db.127.0.0 file represents 0.0.127.in-addr.arpa. The current origin is also appended to names that do not end
with a dot. For example, the 1 in the PTR line would be interpreted as 1.0.0.127.in-addr.arpa. - class
The optional class field specifies the protocol group. IN, for internet addresses, is the most common class. - type
The SOA (start-of-authority) record designates the start of
a domain, and indicates that this server is authoritative for the
data in the domain. The NS record designates a name server for the current origin
(0.0.127.in-addr.arpa). PTR records are usually used to associate an address
in the in-addr.arpa domain with the canonical name of a host. The PTR record in the example db.127.0.0 file associates the name localhost with the address 1.0.0.127.in-addr.arpa. (The current origin is appended to the 1 in the name field, because it does not end with a dot.) - data
The SOA data includes the name of the host this data file
was created on, the mailing address of the person responsible for
the name server, and the following values: - Serial
The version number of this file, incremented whenever
the data is changed. - Refresh
Indicates (in seconds) how often a secondary name
server should try to update its data from a master server. - Retry
Indicates (in seconds) how often a secondary server
should retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the secondary name
server can use the data before it expires for lack of a refresh. - Minimum ttl
The minimum number of seconds for the time to live
field on other resource records for this domain.
The NS data is the fully qualified name of the name server. The PTR data is the loopback address of localhost, in the in-addr.arpa domain.
The Primary Master
Server's db.domain Files | |
A primary server has one /etc/named.data/db.domain file for each domain for which it is authoritative. domain is the first part of the domain specified with
the -d option in the hosts_to_named command. This file should contain an A (address) record for every host in the zone. The example file shown below, db.div, contains the following types of records: - SOA
Start of Address record. The SOA record designates the start of a domain, and indicates
that this server is authoritative for the data in the domain. In data files, @ represents the current origin. The current origin
is the domain configured in this file, according to the boot file.
The boot file says that the div.inc.com domain is configured in the db.div file. Therefore, every instance of @ in the db.div file represents div.inc.com. The SOA record indicates the name of the host this data file
was created on, the mailing address of the person responsible for
the name server, and the following values: - Serial
The version number of this file, incremented whenever
the data is changed. - Refresh
Indicates (in seconds) how often a secondary name
server should try to update its data from a master server. - Retry
Indicates (in seconds) how often a secondary server
should retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the secondary name
server can use the data before it expires for lack of a refresh. - Minimum ttl
The minimum number of seconds for the time to live
field on other resource records for this domain.
- NS
Name Server records. The NS records give the names of the name servers and
the domains for which they have authority. The domain for the name
servers in the example is the current origin (div.inc.com), because @ was the last domain specified. - A
Address records. The A records give the internet addresses for all the
hosts in the domain. The current origin is appended to names that do not end with
a dot. For example, localhost in the first A record is interpreted as localhost.div.inc.com. - HINFO
Host Information records. The HINFO records indicate the hardware and operating system
of the host. - CNAME
Canonical Name record. The CNAME record specifies an alias for a canonical name
(the host's official name). If an alias name is looked
up, it is replaced with the canonical name and data for the canonical
name is looked up. All other resource records should use the canonical
name instead of the alias. - WKS
Well Known Service records. The WKS record lists the services supported by a host.
The list of services comes from the host's /etc/services file. There should be only one WKS record per protocol per address. - MX
Mail Exchanger records. MX records specify a weighted list of hosts to try
when mailing to a destination on the Internet. The MX data indicates an alternate host or list of hosts
that accept mail for the target host if the target host is down
or inaccessible. The preference field specifies the order a mailer
should follow if there is more than one mail exchanger for a given
host. A low preference value indicates a higher precedence for the mail
exchanger. In the example below, mail for rabbit should go first to rabbit.div.inc.com. If rabbit is down, its mail should be sent to indigo.div.inc.com. See Chapter 4 “Installing and Administering sendmail” for information on
sendmail and how it uses the name server's
MX records for mail routing.
|
;
; db.div
;
@ IN SOA rabbit.div.inc.com. root.moon.div.inc.com.(
1 ; Serial
10800 ; Refresh every 3 hours
3600 ; Retry every hour
604800 ; Expires after a week
86400 ) ; Minimum ttl of 1 day
IN NB rabbit.div.inc.com
IN NS indigo.div.inc.com.
localhost IN A 127.0.0.1
indigo IN A 15.19.8.197
IN A 15.19.13.197
IN HINFO HP9000/840 HPUX
incindigo IN CNAME indigo
cheetah IN A 15.19.8.64
IN HINFO HP9000/850 HPUX
IN WKS 15.19.8.64 UDP syslog domain route
IN WKS 15.19.8.64 TCP (telnet smtp ftp
shell domain)
rabbit IN MX 5 rabbit.div.inc.com.
IN MX 10 indigo.div.inc.com.
rabbit IN A 15.19.8.119 |
The Primary Master
Server's db.net Files | |
A primary server has one db.net file for each network it serves. net is the network number specified with the -n option in the hosts_to_named command. This file should contain a PTR (pointer) record for every host in the zone. A PTR record allows BIND to translate an IP address
back into its host name. BIND resolves the address of a name by
tracing down the domain tree and contacting a server for each label
of the name. The in-addr.arpa domain was created to allow this inverse mapping. The in-addr.arpa domain is preceded by four labels corresponding
to the four bytes (octets) of an internet address. Each byte must
be specified even if it is zero. For example, the address 143.22.0.3
has the domain name 3.0.22.143.in-addr.arpa. Note that the four octets of the address are
reversed. ;
; db.15.19.8
;
@ IN SOA rabbit.div.inc.com. root.moon.div.inc.com.(
1 ; Serial
10800 ; Refresh every 3 hours
3600 ; Retry every hour
604800 ; Expire after a week
86400 ) ; Minimum ttl of 1 day
IN NS rabbit.div.inc.com.
IN NS indigo.div.inc.com.
119 IN PTR rabbit.div.inc.com.
64 IN PTR cheetah.div.inc.com.
197 IN PTR indigo.div.inc.com. |
This example file, db.15.19.8, contains the following records: - SOA
Start of Address record. The SOA record designates the start of a domain, and indicates
that this server is authoritative for the data in the domain. In data files, @ represents the current origin. The current origin
is the domain configured in this file, according to the boot file.
The boot file says that the 8.19.15.in-addr.arpa domain is configured in the db.15.19.8 file. Therefore, every instance of @ in the db.15.19.8 file represents 8.19.15.in-addr.arpa. The SOA record indicates the name of the host this data file
was created on, the mailing address of the person responsible for
the name server, and the following values: - Serial
The version number of this file, incremented whenever
the data is changed. - Refresh
Indicates (in seconds) how often a secondary name
server should try to update its data from a master server. - Retry
Indicates (in seconds) how often a secondary server
should retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the secondary name
server can use the data before it expires for lack of a refresh. - Minimum ttl
The minimum number of seconds for the time to live
field on other resource records for this domain.
- NS
Name Server records. The NS records give the names of the name servers and
the domains for which they have authority. The domain for the name
servers in the example is the current origin (8.19.15.in-addr.arpa), because @ was the last domain specified. - PTR
Pointer records. PTR records are usually used to associate an address
in the in-addr.arpa domain with the canonical name of a host. The
first PTR record in the example file associates the name rabbit.div.inc.com with the address 119.8.19.15.in-addr.arpa. (The current origin is appended to the 119 in the first field, because it does not end with
a dot.)
To Add a Host to the
Domain Data Files | |
Add the host to /etc/hosts and run hosts_to_named again. or Add the host manually, as follows: Edit db.domain. Add an Address (A) resource record for each address of the new host.
Add CNAME, HINFO, WKS, and MX resource records as necessary. Increment the serial
number in the SOA resource record. Edit db.net. Add a PTR resource record for each host address. Increment
the serial number in the SOA resource record. Add the host to the /etc/hosts file. If the host is not listed in /etc/hosts, someone might run hosts_to_named, which overwrites your db.domain and db.net files, and the host will be lost.
Examples of these records are shown in “The Primary Master
Server's db.domain Files” and “The Primary Master
Server's db.net Files”. After modifying the domain data files, issue the
following command to restart the name server and force it to reload
its databases: /usr/sbin/sig_named restart |
To Delete a Host from
the Domain Data Files | |
Delete the host from /etc/hosts and run hosts_to_named again. or Delete the host manually, as follows: Edit db.[domain]. Delete all A, CNAME, HINFO, WKS, and MX resource records associated with the host. Increment
the serial number in the SOA resource record. Edit db.[net]. Delete all PTR resource records for the host. Increment the serial
number in the SOA resource record.
After modifying the domain data files, issue the
following command to restart the name server and force it to reload
its databases: /usr/sbin/sig_named restart |
|
