| Previous | Table of Contents | Next |
The named.rev file is very similar to the named.hosts file, except that it essentially works in reverse—it maps addresses to host names. Listing 25.2 shows a sample named.rev file for tristar.com.
Listing 25.2 An Example named.rev File
; named.rev file for tristar.com ; @ IN SOA ns.tristar.com. dave.tristar.com. ( 6 ; serial number 86400 ;refresh 24 hrs 300 ; retry 5 minutes 2592000 ; expire 30 days 86400 ; minimum 24 hrs ) IN NS ns.tristar.com. ; ; reverse map your IP addresses ; 1 IN PTR ns.tristar.com. 2 IN PTR mailhost.tristar.com. 3 IN PTR opus.tristar.com. 4 IN PTR skippy.tristar.com.
In this example, you have the same SOA record that you saw in the named.hosts file. This just sets up the authority information for the domain. In this case, @, the value of the origin, is set to 197.198.199.in-addr.arpa from the primary line in the named.boot file. Recall that the in-addr.arpa domain refers to reverse mapping of addresses to names.
NOTE: The addresses listed as part of your in-addr.arpa line is your network address backward. Your example network for this chapter has the address 199.198.197.0. When you list it in the reverse mapping data files, you list it as
- 197.198.199.in-addr.arpa
You have the NS record that lists the name server for your domain. Following that are the records that make up the reverse address resolution records. These are PTR records and give the host number (the part of the IP address not listed in the in-addr.arpa value) and the canonical host name that matches it. You must use the canonical host name here instead of a relative host name. For example, the line
2 IN PTR mailhost.tristar.com.
tells named to map the host address 199.198.197.2 to the host name mailhost.tristar.com.
As stated earlier in this chapter, the caching operation of named is very important. Fortunately, the named.ca file that sets up caching is also usually the simplest of the named configuration files. It just lists the root name servers for the various domains with their IP addresses. It contains a couple of special field indicators that tell named that these are root servers.
You can probably just copy the format of the sample named.ca file in Listing 25.3. To get a complete current list of the root name servers, use the nslookup utility.
Listing 25.3 An Example named.ca File
; named.ca file ; . 99999999 IN NS NS.NIC.DDN.MIL. 99999999 IN NS NS.NASA.GOV. 99999999 IN NS KAVA.NISC.SRI.COM. 99999999 IN NS TERP.UMD.EDU. 99999999 IN NS C.NYSER.NET. 99999999 IN NS NS.INTERNIC.NET. ; NS.NIC.DDN.MIL. 99999999 IN A 192.112.36.4 NS.NASA.GOV. 99999999 IN A 128.102.16.10 KAVA.NISC.SRI.COM. 99999999 IN A 192.33.33.24 TERP.UMD.EDU. 99999999 IN A 128.8.10.90 C.NYSER.NET. 99999999 IN A 192.33.4.12 NS.INTERNIC.NET. 99999999 IN A 198.41.0.4
As you can see, the named.ca file simply maps NS name server records to the appropriate addresses for them.
DNS is a very complex system. You can do many things wrong that will cause your system to not behave properly. Many of the problems that occur with a DNS setup will appear to be identical but come from different causes. However, most of the problems result from syntax errors in your configuration files.
Make sure that you specify the host names correctly in your DNS configuration files. If it’s an absolute host name, be sure to end it with a dot.
Be especially careful with the names used in SOA and CNAME records. If you make errors here, these resource records can redirect host name queries to computers that don’t exist.
Be sure to increment the serial number in your configuration files when making changes. If you forget, DNS will not reread the file.
Be sure to enter the correct IP address for A records, and check to see that it matches your /etc/hosts file (if you have one). Also, make sure that the DNS name and IP address match the corresponding reverse resolution information in named.rev.
Your best tool for figuring out errors is the nslookup command. Use nslookup to test your DNS server thoroughly. Do regular and reverse resolution for every address in your DNS database to make sure that all the names and addresses are correct.
NOTE: An interesting project is Paul Vixie’s (he wrote BIND) S/WAN project, which provides opportunistic encryption at the Ethernet packet level. For more information, go to http://www.cygnus.com/~gnu/swan.html.
This chapter shows the various components of the DNS system and explores the various configuration files necessary to get a DNS name server running on your Linux system. Because the syntax for the resource records is fairly arcane, you need to pay close attention to your configuration files as you write them.
You can find more information about networking in the following chapters:
| Previous | Table of Contents | Next |