Home Index Search Links About LF
[LinuxFocus Image]
[Navegation Bar]
News    Archives    Map 
This document is available in: English  Castellano  Deutsch  Francais  Nederlands  Russian  Turkce  


by Andreas J Gundacker
<AJGundi(at)aol.com>



Translated to English by:
Dallas L. Gale <no(at)email>

Content:

 

Introduction to DNS

[Illustration]

Abstract:

This article is written for all those that are interested in the subject of world-wide computer networks like the Internet and the World Wide Web (WWW). It is for those who want to know more about their functionality. If you have ask yourself what happens behind your navigator after you enter the address of a server, this article will help you understand in a simple manner the processes that bring it about.

This article first appeared in Linux Magazine.
Reprinted with the author's permission


_________________ _________________ _________________

 

Introduction

The article is divided into five sections:

The first briefly explains what the Internet means and how it came about.
The second will help you understand some technical expressions.
The third is dedicated to the most important protocols of the Internet: TCP and IP.
The fourth will help you understand the function of DNS.
The fifth section is the practical part, explaining the creation of the Domain Name Service (DNS) for a local network with a gateway, using the LINUX operating system, how it was implemented on the author's network. In this manner the document serves as a basic introduction for novices and offers a practical reference for the advanced.


 

The ARPANET, the origin of the World Wide Web

The "Internet" means all of the interconnected computer networks which were a result of the ARPANET. The ARPANET was created in the year 1969 from an American project of the DARPA (Defense Advanced Research Project Agency). When the ARPANET moved beyond it's experimental state, the basic protocols of TCP/IP were developed, which were nominated as the military standard and all of the institutions that made up the ARPANET had to change to the new protocols. To simplify this change, the DARPA hired the company Bolt, Beranek &Newman (BBN) for the integration of TCP/IP in the Berkeley-UNIX system (BSD). It's because of this TCP/IP and the UNIX operating system came together.

In the year 1983, the ARPANET was split. The result was the MILNET, as part of the Defense Data Network (DDN), and another smaller ARPANET. The combination consisting of the MILNET and the ARPANET controlled the INTERNET. The ARPANET disappeared in the year 1990 opening the way for the Internet, which includes a large number of networks around the world.

 

 

Understanding a few technical expressions

Imagine that your are sitting in front of a computer that is part of a local area network (LAN) of the mathematics department of your university (Figure 1).

The mathematics LAN is connected by the backbone (principal node) to the physics department which is located in another building. You want to send data to a friend that is working on the Physics department. It's important to know that your computer and your friend's have unique names on the university network (the same as all other computers on the Internet). For example, yours is named Einstein and your friend's is named Edison. For the two physically independent networks to communicate, they need a gateway. A gateway is a computer that is capable of uniting physically independent networks. In this case we need two gateways - one for the local mathematics network and one for the physics network. From now on we'll call the mathematics gateway "math" and the physics gateway "fisa".


Figure 1: The path of a datagram from Einstein to Edison

Because Einstein's software (rlogin, telnet, ftp etc.) can't send data (data packets) directly to Edison, which is found on a physically independent network, you have to rely on the gateway to transport the packets to the corresponding destination. In other words, the gateway "math" sends the packets to the gateway "fisa", that has the same function the the physics network. The transfer goes through the university backbone and "fisa" finally delivers the data to Edison. This scheme of data transmission to a remote host (computer on the network) is call Routing and the data or packets of data are called datagrams.

 

TCP/IP

 

IP

Datagrams, as the smallest unit of the data transmission, are exchanged by a protocol - the Internet Protocol (IP), that is completely independent from the hardware. In this manner we come to the principal advantage of the IP protocol, uniting physically separated networks in an apparently homogeneous network.

The principal functions of IP:

But on the other hand, IP does not use transmission control information (handshake), in other words, IP transports packets from one place to another without proper control over if all the packets are received in the correct order. We'll handle this problem later.

Now we have an idea about transmission software (Routing). Remember that our computer is named Einstein. Network computers have names because they are easier to remember than a sequence of numbers.

IP has an address scheme that is independent from the hardware. This assigns a unique 32 bit number to a host; the IP-address (IP). The IP-address is represented by four decimal numbers (octets) separated by periods. Einstein, for example, could have the hardware address 0x95c0c02, which would appear in the form 149.176.12.7.

It needs to be understood that have three distinct addresses:

