Gokmen Portal - (DNS System Configuration)

Your IP address
38.107.179.242

The Universal Declaration of Human Rights
Turkish - English

©CopyLeft by
Mustafa GÖKMEN
Konya / Turkiye, 2008.

Visitors

There are no copyrighted materials here.
All products, names and rights are respected to their owners.

Overview

Domain Name Service (DNS) is an Internet service that associates a Text Name with a Numeric Address. Normally when a user or program refers to a domain name (such as www.gokmen.net) to locate a resource on the Internet, DNS is used to convert that name to a numeric address (such as 81.128.54.52) which is then used to actually locate the resource.

Every device that can be reached on the Internet via TCP/IP is identified by a unique 24 bit numeric address, called an Internet Protocol (IP) Address. IP addresses are normally written as four numbers separated by periods. Each of the four numbers can range from 0 to 255 (e.g., 81.128.54.52). IP addresses are grouped by ranges into networks and are used to locate a specific machine or resource on the Internet much in the same way that a telephone number is used to identify a telephone instrument on the international telephone system.

Because humans often find it easier to remember names than numbers, the DNS system was devised to associate the names with the numeric IP addresses. The Domain Name System is a hierarchical, distributed system. It is hierarchical in that names are grouped into domains, then within a domain into sub-domains, and so on until the individual machine is uniquely identified.

The primary top level domains that the Domain Name System is grouped into are:

.COM for commercial businesses

.ORG for Non-Profit organizations

.NET for organizations providing Internet Connectivity Services

.GOV for the US Federal Government

.MIL for the US Military

.EDU for 4 year accredited Universities

There are also other primary domains for countries outside the US, such as .TR for Turkey and .UK for England.

Unique names are registered within each primary domain, such as gokmen.com.tr within .COM.TR, gokmen.net.tr within .NET.TR, and gokmen.edu.tr within .EDU.TR. Normally a business or organization registers a single domain name to uniquely identify themselves on the Internet. This is what is most often referred to as "The Domain Name". This Domain Name might refer to an actual computer system, but it most often refers to a network of computers, and each computer system or service in that network has its own unique name added to the Domain Name, such as www.gokmen.net, ftp.gokmen.net, and mail.gokmen.net. As networks grow more and more complex, additional levels can be added to a network, each adding their own name to the levels in "The Domain Name".

As you can see by the above examples, the Domain Name grows to the left as each new level is added to the hierarchy, and each network level is separated by a single period. In addition to logically organizing the name, this has another meaning: It identifies how the DNS system is distributed for that specific name.

The Domain Name System is built as a distributed information system. At the base of the distributed system is a series of root DNS servers. A DNS server is a computer that has information on one sub- section of the entire DNS system. The DNS server is available on the Internet to provide this information to users on the net. The root servers are maintained by a number of organizations. As of this writing there are 9 root servers each providing duplicate information. The multiple systems provide redundancy and serve to spread the load of the service among various systems. In the DNS system each root server actually has a unique name, but each also responds to the name of "." (referred to as DOT).

The DOT servers, or root servers, have information on the IP addresses of other DNS servers that have information on the primary domains (.COM, .NET, .GOV, etc.). Within each primary domain server there is information identifying each sub-domain under that primary domain. For example: the root servers have information telling where to find the DNS servers for the .COM domain. The DNS servers for the .COM domain have the information telling where to find the servers holding information on omer.com, furkan.com, muhammed.com and any other Domain Name in the .COM Domain. Following this out further, the servers with the information on gokmen.net will have the information on the address of www.gokmen.net, ftp.gokmen.net, mail.gokmen.net etc.

When a program does a lookup of a Domain Name, the query follows the path from the root out to the server that actually can identify the name.

The name server will pass the requested information back to the computer that made the original request. In addition, the name server will place this information in it’s local database cache along with information telling how long to keep this information on file before it should be expired as old and no longer reliable.

Setting Up a DNS Server

