 |
» |
|
|
|
|  | |
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: Issue the following command to generate the name server data files from the /etc/hosts file: Following is an example: Move the named.boot file to the /etc directory: 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
nameservers.
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: 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:
The Primary Master Server's Boot File | |
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: 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 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: - ;
Lines beginning with 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
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 5 “Installing and Administering sendmail” for information on sendmail and how it
uses the name server's MX records for mail routing.
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. 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:
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:
|
Printable version