The Ethernet card address occupies a port on the operating system; it is usually eth0-n under Linux. Serial ports, for example, have the name cua0-n or ttyS0-n. To be exact, it shouldn't be said that your computer or the host has the name Einstein, but that refers to the corresponding hardware interface.

You know now that the Internet Protocol (IP) transmits data between computers in the form of datagrams. Each datagram is transmitted to the address on the Internet or other local network, that is indicated in the header of the datagram. The destination address is a standard 32 Bit address (IP) and contains sufficient information to unequivocally identify a computer on the network.

An IP-address is made up of two parts:

The number of the host addresses depends on the size of the network. To fulfill these different requirements, different network classes were created that define separations of different IP addresses.
 

Class A:   Class A includes networks from 1.0.0.0 to 127.0.0.0. The number of this type of network is found in the first octet. There are 24 bits left to define the hosts, which is enough for approximately 1.6 million computers.
Class B:   Class B includes networks from 128.0.0.0 to 191.255.0.0. The number of this type of network is found in the first two octets. This allows 16,320 networks with 65,024 computers on each one.
Class C:   Class C includes the networks from 192.0.0.0 to 223.255.255.0 . The number of this type of network is found in the first three octets. This allows 2 million networks with around 254 hosts.
Class D, E and F:   Addresses, that are in the range of 224.0.0.0 to 225.0.0.0 are experimental, or are reserved for future use and don't define any network.

Returning to our example, you can see that Einstein with the IP-address of 149.176.12.7 forms part of a class B network: 149.176.0.0 and the host computer 12.7. It is important to know that the host address cannot have a 0 or a 255, since these are reserve for special purposes. The host address, consisting only of zeros, identifies the network (149.176.0.0). If the host's numbers are 255 (149.176.255.255) this indicates the broadcast (radio) address, since data that is sent to this address is received by all of the computers on the 149.176.0.0 network.

At the same time, there are two reserved network addresses: 0.0.0.0, which is named the default route and 127.0.0.0 which is the loopback address. The default route has to do with the manner that IP routes the datagrams (note: masquerading).

The most important for now is the 127.0.0.0 network, which is reserved for IP traffic that occurs on your own computer. The IP-address 127.0.0.1 usually refers to the interface on your computer that is called the loopback interface, which functions like a closed circuit. Each packet sent there is returned immediately. In this manner, the loopback serves to test network software without being obligated to use the "real" network.
"Ping localhost" or "ping 127.0.0.1" is a common test under Linux to see if TCP/IP is configured correctly.

The IP-address that you will have, in the end, is decided by a central institution called NIC (Network Information Center). The best solution is to ask your Internet Service provider to reserve the IP-address. If you are sure that your network will never be connected to the Internet, you can choose any IP-address. But to be sure that no data packets escape to the Internet, it important to use an IP-address that is only valid in a private network and cannot be used on Internet systems.

These addresses are:

Never the less, it is possible to install a gateway to the Internet. In other words, the external address is known on the Internet; but the computers on your network normally can't access them, because their IP-addresses aren't transmitted on the Internet. The hosts on your network, on the other hand, will have access to the WWW (World Wide Web).

 

 

TCP (Transmission Control Protocol)

It was mentioned earlier, the Internet Protocol doesn't provide transmission control; this is what TCP does. TCP is a byte stream, reliable, and connection oriented protocol.

Because of this, TCP takes care of the correct order of the data.

 

 

The Domain Name System (DNS)

 

A summary of the system

The Domain Name System (DNS) is basically a distributed database of computers that form part of a network. This makes local control of all of the database segments easy, which allows each segment to be available through the network in a client-server scheme.

The Name Server is a program that forms the server part of the client-server mechanism of DNS. The Name Servers have information about a given segment of the database, which it makes available for clients, named Resolvers. Many times the Resolvers only consist of library routines, that create queries and send them to the Name Server through the network.

The DNS database structure is shown in figure 2. The whole database looks like an inverted tree with the root on the top. The name of the root is the tag NULL, but this is written with a single period ("."). Every node on the tree represents both a partition of the whole database, as well as a DNS domain. From now on, each domain can be divided in partitions that are called subdomains that are derived as children of the parent nodes.


Figure 2: The DNS database

Each domain is marked in a way that it has a tag that identifies it relative to their domain parent. The domain also possesses a domain name, that identifies their position in the database, just as the root directory specifies its place in a computer file system.