If you have a your own Domain Name, and you have a permanent connection to the Internet, and you have a network of any size, it is often a good idea to set up your own DNS server. This gives the systems on your network a local contact for DNS information and allows you to maintain and control the names and addresses of your own systems. The DNS server you set up might be as simple as a small 486/33 system running Linux, or you might set up DNS as one of several services hosted by a larger UNIX or NT Server.

Normally the only requirement for a DNS server is that it be connected to the Internet on a permanent basis and that it be reachable from the Internet via TCP/IP.

Most DNS servers, whether they are on UNIX, NT, or any other system, follow a similar structure and setup scheme. This is because most are based on the publicly available Berkeley Bind program source code. With this in mind, this article will first go over the general setup principles, then will link to separate pages giving examples of how to set up specific versions of DNS on a Windows NT system and on a Linux system.

The first step to setting up a DNS server is to acquire the software for the specific server on which you intend to host the service. Then you need to copy it into the correct directories on that system. Consult the documentation for your particular software for instructions on how to do this.

Once you have the software loaded onto the system, the next step is to set up a Boot Configuration file. This file tells your DNS server what Domain Names it is hosting, the directories on the server system to use, and the names of the files from which the DNS server will load it’s databases. This file is often called the NAMED.BOOT file. This is an example of a typical NAMED.BOOT file:

   ;
   ;   boot file for name server
   ;
   directory   /etc
 
   cache   .   root.cache
 
   primary gokmen.net   db.gokmen.net
   primary 146.217.205.IN-ADDR.ARPA db.205.217.146
   primary 0.0.127.IN-ADDR.ARPA db.127.0.0

The lines that begin with a semi-colon are comments and are ignored by the software.

The line that begins ‘directory’ tells the software the name of the directory to be used for files that do not have a full path name.

The line that begins ‘cache’ tells the software where to find the file containing the list of root servers.

Each line beginning with ‘primary’ identifies to the software a domain for which it will be hosting authoritative database information. It also identifies the name of the file from which the information for this domain should be read. For example, in the above file, the server will be a Primary DNS server for the gokmen.net domain, and the information on that domain is found in the file ‘/etc/db.gokmen.net’.

The two primary lines that have .IN-ADDR.ARPA as part of the domain name are identifying to the software that it will be providing Reverse Arpa lookup services. Reverse Arpa is how the DNS system allows a program or user to find the Domain Name for given IP addresses in addition to finding the IP addresses for specific Domain Names.

After setting up the named.boot file, the next step is to get a current Root Server list. This is a file that lists the servers at the root of the DNS distributed database. One good place to get this file is from nic.ddn.mil. Go to their home page, http://nic.ddn.mil, select Domain Naming System (DNS) Information, select Domain Naming System Files, and then select the root.cache file (as of this writing, the direct URL for this is ftp://nic.ddn.mil/domain/named.cache). This file should be downloaded and copied into the correct directory for your software. Some systems name this file "root.cache", on others it could be "named.cache" or "cache.dns" . Consult your specific documentation for the correct directory and name required by your software.

The next step in setting up your DNS server is to set up a domain database file. This file defines the domain to the DNS server. This is the most critical file in setting up your DNS server, and is the one in which the most errors are usually made. Study the documentation that comes with your particular DNS software for information relating specifically to your server. The following is an example of a simple domain database file:

   gokmen.net.  in  soa  ns.gokmen.net.  hostmaster.gokmen.net. (
       1996090101   ; Serial number yyymmddnn
       10800        ; Refresh in 3 hrs
       3600         ; retry in 1 hr
       604800       ; expire in 7 days
       86400 )      ; minimum ttl 1 day
 
   @   in   ns   ns.gokmen.net.
       in   ns   ns.telekom.com.tr.

       in   mx   10   mail.gokmen.net.
       in   mx   20   mail.telekom.com.tr.
 
   dns         in   a       205.217.146.198
               in   mx  10  mail.gokmen.net.
               in   mx  20  mail.telekom.com.tr.

   localhost   in   a       127.0.0.1
   mail        in   a       205.217.146.200
   www         in   cname   ns.gokmen.net.

