![[LinuxFocus Image]](../../common/May1998/border-short.jpg)
![[Navegation Bar]](../../common/May1998/Navegator-bar.gif){kind=small}
| News Archives Companies Tips |
Introduction to DNSby Andreas J GundackerThis 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.
This article first appeared in
Linux Magazine. |
|
The paper is divided into five sections:
The first briefly explains what the Internet means and how it came about. 1 The ARPANET, the origin of the World Wide Web 2 Understanding a few technical expressions 3 TCP/IP 3.1 IP 3.2 TCP (Transmission Control Protocol) 4 The Domain Name System (DNS) 4.1 A summary of the system 4.2 Why is DNS necessary? 5 Installing a Domain Name Server 5.1 Database files 5.2 Resource records 5.3 The complete files for our fictitious domain 5.4 Abbreviations 5.5 The Resolve Library 5.6 Testing your setup with nslookup (1) 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.
(2) 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 "phys".
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$quot; sends the packets to the gateway "phys", that has the same function the the physics network. The transfer goes through the university backbone and "phys" 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.
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. 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).
(3.2) 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.
(4) The Domain Name System (DNS) 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.
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).
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).
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
(5) Installing a Domain Name 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.
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:
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 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:
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 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:
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 The following records are the PTR records for the 192.249.249
network.
(5.3) The complete files for our fictitious domain The hosts table file for the alcomat.com domain
The named.249 and named.253 files for mapping addresses to host names
The loopback address
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. 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.
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 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 @ @ 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 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 ;-))
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.
The /etc/host.conf file in our example indicates to the Resolver to first use DNS and then the /etc/hosts file.
Since our Resolver is using DNS, we have to tell it
which Name Server to consult. To accomplish this,
the resolv.conf exists.
(5.6) 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 After correcting the errors, use the command
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:
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. |
Translated by Dallas Gale
- TCP/IP Network
Administration: Craig Hunt; O´Reilley; 1992
- DNS and BIND: Paul Albitz & Cricket Liu; O´Reilley; 1997
- LINUX Network Administrator´s Guide: Olaf Kirch; O´Reilley; 1995
- Proyecto Web: Jon Udell, BYTE, Diciembre
1997
This website is maintained by Miguel A Sepulveda.