In DNS, the complete domain name is a sequence of tags, beginning with the domain until the root, separating the tags with periods "." (for example: einstein.mathematics.ac.edu). Allowing each domain to be administrated by a different organization. Each organization can divide their domain in various subdomains, whose administration can be carried out by other organizations

The Network Information Center, for example, administers the domain "edu" (educational) but passes the authority over the sub domain "ac.edu" (academic) to the university, which authorizes the mathematics department to administrate the following domain: "mathematics.ac.edu" (Figure 3).


Figure 3: Maintaining Subdomains

Finally, is should be mentioned that a domain can have subdomains as well as hosts. Each host on a network has a Domain Name that contains information about the host, just as the IP-address or how the Routing of mail works, etc. A host also can have one or more Domain name aliases that are simply an indicator of a domain name of the canonical domain name. An example: if your wife is named Maria Elizabeth, some times you will call here Maria and other times Elizabeth. Even though you use different names, it refers to the same person.

The domain organizations are free to chose the names in their domain. It does not matter which name is used, it is certain that it won't cause a conflict with another name, because it has a unique Domain name attached to the end. In this manner, two hosts named einstein can exist in the university, for example, packets from einstein.physics.ac.edu will always find their way to einstein.mathematics.ac.edu, because they address each other from different parent domains.

 

 

Why is DNS necessary?

To resolve domain names and IP-addresses and to be able to locate host on remote networks. As was mentioned earlier, it is easier to remember names than numbers. Especially when you talk about a quantity of addresses as immense as the Internet.

Computers, on the other hand, work perfectly with numbers like IP-addresses. What happens when you enter the Internet putting an address like, for example, http://www.altavista.com, is that your navigator sends a request to your provider's Domain Server and this tries to resolve the domain name with the corresponding IP-address. In the case that your provider isn't authorized for this zone, is transmits the request to the authorized domain until it arrives at the indicated domain. (We detail a search with the address "einstein.mathematics.ac.edu" in Figure 4).


Figure 4: Resolving einstein.mathematics.ac.edu on the Internet

This means that each domain server has the complete information of the zone that it is authorized and also has basic information about other zones. When a request is sent to a zone that is outside of the authorized zone, your server at least knows where to look. This can mean that the address request has to go through various domain servers until you contact the the requested destination.

Even if you knew the destination IP-address, it is essential to consult other domain servers if your computer is not found in the same zone. In this manner it is easy to imagine why the Domain Name System couldn't exist on one centralized database only. First it would take too much time to find a server among millions of others and second there would be a fairly long line in the case of thousands of simultaneous requests from all over the world. Additionally it wouldn't make sense to go to a distant server to communicate with a host in the same zone.

Up to now we've talked of the mapping of names to addresses. But, what happens if you have the IP-address and you want to know the name of this domain? To solve this problem the "in-addr.arpa" (Figure 5) domain was created.

This domain is called reverse domain and the resolution of IP-addresses to domain names is named reverse map (reverse mapping or reverse lookup). The reverse domain name is created by putting the numbers of the IP-address in reverse order and adding in-addr.arpa to the end.

For example: Remember that the IP-address of Einstein from the mathematics department is "149.176.12.7" with the domain name of "einstein.mathematics.ac.edu".

The domain "mathematics.ac.edu" would then have the reverse domain name of: "12.176.149.in-addr.arpa" and the computer einstein.mathematics.ac.edu correspondingly is made with "7.12.176.149.in-addr.arpa".

Figure 5: The reverse map

 

 

Installing a Domain Name Server

Here I describe how to install a DNS server for a local network (LAN) with a gateway in the LINUX Operating system using BIND (Berkeley Internet Name Daemon).

The following is based on the assumption that you know how to install and configure network cards under LINUX. The commands "ifconfig" and "ping localhost" can test a correct configuration for each computer. Now we will dedicate ourselves to connecting your computers using DNS configuring BIND. You have to have installed the BIND package that has named (pronounce name-d = the server daemon) on the computer that will work as the domain server. In the chapter we will install a fictitious domain. This way you only have to replace the IP-addresses, the names of the computers and a couple of additions details of your network.


Figure 6
: The Alcomato Distributions network

Our fictitious domain is for a beverage wholesaler. The company "Alcomato Distributions", specializing in beer and liquor, was given the domain name "alcomat.com" after having contacted NIS. Alcomato Distributions has two Ethernets with the network numbers 192.249.249 and 192.253.253 (Figure 6).

