 |
» |
|
|
|
This section explains 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.conffile 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.cachefile. 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 shows the structure of a master server and a slave server. In the Figure 2-1, 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, 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 |
|
Printable version
