 |
» |
|
|
 |
This section describes how to configure a master server in
your domain. It also describes the name server data files in the
master server configuration. It discusses the following topics: Creating
the Data Files for a Master Server |  |
The following lists the steps to configure the master name
server: Ensure that the /etc/hosts file is updated on the host that you want to configure
as the master server. On the host that you want to configure as the master
server, create a temporary directory /etc/named.data, where you want to store the name server data
files, 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 hosts_to_named statement: /usr/sbin/hosts_to_named -d div.inc.com -n 15.19.8 |
Issue the following command to move the /etc/named.data/named.conf file to the /etc directory: mv /etc/named.data/named.conf /etc/named.conf |
Copy the /usr/examples/bind/db.cache file 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 file. Use the list of root name servers from the /usr/examples/bind/db.cache 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 “Master
Server Cache File”. If your network is isolated from the Internet, contact the
BIND administrator for your domain to obtain the names and addresses
of the root name servers.
The hosts_to_named program creates the following data files in the working
directory: 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 an HP 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 the
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 the manual modifications to these files
are lost when you run the hosts_to_named program again, except the changes to the SOA records. For more information, type man 1M hosts_to_named or man 1M named at the HP-UX prompt. Setting
the Default Domain Name |  |
If you are 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” for more information. If you are not using an
/etc/resolv.conf file, complete the following steps to set the
default domain name: Set the default domain name using the hostname command, by appending the domain name to the host
name, as shown in the following example: /usr/bin/hostname indigo.div.inc.com |
Do not insert 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 specified in the following
example: HOSTNAME=indigo.div.inc.com |
Master
Server Configuration File |  |
The configuration file, /etc/named.conf, informs the master server of the location of
all the required data files. The master name server loads its database
from these data files. The hosts_to_named program creates the named.conf file. Following is an example configuration file for a master server authoritative
for the domain div.inc.com, and for the network 15.19.8. # # type domain source file # option { directory “/etc/named.data”; }; zone “0.0.127.IN-ADDR.ARPA” { type master; file “db.127.0.0”; }; zone “div.inc.com” { type master; file “db.div”; }; zone “8.19.15.IN-ADDR.ARPA” { type master; file “db.15.19.8”; }; zone “.” { type hint; file “db.cache”; };
|
Figure 2-1 “Structure
of a Master Server and Slave Servers” shows the structure
of a master server and a slave server. In the Figure 2-1 “Structure
of a Master Server and Slave Servers”, the master server is rabbit.div.inc.com and the slave servers are cheetah.div.inc.com and indigo.div.inc.com. For the setup in Figure 2-1 “Structure
of a Master Server and Slave Servers”,
the /etc/hosts file is as follows: 15.19.8.119 rabbit 127.0.0.1 localhost loopback 15.19.8.64 cheetah 15.19.8.197 indigo incindigo |
Use the following parameters for the hosts_to_named command to generate the example named.conf file for the master server rabbit from the /etc/hosts file: -d div.inc.com name domain -n 15.19.8 net address domain -s rabbit master server -s cheetah slave servers -s indigo -Z 15.19.8.119 master server address -d div.inc.com |
The configuration file named.conf is as follows: // generated by named-bootconf.pl options { check-names response fail; // do not change this check-names slave warn; directory “/etc/named.data”; // running directory for named /* If there is a firewall between you and the nameservers you * want to talk to, you might need to uncomment the * query-source directive below. Previous versions of BIND * always asked questions using port 53, but BIND 8.1 uses * a privileged port by default. /* // query-source address *port 53; }; // // type domain source file // // zone “0.0.127.IN.ADDR.ARPA” { type master; file “db.127.0.0”; }; zone “div.inc.com” { type master; file “db.div”; }; zone “8.19.15.IN.ADDR.ARPA” { type master; file “db.15.19.8”; }; zone “.” { type master; file “db.root”; }; |
The following describes the various fields used in the named.conf file: - //
Lines beginning with // are comments. - directory
Indicates the directory where data files are located. - zone
Used to define the zone for that domain. - type
Defines the zone type. - file
Used to specify the database file for that zone.
 |  |  |  |  | NOTE: If you are moving your name server data and configuration