Part of the host table (usually the /etc/hosts file) shows the following:
 

/etc/hosts 

127.0.0.1       localhost

# These are the computers for the liquor

192.249.249.2   whisky.alcomat.com              whisky

192.249.249.3   brandy.alcomat.com              brandy

192.249.249.4   vodka.alcomat.com               vodka

        .........

# These are the computers for the beer

192.253.253.2   mahou.alcomat.com               mahou

192.253.253.3   augustiner.alcomat.com          augustiner

192.253.253.4   polar.alcomat.com               polar

        ..........

# The following defines the gateway for the two Ethernets

192.249.249.1   tubo.alcomat.com tubo   tu       tub249

192.253.253.1   tubo.alcomat.com tubo   tu       tub253

 

 

Database files

The first step will be to translate the host table to equivalent DNS data. DNS consists of various files: a file changes all of the host names to IP-addresses. Other files re-change the IP-addresses to host names. The search for IP-addresses from host names is called reverse mapping and each network has their own file to reverse map.

I have called the file that changes names to addresses named.hosts. The files that change the addresses to hosts I will call named.249 and named.253 corresponding to the two networks of the fictitious company. You can choose any different name for these files. Never the less, I will call them DNS database files.

Apart from this, there exist two database files that are more or less equal for each server. These I will call named.cache and named.local.

To unite all the database files, the Name Server requires a file that begins with – using BIND, this file is usually /etc/named.boot. The database files are specific for DNS. The starting file is specific for the Name Server implementation – in our case we will use BIND.

 

 

Resource records

The majority of the components of these files are called DNS resource records. According to DNS references, the resource records have the following order:

The following records show host information on this domain:

Comments: Using comments and blank lines makes the DNS files easier to read. The comments begin with a period and coma and they end at the end of the line. Name Servers ignore comments as well as blank lines.

SOA record:
The first resource record of each database file is the SOA record (start of authority). The SOA record indicates that this Name Server is the best source of information for the hosts within this domain. Our Name Server - augustiner - is authorized for the domain "alcomat.com" because of the SOA record. An SOA record is required for named.hosts, named.249, and named 253. We will adjust the following SOA record in the "named.hosts" file.
 

SOA record

alcomat.com.   IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week

The name "alcomat.com" should be in the first column. Is it very important to put a period at the end of the names! If not, the domain "alcomat.com" is automatically added, which wouldn't mean anything. I will give you the explanation when we deal withabbreviations.

The "IN" Is put for the Internet. Other classes exist, but none is commonly used.

The first name after SOA, augustiner.alcomat.com, is the name of the Name Server for this information. The second name, juan.mahou.alcomat.com, is the mail address of the person in charge of this information (if you replace the first period "." with a @). BIND provides another type of resource record for this purpose: RP (responsible person).

The parenthesis permit the SOA record to extend over various lines. The majority of the lines between the parenthesis serve to inform secondary Name Servers, which we don't use in our fictitious network and will probably be treated in the next edition.

Similar SOA records are inserted in the files named.249 and named.253. Note that in these files we change the first name of the SOA record of alcomat.com to the appropriate name of the domain in-addr.arpa: 249.249.192.in-addr.arpa. and 253.253.192.in-addr.arpa.

NS record:
The next line that we add to each database file is the NS record (Name Server). The NS records of our domain are:
 

NS record
alcomat.com.      IN NS     augustiner.alcomat.com.
alcomat.com.      IN NS     tubo.alcomat.com.

These records indicate that two Name Servers exist for the domain "alcomat.com". The Name Servers and found on the hosts "augustiner" and "tubo". Hosts like "tubo", (our gateway) that have more than one network interface (multihomed hosts), in our case two Ethernet cards, are excellent choices for Name Servers, since they are well connected: First they are directly accessible from hosts on more then one network and in some cases they also serve as routers, and they aren't down very much since they are monitored closely.

Just the same as with the SOA records, We will add NS records to the files named.249 and named.253.

Address and Alias records:
The following step is the mapping of addresses to names. We add the following resource records to the named.hosts file.

 

A record

;
;host addresses
;

localhost.alcomat.com.   IN A      127.0.0.1
mahou.alcomat.com.       IN A      192.253.253.2
augustiner.alcomat.com.  IN A      192.253.253.3
polar.alcomat.com.       IN A      192.253.253.4

;
; multiple residency hosts
;

