Traditional DNS Howto - Page 2
How Do I Answer These Queries Now?
That's where BIND comes into play. The people who maintain the BIND code make sure it meets the specifications of the Internet Engineering Task Force and will run on your server. All you have to do is learn how it does what it does.
Named lives on a domain name server and answers queries from resolvers. The application reads its data from a configuration file called named.conf. named.conf gets its information from something we call zone files. Several zone files exist, but one zone file in particular keeps a database of records that supply named with most of its answers.
In Figure 2, named had received a query. It looks to its configuration file named.conf, which looks to the primary zone file and hands off the information requested to the resolver from the outside.
Figure 2 - Answering a query
Some people refer to configuration files as rule files. BIND's configuration files seem like rule files to me. The rules of Domain Name Services require tight compliance. Making and resolving queries follow strict protocols on the Internet as does the interprocess communication within BIND.
Let's refer to Figure 2 again and look at the process. You should have BIND installed and running on your server. If not, we will address installation and configuration in one of the next sections.
The named process listens on port 53 of a Linux system. When it receives a query for an address, it looks to the first configuration file about which it knows: named.conf.
Figure 3 - named.conf
The following table depicts a simple named.conf file. If you have seen a file like this and didn't understand it, then let's break it down into its components. Once we do that, we can take the mystery out of it.
This file refers to the four other configuration files. The third line down lists the directory containing them all, /etc/bind where they exist.
The options statement defines the default directory for named and the location of the process ID (pid) file. named.pid represents the daemon itself. If you followed any of the Perfect Setup Tutorials, we put it in a chrooted environment.
The zone statement identifies the location of the hints, localhost, zone and reverse zone files.
This file contains the names and addresses of the root servers on the Internet. These know where the authoritative servers for your domain exist - the first one being the Top Level Domain (com, net, org, etc.) and next being the authoritative server for your domain.
Name servers are the masters of their own loopback domain (127.0.0.1). The point of creating local zone files for each aspect of your of localhost is to reduce traffic and allow the same software to work on your system as it does on the network.
This file, also called the domain database, defines most of the information needed to resolve queries about the domain you administer. It maps names to IP addresses and provides information about the services offered by your Internet computer including your web and ftp server, email, telnet, name servers, etc.
The zone file uses several record types including the SOA or start of authority; NS or name server; A or host name to address map; PTR or pointer which maps addresses to names; MX or mail exchanger which identifies the mail servers in the domain; and CNAME or canonical name which defines an alias for a host name.
Don't try to memorize or understand what these record types mean at this point. Just realize that they exist and you will have ample opportunity to use them.
Another way to talk about zone files is to define them something that links all the IP addresses in your domain to their corresponding server. The reverse zone file maps IP addresses to host files. It's a mirror image of the database file above. You can recognize a reverse zone file because it has the extension of in-addr.arpa.
Figure 4 - Zone files