On the first line of the file, the arguments "gokmen.net. in soa" states that this defines the start of authority for the Internet domain gokmen.net. The section "gokmen.net." specifies the domain name, the "in" specifies Internet, and "soa" specifies it is the start of authority.

The next section of the first line, "ns.gokmen.net", specifies that this DB file was created on the system known as ns.gokmen.net.

The next section of the line, "hostmaster.gokmen.net", identifies the E-Mail address to which inquiries about this domain should be sent. To determine the E-Mail address replace the first period in the name with an @, in this case giving you hostmaster@gokmen.net as the address. A period is used instead of the @ because an @ is a special character in a DNS DB file.

Note that the first line ends in a left parenthesis. This allows the Start of Authority record to span multiple lines. The next five lines contain additional information for the SOA record.

The serial number line must contain a unique number that is incremented each time the DB file is updated or changed. This allows other DNS servers to determine if the information they have is out of date. A very common practice is to create a serial number from the year, month, and day, followed by a two-digit number. The serial number "1996090101" would break down to Sept. 1, 1996, first time edited that day.

The next three lines contain information that is specifically for a Secondary DNS server. In the DNS system only one server is normally Authoritative for a particular domain. Even if there are other servers hosting for the domain, they all get their information from the Primary. The other servers are called Secondary servers. Secondary servers contact the Primary and pull information from it, then check back regularly to make sure that their information is still accurate.

The "refresh" line specifies that a secondary DNS server checking this server for information should check every 3 hours (10800 seconds is 3 hours) to make sure it’s data is accurate.

The "retry" line specifies that if a secondary DNS server checks this server for information and finds it down, it should check back in 1 hour (3600 seconds is 1 hour).

The "expire" line specifies that if a secondary DNS server is unable to contact this server for 7 days, then it should expire all the information on this domain as unreliable (604800 seconds is 7 days).

The "ttl" line applies to all of the information in the DB file. It specifies that any server that requests information about this domain should cache that information for 1 day, then expire it as old and unreliable (86400 seconds is 1 day). Any time any DNS server requests information from the server, this value will be sent along with the other information.

The right parenthesis on the "ttl" line ends the SOA entry in the file.

Note that on the SOA line as well as on all other lines in the file, any excess white space (spaces and tabs) separating the arguments is ignored by most DNS programs (check the documentation provided with your software for rules specific to your server software). This allows you to use spaces to make your DB file easier for you to read. Also note that the information on a line following a semi-colon is ignored as comments and should also be used to make the file easier for you to read.

The next line in the file begins "@ in ns". This line identifies that a computer that serves as a DNS Name Server for this domain is ns.gokmen.net. The @ is a shorthand way of referring to the domain name, and in this file is therefore the same as writing "gokmen.net.". The "in ns" specifies Internet Name Server. The "ns.gokmen.net." specifies the name of the system providing the service.

Note the trailing period in the name "ns.gokmen.net.", this is important: In a standard DNS DB file, any name argument that does not end with a period will have the name of the domain added to it. If this argument was written "ns.gokmen.net" without the trailing period, the DNS program would expand that to "ns.gokmen.net.gokmen.net.", providing incorrect information. To save space and time, the name could be written "dns", which would be expanded correctly to "ns.gokmen.net.".

The next line after the "@ in ns" also identifies a computer that serves as a DNS server for this domain. When a line in the DB file does not begin with a name, and does not begin with an @, then it will default to the last name used, in this case it uses the @ which expands to "gokmen.net.". This line identifies ns.telekom.com.tr as another system providing Name Services for the domain gokmen.net.

The next line in the DB file begins "in mx". This line specifies that the computer that will provide Internet Mail Exchanger services for gokmen.net is mail.gokmen.net. The "in mx" specifies Internet Mail Exchanger. Because the line begins with spaces instead of a name, the program will use the last name specified which was @ (expanded to gokmen.net.). The next argument, "10", is known as a preference value. The last argument specifies that the system providing the mail exchanger services is known as mail.gokmen.net. A mail exchanger is a computer to which mail for this computer can be sent. In effect, this line says "When you are trying to send E-Mail to anyone@gokmen.net, then it should actually be sent to anyone@mail.gokmen.net."