tubo.alcomat.com.        IN A      192.253.253.1
tubo.alcomat.com.        IN A      192.249.249.1

;
; Aliases
;

edel.alcomat.com.        IN CNAME  augustiner.alcomat.com.
pol.alcomat.com.         IN CNAME  polar.alcomat.com.
tu.alcomat.com.          IN CNAME  tubo.alcomat.com.
tub249.alcomat.com.      IN A      192.249.249.1
tub253.alcomat.com.      IN A      192.253.253.1

The first two blocks are not going to surprise you. The "A" Indicates the address and each resource record maps a name to an address. Tubo acts as a Router and has two addresses associated with its name and because of this it has two resource records.

The third block contains the alias table. For the first two aliases we will create a "CNAME" (canonical name, fully qualified host name) resource record. Never the less, we will create address records for the other two aliases.

When a Name Server looks for a name and it finds a corresponding CNAME-record, it replaces the name with the first order host name and continues looking for the new name. If for example the Name Server looks for "tu", and finds a CNAME record indicating "tubo". Then "tubo" is looked for, and the addresses 192.249.249.1 and 192.253.253.1 are returned

The last two lines solve a special problem. Let's suppose that we have a gateway, "tubo" and you want to test one of the interfaces. One very common solution is, send a "ping" to the interface to verify that it is responding. When you send a "ping tubo", the Name Server returns both directions. In our table we didn't put aliases for tub249 and tub253, because it would result in both addresses being returned the alias is looked for. To avoid it, we only use the address record "A" to identify the two interfaces. To prove that the tubo's interface 192.249.249.1 is operational, we send a "ping tub249", since this refers to only one address. It functions the same with "tub253".

Let's form a general rule for this:

When a host has more than one network interface (multihomed host), an address record "A" is created for each alias that is unique to an address.

Putting what was said aside, don't use names like tub249 or tub253 to identify users. These only serve with the purpose of system Administration and they are not of any use to the user.

 

PTR Records
Now we will create the address to name maps. The named.249 file maps addresses to host names for the network 192.249.249. The resource record for this map is the PTR (pointer) record. A record exists for each host on this network. (Remember that in DNS names for addresses are looked for). The address is placed in reverse order and in-addr.arpa is joined to it.

The following records are the PTR records for the 192.249.249 network.
 

PTR record

1.249.249.192.in-addr.arpa.     IN PTR     tubo.alcomat.com.
2.249.249.192.in-addr.arpa.     IN PTR     whisky.alcomat.com.
3.249.249.192.in-addr.arpa.     IN PTR     brandy.alcomat.com.
4.249.249.192.in-addr.arpa.     IN PTR     vodka.alcomat.com.

 
Remember that tubo has two addresses, since it has two network interfaces. Never the less only one appears, since this file only shows the direct connection to the 192.249.249 network and tubo only has one connection there with the interface 192.249.249.1. It functions the same for the named.253 file.

 

 

The complete files for our fictitious domain

The hosts table file for the alcomat.com domain

named.hosts

alcomat.com.   IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week

;
; Our Name Servers
;

alcomat.com.             IN NS     augustiner.alcomat.com.
alcomat.com.             IN NS     tubo.alcomat.com.

;
; Host addresses
;

localhost.alcomat.com.   IN A      127.0.0.1
mahou.alcomat.com.       IN A      192.253.253.2
augustiner.alcomat.com.  IN A      192.253.253.3
polar.alcomat.com.       IN A      192.253.253.4
whisky.alcomat.com.      IN A      192.249.249.2
brandy.alcomat.com.      IN A      192.249.249.3
vodka.alcomat.com.       IN A      192.249.249.4

;
; Multiple residence hosts
;

tubo.alcomat.com.        IN A      192.253.253.1
tubo.alcomat.com.        IN A      192.249.249.1

;
; Aliases
;

edel.alcomat.com.        IN CNAME  augustiner.alcomat.com.
pol.alcomat.com.         IN CNAME  polar.alcomat.com.
tu.alcomat.com.          IN CNAME  tubo.alcomat.com.
tub249.alcomat.com.      IN A      192.249.249.1
tub253.alcomat.com.      IN A      192.253.253.1

 

The named.249 and named.253 files for mapping addresses to host names

named.249

249.249.192.in-addr.arpa. IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week


;
; Name Servers
;
249.249.192.in-addr.arpa.         IN NS      augustiner.alcomat.com.
249.249.192.in-addr.arpa.         IN NS      tubo.alcomat.com.

