The following code does the same thing as that shown in the named.boot file we examined previously. If you upgrade your version of BIND, you will need to either write a new named.conf file, or use a conversion script to convert your existing named.boot file. Newer versions of BIND contain the scripts necessary for conversion.

#directory /var/named
options {
        directory "/var/named";
};

#cache . named.ca
zone "." {
        type hint;
        file "named.ca";
};

#primary 0.0.127.in-addr.arpa named.local
zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
};

#primary corporation.com corp.zone
zone "corporation.com" {
        type master;
        file "corp.zone";
};

#primary 34.168.92.in-addr.arpa rev.zone
zone "34.168.92.in-addr.arpa" {
        type master;
        file "rev.zone"; 
};

Figure 4-6 depicts the process used to answer a query. Let us break it down.
In the upper-left corner of the figure is a drawing of a server tower (in our example this server is called server1.centralsoft.org; it performs the same function as ns1. google.com). Assume the server is running Linux and BIND.
A server at a higher level directs resolvers to the system (in the case of server1.centralsoft.org, a TLD nameserver for the .org domain sends the requests).

The named daemon listens on UDP port 53 for anyone making requests for names in the domain. When named receives a request, it consults its configuration file, /etc/ named.conf. If the server has information on the domain in question, it looks in the appropriate zone file. If the zone file has the information requested, the server hands it off to the system querying for the information.
Some people refer to configuration files as rule files. This makes some sense because correct DNS operation requires tight compliance with its rules and protocols. However, the zone files actually function as part of the DNS directory. Their primary function is to provide information, not to enforce rules.