files from earlier versions of BIND 8 to this version, then you
must migrate your old configuration file format to the new file
format. The configuration file in versions prior to BIND 8 was called named.boot. You can convert named.boot to named.conf by executing the following command:/usr/bin/named-bootconf.pl named.boot>named.conf |
|  |  |  |  |
Master
Server Cache File |  |
The cache file, /etc/named.data/db.cache, lists the root name servers for the root domain.
Each 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,
the name server queries a root server. The hosts_to_named program creates the db.cache file, but does not enter any data into the db.cache file. To add data to this file, copy data from
the file /usr/examples/bind/db.cache. You can also use anonymous ftp to obtain the list of root name servers from rs.internic.net. Following is an example db.cache file for a master server:  |
; This file holds the information on root name servers ; needed to initialize cache of Internet domain name servers ; (e.g. reference this file in the “cache.<file>” ; configuration file of BIND domain name servers). ; This file is made available by InterNIC registration ; services under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; ; last update: Nov 5, 2002 ; related version of root zone: 2002110501 ; ; formerly NS.INTERNIC.NET ; name ttl class type data ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.EDU ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc ; ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 ; ; housed in LINX, operated by RIPE NCC ; ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; . 3600000 NS L.ROOT-SERVERS.NET L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
|
 |
The following describes the fields in the db.cache file: - ;
Lines beginning with a semicolon (;) are comments. - name
For NS records, name specifies 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). For 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 caches
the data received in response to a query. - class
The optional class field specifies the protocol group. The protocol
group IN, for Internet addresses, is the most common class.
If you do not specify this field, the class defaults to the last
class specified. All the entries in the example db.cache file are of class IN. - type
Records of type NS list the 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. For records of type A list, 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 provides the fully qualified name of a
name server. The data field for an A record specifies an Internet address of the name
server.
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. Because the network number
127.0.0 is not assigned to any site but is used by all hosts running
Berkeley networking, you must configure each name server as authoritative
for the network 127.0.0. The file /etc/named.data/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 the /etc/named.data/db.127.0.0 file. The following is an example db.127.0.0 file: ;name class type data $TTL 86400 @ IN SOA rabbit.div.inc.com root.moon.div.inc.com ( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Refresh every hour 604800 ; Expires after a week 86400 ) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com 1 IN PTR localhost |
The following explains the fields in the db.127.0.0 file: - name
This field specifies the name of the subdomain.
In the SOA record, the at sign (@) represents the domain name when the domain name
and the origin are the same. In the expanded notation, @ represents 0.0.127.in-addr.arpa. Similarly,
for the PTR record, 1 represents 1.0.0.127.in-addr.arpa. in the expanded notation. - class
The optional class field specifies the protocol group. IN, for Internet addresses, is the most common class. - type
The start of authority (SOA) 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, that is, 1.0.0.127.in-addr.arpa. (The current origin 0.0.127.in-addr.arpa is appended to the 1 in the name field because it does not end with a dot.) - data
For an SOA record, 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
Indicates the version number of this file, incremented
whenever you change the data. - Refresh
Indicates (in seconds) how often a slave name server
must update its data from a master server. - Retry
Indicates (in seconds) how often a slave server
must retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the slave name server
can use the data before it expires for lack of a refresh. - Minimum ttl
Indicates (in seconds) the minimum number of seconds
the name server is allowed to cache data. After the ttl (time to live) value expires, the name server
must discard the cached data and obtain new data from the authoritative
name servers.
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. - $TTL
Indicates (in seconds) the
time to live value for records that do not have the ttl value defined in the data field.
Master
Server db.domain Files |  |
A master 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 must contain an A (address) record for every host in the zone. The following is an example db.div file: ; ; db.div ; $TTL 86400 @ 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 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 UPD 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 example file db.div contains the following types of records: - SOA
Start of Authority record. The SOA record designates the start of a domain, and indicates
that this server is authoritative for the data in the domain. The at sign (@) in the data file represents the current origin. @ is used to represent the domain name when the
domain name and the origin are the same. The origin is the domain
configured in this file, according to the /etc/named.conf configuration file. The /etc/named.conf file denotes 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 specifies the name of the host this data file
was created on, an electronic mail address of the name server’s
technical contact, and the following values: - Serial
Indicates the version number of this file, incremented
whenever the data is changed. - Refresh
Indicates (in seconds) how often a slave name server
must try to update its data from a master server. - Retry
Indicates (in seconds) how often a slave server
must retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the slave name server
can use the data before it expires for lack of a refresh. - Minimum ttl
Indicates (in seconds) the minimum number of seconds
the name server is allowed to cache data. After the ttl (time to live) value expires, the name server
must discard the cached data and obtain new data from the authoritative
name servers
- NS
Name Server records. The NS records provide the names of the name servers
and the domains for which the domain has authority. The domain for
the name servers in the example db.div file is the current origin (div.inc.com), because @ was the last domain specified. - A
Address records. A records provide 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 host name. When
a name server looks up a name and finds a CNAME record, it replaces the name with the canonical
name and looks up the new name. All other resource records must
use the canonical name instead of the actual host name. - WKS
Well Known Service records. The WKS record describes the services provided by a particular
protocol on a particular interface. The protocol is any of the entries in
the /etc/protocols file. The list of services is as specified in
the host’s /etc/services file. You can specify only one WKS record per protocol per address. - MX
Mail Exchanger records. MX records specify a 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
must 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 db.div file, mail for rabbit must go to rabbit.div.inc.com first. If rabbit is down, its mail must be sent to the host indigo.div.inc.com. See HP-UX Mailing Services Administrator’s Guide for information
on Sendmail and how Sendmail uses the name server’s MX records for routing mail. - $TTL
Indicates (in seconds) the
time to live value for records that do not have the ttl value defined in the data field.
Master
Server db.net Files |  |
A master 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 must contain a PTR record for every host in the zone. A PTR record allows BIND to translate an IP address
into a 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 is created to allow this inverse mapping.
The in-addr.arpa domain is preceded by four labels corresponding
to four bytes (octets) of an Internet address. You must specify
each byte even if it is zero. For example, the address 143.22.0.3
has the domain name 3.0.22.143.in-addr.arpa. The four octets of the address are reversed. ; ; db.15.19.8 ; $TTL 86400 @ 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. |
The example file, db.15.19.8, contains the following records: - SOA
Start of Authority record. The SOA record indicates that this server is authoritative
for the data in the domain. The at sign (@) in the data file represents the current origin.
The current origin is the domain configured in this file, according
to the configuration file /etc/named.conf. The configuration file indicates 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, an electronic mailing address of the name server’s
technical contact, and the following values: - Serial
Indicates the version number of this file, incremented
whenever the data is changed. - Refresh
Indicates (in seconds) how often a slave name server
should try to update its data from a master server. - Retry
Indicates (in seconds) how often a slave server
should retry after an attempted refresh fails. - Expire
Indicates (in seconds) how long the slave name server
can use the data before it expires for lack of a refresh. - Minimum ttl
Indicates 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 specifies the names of the name servers
and the domains for which the domain has 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 db.15.19.8 associates the name rabbit.div.inc.com with the address 119.8.19.15.in-addr.arpa. (The current origin is appended to the name 119 in the first field, because it does not end with
a dot.) - $TTL
Indicates (in seconds) the
time to live value for records that do not have the ttl value defined in the data field.
Adding
a Host to the Domain Data Files |  |
You can add a host to the /etc/hosts file and run the hosts_to_named command to automatically regenerate all the data
files for the domain. You can also manually add the host to all
the domain data files. Use the following procedure to manually add a host to the
domain data files: Edit the db.domain file and add an address (A) resource record for each address of the new host,
and add CNAME, HINFO, WKS, and MX resource records as necessary. Then, increment
the serial number in the SOA resource record by 1. Edit the db.net file and add a PTR resource record for each host address. Then, increment
the serial number in the SOA resource record by 1. Add the host to the /etc/hosts file.  |  |  |  |  | CAUTION: If the host is not listed in the /etc/hosts file, and you accidently run the hosts_to_named command, the db.domain and db.net files are overwritten, and the host is lost. |  |  |  |  |
See the sections “Master
Server db.domain Files” and “Master
Server db.net Files” for
examples of the db.domain and db.net files. After modifying the domain data files, issue the
following command to restart the name server, which forces the name
server to reload its databases: /usr/sbin/sig_named restart
Deleting
a Host from the Domain Data Files |  |
You can delete the host from the /etc/hosts file and run the hosts_to_named command to regenerate all the data files for the domain.
You can also delete the host manually from all the data files. Use the following procedure to manually delete a host from
the domain data files: Edit the db.domain file and delete the A, CNAME, HINFO, WKS, and MX resource records associated with the host. Then,
decrement the serial number in the SOA resource record by 1. Edit the db.net file and delete all the PTR resource records for the host. Then, decrement
the serial number in the SOA resource record by 1. 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 |
|