;
; Address to name map
;
1.249.249.192.in-addr.arpa.       IN PTR     tubo.alcomat.com.
2.249.249.192.in-addr.arpa.       IN PTR     whisky.alcomat.com.
3.249.249.192.in-addr.arpa.       IN PTR     brandy.alcomat.com.
4.249.249.192.in-addr.arpa.       IN PTR     vodka.alcomat.com.

 

named.253

253.253.192.in-addr.arpa. IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week


;
; Name Servers
;
253.253.192.in-addr.arpa.         IN NS      augustiner.alcomat.com.
253.253.192.in-addr.arpa.         IN NS      tubo.alcomat.com.

;
; Address to name map
;
1.253.253.192.in-addr.arpa.       IN PTR     tubo.alcomat.com.
2.253.253.192.in-addr.arpa.       IN PTR     mahou.alcomat.com.
3.253.253.192.in-addr.arpa.       IN PTR     augustiner.alcomat.com.
4.253.253.192.in-addr.arpa.       IN PTR     polar.alcomat.com.

 

The loopback address

A Name Server needs an additional file for the "loopback network": named.local. This is the address that hosts use for direct traffic with themselves. The loopback network is (almost) always 127.0.0 and the host number (almost) always 127.0.0.1.

named.local

0.0.127.in-addr.arpa.     IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week


;
; Name Servers
;
0.0.127.in-addr.arpa.         IN NS      augustiner.alcomat.com.
0.0.127.in-addr.arpa.         IN NS      tubo.alcomat.com.

;
; Address to name map
;
0.0.127.in-addr.arpa.         IN PTR     localhost.

 

The named.cache file

This file contains the address and names of all the root Name Servers on the the Internet. If you don't think you'll connect your network to the Internet, it's not necessary to install it.
Even though the BIND software package normally has this file (named.root or named.cache), it's best to go to the Internet host ftp.ts.internic.net(198.41.0.5) through anonymous ftp to download the current file. Since this file is the same for (almost) each Name Server and it is automatically installed with BIND, it won't be explained. The only thing that you need to know is what name this file has in your version of BIND.

The boot file: named.boot

Finally, what we lack is a file that unites our database files, in other words, the Name Server expects a file that shows it where the database files are located.
BIND looks for the file /etc/named.boot. The database files in our example are found in the directory /usr/local/named. You are free to choose another directory, but it's recommended not to put the files in the root file system because of lack of space.

named.boot

directory   /usr/local/named

primary    alcomat.com                named.hosts
primary    249.249.192.in-addr.arpa   named.249
primary    253.253.192-in-addr.arpa   named.253
primary    0.0.127.in-addr.arpa       named.local

cache      .                          named.cache

Once the files are installed, you should activate the "named" daemon in the system boot file so that it automatically starts up when the system boots.

 

Abbreviations

Up until now, we've created very detailed files to facilitate the explanation. Various abbreviations exist that are normally used.

The origin
The second column of the "named.boot" boot file always indicates a domain. This domain is the key for the most useful abbreviation and it shows the origin of all of the information within this database file.
The origin is joined to all the names within the files that don't end with a period! (mahou.aclomat.com would result in mahou.alcomat.com.alcomat.com). The origin is different for each database file.


The address of "mahou" from named.hosts:
mahou.alcomat.com.   IN A    192.253.253.2
would have to be able to be written:
mahou            IN A    192.253.253.2


We write the following in the named.249 file:
2.249.249.192.in-addr.arpa. IN PTR  whisky.alcomat.com.

because 249.249.192.in-addr.arpa is the origin, we will have to be
able to write:
2               IN PTR whisky.alcomat.com.

The notation @
If the domain name is the same as the origin, it can be determined with "@". This appear very frequently with the SOA record:


@ IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week

The repetition of previous names
If the first column of a resource record consists of a tab or a space, the name of the previous resource is used. This makes work easier when handling multiple resource records for a name:


tubo           IN A      192.253.253.1
            IN A      192.249.249.1

Finally, I'll present the named.hosts file in abbreviated form. It's a good exercise to make the changes on the remain files ;-))

named.hosts (abbreviated)

