![[LinuxFocus Image]](../../common/images/border-short.jpg)
![[Navegation Bar]](../../common/images/Navegator-bar.gif){kind=small}
| 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
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. |
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 "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.
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.
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).
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) 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.
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
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
|
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.
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 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. |
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.
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.
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 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 |
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:
|
|
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.
|
|
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.
|
Webpages maintained by the LinuxFocus Editor team
© Andreas J Gundacker, FDL LinuxFocus.org |
Translation information:
|
2002-11-02, generated by lfparser version 2.34