The next line in the DB file also begins "in mx". This line identifies another computer that will provide Internet Mail Exchanger services for the gokmen.net domain. Note that the preference argument on this line (20) is higher than the preference value on the previous line. This tells anyone out on the Internet who is trying to send mail to gokmen.net that they should try mail.gokmen.net first, and if it is unreachable, then try mail.telekom.com.tr. This implies that mail.telekom.com.tr will hold the mail until mail.gokmen.net is reachable, then will forward the mail to be picked up. In large networks it is not uncommon to have 2, 3, or more mail exchangers with different preference values to guarantee that a server is available to receive incoming mail.

The next line in the DB file begins "dns in a". This specifies that the Internet Address of the computer "ns.gokmen.net." is 205.217.146.198. Note that the name argument "dns" does not have a trailing period, so it will be expanded to "ns.gokmen.net.". The "in a" specifies Internet Address. The number at the end of the line specifies the IP address for this name. Also note that the IP address does not end with a trailing period. The IP address is not a name argument so it will not have the domain name appended to it.

Following the line that defines ns.gokmen.net. are two "in mx" lines. These two lines specify the mail exchangers to be used if any mail is addressed to anyone@ns.gokmen.net.

The next line is one that is found in almost all DNS DB files. It begins "localhost" and defines to the DNS system how to find the local loopback for any computer in the gokmen.net domain. A standard feature of TCP/IP is that the address 127.0.0.1 will "loop back" to the computer that originates the request. It is a similar feature of DNS that the name "localhost" will also loop back to the computer originating the request. Note that the name "localhost" does not have a trailing period. This means the name will be expanded to "localhost.gokmen.net.".

The next line of the DB file is another address record. It specifies that the Internet address for mail.gokmen.net. is 205.217.146.200.

The last line in this file is "www in cname ns.gokmen.net.". This tells the DNS program that another name for ns.gokmen.net. is www.gokmen.net. The argument "www" does not end with a period, so it is expanded to "www.gokmen.net.". The "in cname" specifies that this is an Internet Canonical Name, a term for "Alias". The last argument specifies that this defines an alias for "ns.gokmen.net.". The result of this is that when the name www.gokmen.net is requested in a lookup, the DNS system will return the address 205.217.146.198.

There are many other things that can be included in a DNS database file, but the above covers the basic information that will get probably 90% of users up and running.

After the main DB file is set up, the next thing to set up is the Reverse Arpa files. Reverse Arpa is a feature that allows a user or a program to take an IP address and look up the Domain Name that is associated with it.

When it was decided to add this ability to the DNS system, rather than add a whole new set of functions, it was implemented simply by making the information fit the existing system as closely as possible.

A standard Internet Domain Name is a series of names separated by periods, with the most specific designator on the left moving to the most global designator on the right (e.g. www.gokmen.com.tr designates the www system in the Gokmen Ltd. network under the .COM.TR domain). An IP address is the reverse: a series of numbers separated by periods with the most global designator on the left moving to the most specific designator to the right (e.g. 198.137.240.91 could be read to designate system 91 in subnet 240 of network 137 in global network 198).

When Reverse Arpa was implemented, a new top level domain was created: IN-ADDR.ARPA. Historically this was because the Advanced Research Projects Agency (ARPA) was funding the Internet (which at that time was called ARPA-NET) and the purpose of the reverse lookup was to get the Internet Address, therefore IN-ADDR.ARPA. The top level domain name has remained ever since. To make the IP address fit the Domain Name conventions, the order of the numbers is reversed and added to IN- ADDR.ARPA. Thus, to find the name associated with the IP address 198.137.240.91, the request made to the DNS system would be for 91.240.137.198.in-addr.arpa. Many people find this confusing, and rightly so. Fortunately this is usually handled by programs and is transparent to users.