@   IN SOA    augustiner     juan.mahou (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week


;
; Our Name Servers (the name @ is included)
;

                            IN NS     augustiner.alcomat.com
                            IN NS     tubo.alcomat.com.
; Only in this file can the domain name be eliminated.(alcomat.com)
; of the Name
Servers, because named.hosts has the same origin!

;
; Host addresses
;

localhost                   IN A      127.0.0.1
mahou                       IN A      192.253.253.2
augustiner                  IN A      192.253.253.3
polar                       IN A      192.253.253.4
whisky                      IN A      192.249.249.2
brandy                      IN A      192.249.249.3
vodka                       IN A      192.249.249.4

tubo                        IN A      192.253.253.1
                            IN A      192.249.249.1

;
; Hosts with multiple residency
;

tub249                      IN A      192.249.249.1
tub253                      IN A      192.253.253.1

;
; Aliases
;

edel                        IN CNAME  augustiner
pol                         IN CNAME  polar
tu                          IN CNAME  tubo

 

The Resolve Library

The counter part to the Name Server is the Resolve Library, which consists in a group of functions pertaining to the standard "C" libraries under Linux. The most important Resolve routines are:

The most important files is host.conf, which controls the Resolve functions. It is found in the directory /etc and among other things determines which services and in which order they will be requested by the resolver.
For our fictitious network, we only need two options: order and multi.

The /etc/host.conf file in our example indicates to the Resolver to first use DNS and then the /etc/hosts file.

/etc/host.conf

# /etc/host.conf
# We use named and the host table:/etc/hosts
order   bind hosts
# We permit multiple addresses (only for /etc/hosts)
multi   on

Since our Resolver is using DNS, we have to tell it which Name Server to consult. To accomplish this, the resolv.conf exists.
The most important option in resolv.conf is nameserver, which indicates the corresponding Name Servers. Up to three Name Servers can be inserted. It is recommended to put the most reliable Name Server first, because they are consulted according to the order.
Two additional options exist - domain and search - which indicate domain names, and are joined to a host name in case the Resolver doesn't know the address. With regards to our example it is to say that when you put "ftp mahou", "alcomat.com" is automatically added. This way you are not obligated to write the complete name. The difference in the before mentioned options is that domain only permits one domain while search accepts various. The disadvantage of a list of domains is shown in a longer search.

/etc/resolv.conf

# /etc/resolv.conf
# The Alcomato Distributions domain
domain       alcomat.com
#
# The Name Server
# As a second IP-address it makes sense to put the IP-address of your
# Internet service provider
nameserver   192.253.253.1

 

 

Testing your setup with nslookup

Before using the nslookup tool, which uses BIND, we will investigate if syslog errors exist. If you have configured the boot file in a manner that "named" automatically starts during the system boot, and a message from "named" is printed, it is active. In the case that you prefer to manually start "named", use the following command:

# /etc/named -b /etc/named.boot (only root can do it)

If an error has occurred, messages appear, for example
Feb 12 21:16:48 tubo named [3221]: named hosts Line 15: database format error (192.249.249.3), indicating to you the file, along with the line where the error is found.

After correcting the errors, use the command
# kill -HUP 'cat /etc/named.pid'
so that the Name Server will read the database files again.

Tests using nslookup

With nslookup, any type of resource record can be searched for and can be sent to any Name Server. Here we are only going to talk about elementary tests.

Local searches:

  • The search for a local host name:

    # nslookup vodka
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: vodka.alcomat.com
    Address: 192.245.245.4
 
  • The search for a local address:

    #
    nslookup 192.245.245.2
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: whisky.alcomat.com
    Address; 192.245.245.2

If the two tests work in the manner shown, your Name Server is working correctly for your domain.

Searches for remote hosts:
In the case that your network has access to the Internet, it is best to use the nslookup command to look for a remote host.

  • The search for the name of a remote host:

    # nslookup ftp.uu.net
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: ftp.uu.net
    Address: 192.48.96.9
 
  • The search for a remote address:

    # nslookup 192.48.96.9
    Server: tubo.alcomat.com
    Address: 192.253.253.1

    Name: ftp.uu.net
    Address: 192.48.96.9

If this test passes, your Name Server can locate the root Name Servers (file: named.cache) and contact them to request information about remote hosts.



For more information:


Webpages maintained by the LinuxFocus Editor team
© Andreas J Gundacker, FDL
LinuxFocus.org
Translation information:
de --> -- : Andreas J Gundacker <AJGundi(at)aol.com>
de --> en: Dallas L. Gale <no(at)email>

2002-11-02, generated by lfparser version 2.34

mirror server hosted at Truenetwork, Russian Federation.