| This procedure documents how to setup a Master (primary), a Slave (secondary), and a Caching-only DNS server on HP-UX 11.0/11i platforms with the latest supported BIND version 8.1.2 release for HP-UX. BIND 8.1.2 is loaded on 11.0 via a patch from http://software.hp.com and is provided on the 11i release media. For a more detailed discussion on BIND 8.1.2, please refer to the O'Reilly and Associates 3rd Edition book DNS and BIND, by Albitz and Liu. BIND 8.1.2 is available on the 11.0/11i platforms only and not on 10.20. 10.20 uses the older 4.9.7 version. It is important to be aware that the older 4.9.X versions of BIND have a different configuration file (boot file) format. There are also some terminology differences. The "boot" file is now called a "config" or "conf" file. HP Primary name servers are now called Master nameservers; Secondary name servers are now called Slaves. In most cases, DNS implementation is fairly straightforward, i.e., resource records and database files, etc. The real test comes in planning. Considerations such as whether the DNS system will be protected behind a firewall, whether or not you wish your resolvers to "peer" out on the Internet, and nslookup remote domains and addresses must be considered. Some administrators choose to turn off looking out on the internet to reduce the network traffic it creates. If you are directly attached to the Internet, you will need to register at least two nameservers with an authorized Internet Domain Name provider. A list of these providers can be found at http://www.icann.org/registrars/accredited-list.html. If you are not directly attached, i.e., sitting behind a firewall, an ISP is a good choice for DNS services and will do most of the work for you. When you have completed your planning you need to configure your DNS server. What names should you use? Some people use planets, locational references, and sometimes people use names for their network computers and printers. The decision is up to you, but do not use underscores in your hostnames (see "check-names" boot file options), and make the names easy to remember.. Here are the steps to creating a Master (Primary) DNS server for your network: -
Populate /etc/hosts with all of the hosts that you want to administer, separated by network segment and domains, and keep everything in an orderly fashion so that a tool such as hosts_to_named can safely and efficiently administer database files for you as in the following example: /etc/hosts 15.17.186.159 wtec712-rtr 127.0.0.1 localhost loopback # 812 Bogus Domain BASEBALL.HP.COM #NL-EAST DIVISION 10.1.1.1 atlantabraves atlantabraves.baseball.hp.com 10.1.1.2 newyork newyorkmets.baseball.hp.com # NL - CENTRAL DIVISION 10.1.2.1 houstonastros houstonastros.baseball.hp.com 10.1.2.2 chicagocubs chicagocubs.baseball.hp.com 10.1.2.3 stlouiscardinals stlouscardinals.baseball.hp.com -
Create a param file with the parameters for your domain as shown in the following example for /tmp/parm: /tmp/param -d baseball.hp.com <--------- Your domain. -n 10.1.1 <--------- Your subnet(s). -n 10.1.2 -n 10.1.3 -n 15.17.186 -H /etc/hosts.dnstest <--------- hosts file you will use. -r <--------- If this nameserver is a root NS. Our examples below are NOT for root NS. -
Run hosts_to_named with your newly created param file from the directory in which you want to place the database. Note that the param file is not necessary, but, it is a good idea; the options can be run from the command line instead of including a file. Another common error with hosts_to_named is not running it in a "clean" directory. If you need to preserve results before you run it, mkdir /etc/named.data.old; mv /etc/ named.data/* /etc/named.data.old to preserve the prior configuration. # cd /etc/named.data # hosts_to_named -f /tmp/param Translating /tmp/hosts.dns to lower case ... Collecting network data ... 10.1.1 10.1.2 10.1.3 15.17.186 Creating list of multi-homed hosts ... Creating "A" data (name to address mapping) for net 10.1.1 ... Creating "PTR" data (address to name mapping) for net 10.1.1 ... Creating "A" data (name to address mapping) for net 10.1.2 ... Creating "PTR" data (address to name mapping) for net 10.1.2 ... Creating "A" data (name to address mapping) for net 10.1.3 ... Creating "PTR" data (address to name mapping) for net 10.1.3 ... Creating "A" data (name to address mapping) for net 15.17.186 ... Creating "PTR" data (address to name mapping) for net 15.17.168 ... Creating "MX" (mail exchanger) data ... Building default named.boot file … Building default db.cache file ... WARNING: db.cache must be filled in withthe name(s) and address(es) of the rootserver(s) Building default boot.cacheonly for caching only servers ... done -
hosts_to_named will produce both a BIND 4.X named.boot file and a BIND 8.X named.conf file. Match the db files created in /etc/named.data with those found in /etc/named.data/named.conf. Here is an example for a non-root name server: // 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 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 an unprivileged * 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 "baseball.hp.com" { type master; file "db.baseball"; }; zone "1.1.10.IN-ADDR.ARPA" { type master; file "db.10.1.1"; }; zone "2.1.10.IN-ADDR.ARPA" { type master; file "db.10.1.2"; }; zone "3.1.10.IN-ADDR.ARPA" { type master; file "db.10.1.3"; }; zone "186.17.15.IN-ADDR.ARPA" { type master; file "db.15.17.186"; }; zone "." { type hint; file "db.cache"; }; (wtec712-rtr)named.data- ls boot.cacheonly db.10.1.2 db.15.17.186 named.boot conf.cacheonly db.10.1.3 db.baseball named.conf db.10.1.1 db.127.0.0 db.cache params-file As you can see, hosts_to_named created reverse lookup (IP addresses to names) db files with one parent domain, baseball.hp.com. Each of the nodes in our network will have the fully-qualified name shortname.baseball.hp.com. -
Since many installations still use underscores in hostnames, we highly recommend you allow for this by modifying the check-names options lists in the named.conf file that hosts_to_named generates. For example, you may want to change these lines: options { check-names response fail // do not change this check-names slave warn . . . to: options { check-names response ignore //change "fail" to "ignore" check-names slave ignore //change "warn" to "ignore" check-names master ignore //add this whole new line . . . -
Fill in db.cache with the addresses of the root name servers. If you are directly connected to the Internet and will be querying the root nameservers at the NIC, obtain an updated list from the site ftp://internic.net/domain/named.cache. Next, copy the file to db.cache after you have downloaded. If you are not directly connected to the Internet and have to go through a firewall to query the root name servers, make the firewall your root name server and point your db.cache entry at the firewall in the same fashion that you would specify the root name servers. It is very important to configure db.cache correctly or services such as mail and name resolution will be affected. Here is an example of this: ; FILL IN THE NAMES AND ADDRESSES OF THE ROOT SERVERS ; ; . 99999999 IN NS root.server. ; root.server. 99999999 IN A ??.??.??.?? ; . 99999999 IN NS firewall.baseball.hp.com. firewall.baseball.hp.com. 99999999 IN A 15.17.186.99 In this case, firewall.baseball.hp.com. is my firewall and since my name server cannot directly query the root nameservers, db.cache is directed to my firewall. -
If you are going to have a Master (primary) name server which will not talk to the internet in any way, shape, or form, then you need to setup your name server as a root name server by doing a couple of things. Either use the -r option in your params file to hosts_to_named or make the following changes: In your named.conf file, change: zone "." { type hint; file "db.cache"; to: zone "." { type master; file "db.root"; The root name server database file db.root would contain: . IN SOA m3107ced.baseball.hp.com. root.m3107ced.base ball.hp.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 m3107ced.baseball.hp.com. m3107ced.baseball.hp.com. IN A 15.50.73.92 What we have done is set up an internal root name server, db.root, with one record, m3107ced.baseball.hp.com. -
The next consideration is where to send queries for domains that you are not authoritative for. If your domain is baseball.hp.com and someone asks for jughead.ibm.com, what happens to the request? Well, if you've configured a root nameserver with no forwarder statements, the answer is nothing. The query will fail with host not found. This might be a good thing if you do not want your internal systems querying internet domains. Security and network congestion are usually the reason. What if you want to resolve Internet names and addresses, however? Easy, configure a forwarders statement in your /etc/named.conf to point to the firewall or whichever system is talking directly to the root name servers as shown in the following example: options { check-names response ignore ; // change fail to ignore check-names slave ignore // change warn to ignore check-names master ignore // add this line forwards 15.253.24.10 15.253.32.10 15.253.24.10 15.253.32.10 directory "/etc/named.data"; // running directory for named /* * If there is a firewall between you and 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 an unprivileged * port by default. */ // query-source address * port 53; }; What's happening here is that queries for domains that we are not authoritative for, basically anything outside baseball.hp.com, we are sending to the forwarders to let them handle it. As you can see, there are two forwarders, each listed twice. The reason for this is that forwarders tend to be quite busy and by specifying two of them, you prevent the query from timing out. Be sure to copy /etc/named.data/named.conf to /etc/named.conf. All versions of BIND will look for the boot file in /etc/ by default, so don't forget to copy it to /etc when you are ready. -
Configure /etc/resolv.conf and /etc/nsswitch.conf on your name server and all clients that will be pointed at the name server: /etc/resolv.conf domain baseball.hp.com search baseball.hp.com atl.hp.com hp.com rose.hp.com cup.hp.com external.hp.com nameserver 15.50.73.92 # authoritative name server 4 atl.hp.com nameserver 15.51.240.8 # non-authoritate cache only servers /etc/resolv.conf is pretty simple: the domain statement identifies which domain the system is part of; the search statements are used to simplify typing when ther is more than one domain. When you issue a query for say, jughead, it will search for jughead first in baseball.hp.com, then atl.hp.com, rose.hp.com, and finally, cup.hp.com. /etc/nsswitch.conf modifies the switch order you will use to look up hosts and IP addresses. There are four possible sources for this information: 1) /etc/hosts, 2) nis, 3) nisplus, 4) and dns By default, the hard coded order is dns nis files. To modify the switch order, you need to copy in a fresh /etc/nsswitch.conf file from / usr/newconfig/etc/nsswitch.hp_defaults and modify the hosts entry: # /etc/nsswitch.hp_defaults: # # An example file that could be copied over to /etc/nss witch.conf; it # uses NIS (YP) in conjunction with files. # passwd: compat group: compat hosts: files [NOTFOUND=return] dns networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis [NOTFOUND=return] files automount: files nis aliases: files nis services: nis [NOTFOUND=return] files As you can see, the hosts line has been modified so that we consult the /etc/ hosts file first then continue on to dns if the query is unsuccessful. There are many ways to modify the switch order and many ways to mess things up. Use discretion when changing the switch order and consult the man pages on switch for more information. -
Start up the DNS name server process as follows: # /usr/sbin/named. # ps -eaf|grep named root 80741008:42:08 ? 0:00 /usr/sbin/named <--- check to make sure it is running.. root 8077 8072 2 08:42:13 ttyp7 0:00 grep named After the name server is started, you use can sig_named to perform various functions. After you modify any of the db files or /etc/named.boot, you need to tell named to refresh its databases. You can accomplish this using either of the two following commands: # sig_named restart # kill -HUP `/var/run/named.pid` This will reload the databases, which you can verify by viewing the end of file /var/adm/syslog/syslog.log as shown below: Oct 12 08:49:13 m3107ced named[8074]: primary zone "0.0.127.IN-AD DR.ARPA" loaded (serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "baseball.hp.com" loaded (serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "1.1.10.IN-AD- DR.ARPA" loaded(serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "2.1.10.IN-AD- DR.ARPA" loaded(serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "3.1.10.IN-AD- DR.ARPA" loaded(serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "1.168.192.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "2.168.192.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 08:49:13 m3107ced named[8074]: primary zone "3.168.192.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 08:49:13 m3107ced named[8074]: Ready to answer queries. As you can see, named loaded each of our databases, or zones, and is ready to answer queries. -
Test queries both by name and IP address. # nslookup atlantabraves Using /etc/hosts on: wtec712-rtr looking up FILES Trying DNS Name: atlantabraves.baseball.hp.com Address: 10.1.1.1 # nslookup 10.1.1.1 Using /etc/hosts on: wtec712-rtr looking up FILES Trying DNS Trying DNS Name: atlantabraves.baseball.hp.com Address: 10.1.1.1 Looking up atlantabraves by name and IP address worked and generally we are done. We always check /var/adm/syslog/syslog.log for messages from named. named logs a lot of seemingly unimportant chatter, but it always deserves at least a short look.
A Word on Slave (Secondary) Name Servers Once you have created a Master (primary) DNS server, you have completed all the hard work. Creating Slaves and cache-only servers is simple. Let's walk through this process step-by-step: -
Use ftp to copy the named.conf file and db.cache from the Master (primary). -
Edit the named.conf file as follows: -
Change each instance of "master" to "slave", except for the loopback domain db.127.0.0 and the cache entry. -
Add a "masters" entry for each zone with the IP address of the Master DNS server. We'll use our example from above: # cat /etc/named.conf // 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 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 an unprivileged * 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 "baseball.hp.com" { type slave; file "db.baseball"; masters ( 15.17.186.159); }; zone "1.1.10.IN-ADDR.ARPA" { type slave; file "db.10.1.1"; masters ( 15.17.186.159); }; zone "2.1.10.IN-ADDR.ARPA" { type slave; file "db.10.1.2"; masters ( 15.17.186.159); }; zone "3.1.10.IN-ADDR.ARPA" { type slave; file "db.10.1.3"; masters ( 15.17.186.159); }; zone "186.17.15.IN-ADDR.ARPA" { type slave; file "db.15.17.186"; masters ( 15.17.186.159); }; zone "." { type hint; file "db.cache"; };
-
Now, all you need to do, once your named.boot has been copied to /etc/ named.boot and your /etc/named.data directory has been created, is kick off a zone transfer. To kick off a zone transfer, all you need to do is kill named with # sig_named restart or # kill -HUP `/var/run/named.pid` to start the transfer. Take a look at /etc/named.data and you should see all the database files there now. Also, check /var/adm/syslog/sylog.log to make sure the zones were loaded properly as shown in the following example: Oct 12 09:21:34 stimpy named[1893]: secondary zone "1.1.10.IN-AD DR.ARPA" loaded (serial 1) Oct 12 09:21:35 stimpy named[1893]: secondary zone "baseball.hp.com" loaded (serial 1) Oct 12 09:21:35 stimpy named[1893]: secondary zone "2.1.10.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 09:21:35 stimpy named[1893]: secondary zone "1.168.192.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 09:21:35 stimpy named[1893]: secondary zone "3.1.10.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 09:21:36 stimpy named[1893]: secondary zone "2.168.192.IN-AD- DR.ARPA" loaded (serial 1) Oct 12 09:21:36 stimpy named[1893]: secondary zone "3.168.192.IN-AD- DR.ARPA" loaded (serial 1) Notice the serial number entries. They should match on the Master (primary) and Slaves (secondaries).
A Word on Cache-Only Name Servers Why in the world would you want a cache-only name server? In a word, performance. If you want to maintain a local cache but do not want to manage database files, this is the way to go. It will act as any other name server, responding to queries in the same fashion, except queries that are built in the cache will be non-authoritative. Any query that comes back with a non-authoritative reply is a query received from cache. Is that a bad thing? No, but be aware that the data may have changed on the Master (primary) and the cache replies may be outdated. The Time To Live (TTL) flag for each query is a way to manipulate the time, in seconds, that a name server may cache the answer to a query, versus having to contact an authoritative name server. The default TTL for records is usually 86400 seconds, or 24 hours. You may want to play with this value, depending on how frequently or infrequently the records are updated. A good rule of thumb is to have at least one name server per subnet, and cache-only name servers are an excellent choice. To configure a cache-only name server, copy down the conf.cacheonly file and db.cache from the Master (primary) nameserver . // generated by named-bootconf.pl options { check-names response fail; // do not change this check-names slave warn; directory "/tmp/testhack"; // running directory for named /* * If there is a firewall between you and 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 an unprivileged * 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 "." { type hint; file "db.cache"; }; Please don't forget to fill in db.cache with the name server(s) that you will be caching data for. A Final Word on Name Server Setup This section in no way offers a comprehensive discussion on setting up DNS. It is only intended to act as a cookbook after all your planning has been completed. Please refer to the book HP Installing and Administering Internet Services at http://docs.hp.com. DNS is pretty straightforward, but any syntax errors or problems with /etc/named.boot can have dramatic consequences. The syslog can be your best friend when zones are not transferring or there are problems with the data. |