Reverse lookup is used for many purposes, and is as important to maintain properly as standard DNS records. Many programs, such as the traceroute utility and most WWW Servers, use reverse lookup as part of their standard operation to display names along with IP addresses. This is to make their output more readable. If these programs do a reverse lookup on an IP address that does not have a name, they are often subject to long delays while they wait for the unanswered request to time out. In addition to this, many firewalls and server systems on the Internet require a system that is trying to connect to them to have a valid reverse lookup. This is to discourage hackers from trying to hide their identities. Also, many of the popular FTP libraries will not allow a connection unless the user has a valid reverse lookup to log in their records. These reasons and many others make reverse arpa important.

In many ways the reverse arpa DB file is the same as a standard domain name DB file. The following is an example of a typical reverse arpa file:

   @  in  soa  ns.gokmen.net.  hostmaster.gokmen.net. (
         1996090101   ; Serial number yyymmddnn
         10800        ; Refresh in 3 hrs
         3600         ; retry in 1 hr
         604800       ; expire in 7 days
         86400 )      ; minimum ttl 1 day
 
   @     in   ns    ns.gokmen.net.
         in   ns    ns.telekom.com.tr.

   198   in   ptr   ns.gokmen.net.
   200   in   ptr   mail.gokmen.net.

The first several lines are essentially the same as the standard domain name file. Note, though, that this file uses an @ at the beginning of the SOA line. This is allowed and will expand into the full name for the domain, in this case 146.217.205.in-addr.arpa.

Just as in the standard domain DB file, there are also "in ns" lines identifying the name servers for the domain.

The last two lines are slightly different from those found in the standard domain DB file. These identify that the name being looked up (in this case reverse arpa names) point to domain names instead of IP addresses. The "in ptr" stands for Internet Pointer. Note that the first argument on the line does not have a trailing period. It is a name argument, so the domain name is appended to it, giving the result 198.146.217.205.in-addr.arpa for the first of the two lines. Also note that the last argument on the line is not an IP address, but a fully expanded name that ends in a period. In this file it is doubly important to be careful to properly use trailing periods when setting up and changing the files.

When setting up the reverse arpa files for your DNS server, you will normally need to set up one for each Class C address that you are using. If you are using Class B addresses, or a subnet of a class C, then you should contact your Internet Service Provider for assistance in setting up reverse arpa.

In addition to the reverse arpa file(s) for your IP addresses, you also need to set up a reverse arpa file for your loopback address. The following is a standard loopback reverse arpa file:

   @  in  soa  ns.gokmen.net.  hostmaster.gokmen.net. (
       1996090101   ; Serial number yyymmddnn
       10800        ; Refresh in 3 hrs
       3600         ; retry in 1 hr
       604800       ; expire in 7 days
       86400 )      ; minimum ttl 1 day
 
   @   in   ns    ns.gokmen.net.

   1   in   ptr   localhost.

One final consideration in setting up your reverse arpa files: You normally register your Domain Name with the InterNIC, and the InterNIC takes care of pointing the top level domain DNS servers at your domain level server. With reverse arpa, however, you need to coordinate with your IP provider to get the reverse arpa properly set up. In a typical setup, you might be getting a single class C group of 256 IP addresses from your Internet Service Provider (ISP). In this case the ISP must properly delegate the reverse arpa to you for hosting. If instead you are using a "provider independent" set of IP addresses directly from the InterNIC, then you would have to arrange reverse arpa delegation through the InterNIC.

In addition to the DNS configuration files, there may be other files needed to tell your specific software how to start and execute the DNS server. On a Unix system it is often necessary to configure HOSTNAME, hosts, and resolv.conf files so that the machine running the DNS server can operate on the network to setup, start, and find it’s own DNS server. On a Windows NT system it is necessary to properly set up the TCP/IP configuration in the Control Panel | Network applet and to properly set up the Services database so that the system can enable TCP/IP and start the DNS service.

Once you have the configuration files properly set up and in the correct directories, the only things left to do are to start your DNS server software, and to test and exercise it. Under Unix there are a number of well-developed testing tools for the DNS system. Under Windows NT some of these tools are available, and more may be available by the time you read this. It is important to note that whether or not your server is on Unix or NT, the testing tools of either should work to test your server.