A Linux Domain

I had basically written about domains in my earlier article. In this one i would like to write about how to build a basic Linux Domain. A basic Linux Domain like any other one, must be able to perform the following tasks:

1. Maintain a detailed database of name-to-address( forward ) and address-to-name ( reverse ) resolutions for the different systems( or hosts ) that are required to be broadcast on the Internet.

2. Provide Name-to-address ( and address-to-name ) resolutions to any client that queries the domain.

The domain may delegate the above mentioned tasks either to a single "system ( or server )", or many servers. Depending upon that, the arrangement may involve delegation to a "single Master Name Server ( program ! )", or " One Master Name Server , and at least one Slave Name Server". Further the Master Name Servers and Slave Name Servers may be classified as Forward or Reverse depending upon whether they answer queries relating to Name-to-Address or Address-to-name resolutions respectively.

A carefully written set of files is maintained in the Server ( or system ) that runs the Master Name Server Program. These specify all the parameters that are required to perform the above tasks successfully. A copy of these is also maintained in the system that runs the Slave Name Server program ( and updated at frequent intervals ). The following are the files that have to be maintained ( on a Redhat Based Linux System, and in general ):

1. /etc/named.conf
2. /var/named/named.ca
3. /var/named/localhost.zone
4. /var/named/named.local
5. /var/named/xyz.com.zone
6. /var/named/xxx.yyy.zzz.in-addr.arpa ( for a general ipv4 type domain )

Note that the above mentioned names may be anything as long as they have been mentioned properly in the named.conf file

1. "named.conf": This file, as mentioned above describes the domain in general terms. It contains details about -
a. Where the domains working directory resides
b. Path of file containint the authentication key. This key is nothing but an automatically and randomly generated stream. One of the main purposes of maintaining such a key ( also called "rndc.key" ) is for authenticating transfer of domain's database to Slave Name Server ( which is done at frequent intervals ).
c. A "controls" command that specifies the DNS to use the rndc key for authentication.
d. Paths of the 3rd, 4th, 5th and 6th files.

Before writing to this file, it must be remembered that this file is parsed by a program which expects very less level of tolerance. Hence it is necessary to maintain this file ( and the rest of files ), as accurate as possible.

2. "named.ca": Caching Only Name Server is better explained by an example. Take a setup where there is an internal domain by name abc.com ( meaning you cannot access it from any outer system connected to the internet, other than the systems served by the domain ). To put it simply, you cannot type http://abc.com from any system other than the ones served by the domain, and access it. Now say 10 clients are served by the domain. For these clients, this is the immediate domain. Whenever requests for IP addresses of any website are made by a client machine, the immediate domain / Server associated with the client sends the request to different (internet broadcast )domains as explained in the previous document. What is necessary to know, is that this process takes a lot of time. Hence, the IP addresses of most accessed domains by clients are stored in a file called named.ca, by the immediate domain. Not only that, it also contains the IP addresses of the Root Name Servers ( refer to the previous document for clear explanation of this term ), in the internet. This can be downloaded in the internet at ftp.internic.net . Generally they are present in the system itself by default.

3. "localhost.zone": Forward Requests / queries( ie., Name-to-Address queries ) from the system running the Name Server Program, are answered by the domain, using the data stored in this file.

4. "named.local": Same as above, except this file is used for Reverse Lookups ( ie., Address-to-name ). It contains an entry which specifies that the loopback address (ie., 127.0.0.1 ) has to be mapped to the host running the Name Server Program, when requests stem from that system.

5. "xxx.com.zone": This is the file which provides data relating to your domain ( xxx.com here ). It particularly provides IP addresses for answering Forward Lookup Queries.

6. "xxx.yyy.zzz.in-addr.arpa": This file provides data for answering Reverse Lookup Queries.


Now the crucial point. How to fill up the files ? The files have to be filled in a pre-defined way, as they are generally parsed by a very concise Name Server Program. I have provided the files in the order mentioned above.

1. /etc/named.conf ( Path may vary depending upon system. It might be /etc/named/named.conf in some systems ):

options {
directory "/var/named";
// indicates where the files relating to the domain reside
};
// donot forget the ";"

controls {
inet 127.0.0.1 allow { localhost;} keys { rndckey; };
};

// inet stands for "of type internet". It does not mean your domain // broadcast to internet. It is just to specify that the domain handles
// such data. Rest of it can be read as " Allow localhost complete access
// , and use rndckey technique for authenticating requests of update
// and the like"

zone "." IN {
type hint;
file "named.ca";
};
// Can be read as " Hints for answering IP addresses of Repeatedly
// requested domain names are in a file called 'named.ca'

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
// Can be read as "The file 'localhost.zone' is the file containing
// the data required for answering forward lookup queries, and right now
// no slave server has been defined for updating domain data to"

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

include "/etc/rndc.key";


2. localhost.zone:

$TTL 86400
// Please remove lines starting with '//' in this file ( just for safety ).
// TTL: In the example above, during explanation of named.ca, we talked of
// domain abc.com . TTL is the time period for which the domain abc.com must
// store IP addresses of repeatedly requested domains before updating itself
// with the data from the real domains.
$ORIGIN localhost.
@ 1D IN SOA @ root (

// Remember the tab-spaces, the final '.' after 'localhost' .
// It signifies that the Root Name Server for the present setup is not to be
// contacted in the internet. In other words, it signifies that the Name Server
// Program that is run, is the one that acts as the Root Name Server.

// SOA is Start Of Authority. It specifies the system/server that is to be
// queried for information relating to Forward Lookup requests from same server.
// 1D is also a TTL ( in a sense ). That is, it specifies that;
// , when a query for Name-to-Address resolution comes from the
// system/server running the Name Server program, the Server specified by @
// ( ie., localhost ) supplies it with the answer " FOR ONE DAY". After one
// day update the information again.
// root is the user whom to mail any log / error entries
42 ;
3H ;
15M ;
1W ;
1D) ;

// 1st number is Serial Number which indicates the revision number of
// the present file
// 2nd number is the refresh frequency, which indicates that the local Slave
// Name Server waits for 3H before updating itself with domain data
// from system running the Master Name Server program.
// 3rd number is the retry rate, indicating the time period which must
// expire before each consecutive query retry by the Slave Name Server
// 4th number is the expiration period, which is the time period for which
// the Slave Name Server must keep querying if it does not get proper response
// from the Master Name Server.
// 5th number is also a TTL, but it is solely dedicated towards other Name Server
// Programs, whereas the previous TTL referred to individual hosts also.


1D IN NS @

// Can be read as " Localhost is the server that answers queries, and keep
// the data (ie., IP Addresses), in cache for one day"
// NS stands for Name Server

1D IN A 127.0.0.1

// Can be read as " 127.0.0.1 is the loopback address"

3. "named.local":

$TTL 86400
@ IN SOA localhost. root.localhost. (
200506241 ;Read reverse order as "1st revision on 24 June, 2005
28800 ;
14400 ;
3600000 ;
86400 ) ;

IN NS localhost. ;

1 IN PTR localhost. ;

// Remember to leave one blank line after all the data on these files
// PTR is the way of indicating that 127.0.0."1"( the first "1") stands for localhost



4. "xxx.com.zone":

$TTL 3D
@ IN SOA host-running-name-server.xxx.com. hostmaster.xxx.com. (
200506241 ;
8H ;
2H ;
4W ;
3D ) ;

IN NS host-running-name-server.xxx.com. ;

5. "xxx.yyy.zzz.in-addr.arpa":

@ IN SOA host-running-name-server.xxx.com. hostmaster.xxx.com. (
200506241 ;Read reverse order as "1st revision on 24 June, 2005
28800 ;
14400 ;
3600000 ;
3D ) ;
IN NS host-running-name-server.xxx.com.


Files 4 and 5 follow the same rules as for template provided in file localhost.zone. In both the previous files, only NS entries have been included, but one must also include entries for the different hosts connected to the domain. Forward entries look like

netbios-name-of-host IN A aaa.bbb.ccc.ddd

Reverse entries look like

1 IN PTR netbios-name-of-host.xxx.com


The above files are just an indication of how to write the domain files. They must not be taken as the original ones. One must also check the different other parameters that decide whether a domain runs properly or not; like

a. Proper permissions in firewalls, for allowing TCP requests on the right ethernet cards.
b. Proper /etc/resolv.conf entries that signify calls to be made to domain before checking idividual hosts.
c. The service named has to be started after making sure that the above files have been written properly, by using utilities such as named-checkconf ...etc
d. DNS lookup should be checked using commands like dig which give outputs similar to the one below:

; <<>> DiG 9.2.2 <<>> www.google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24918
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 668 IN CNAME www.l.google.com.
www.l.google.com. 42 IN A 66.102.7.147
www.l.google.com. 42 IN A 66.102.7.99
www.l.google.com. 42 IN A 66.102.7.104

;; AUTHORITY SECTION:
l.google.com. 67989 IN NS b.l.google.com.
l.google.com. 67989 IN NS c.l.google.com.
l.google.com. 67989 IN NS e.l.google.com.
l.google.com. 67989 IN NS a.l.google.com.

;; ADDITIONAL SECTION:
a.l.google.com. 68456 IN A 216.239.53.9
b.l.google.com. 68456 IN A 64.233.179.9
c.l.google.com. 68456 IN A 64.233.161.9
e.l.google.com. 68457 IN A 66.102.11.9

;; Query time: 196 msec
;; SERVER: 202.54.12.163#53(202.54.12.163)
;; WHEN: Thu Jun 23 22:25:50 2005
;; MSG SIZE rcvd: 228

LinuxHackerBox

Bind - DNS basics

Table Of Contents:

Basic terminology:

1. Meaning Of Domain
2. Zone
3. Recursion and Iteration
4. Types / Other Uses of a Domain

A Linux Domain:



1. Meaning Of Domain:

An Internet Domain can be briefly described as a "hierarchical methodology of storing / retrieving information on the Internet". Let us imagine a smaller version. Take floppy for example. Here the organization of data is defined in the form of FAT, Root Directory Table, Inodes ... etc. Once data organization is defined, one goes about writing programs for both "writing to" and "reading from" the floppy based upon the above design. Same way, the Internet is also a collection of huge quantity of Data, which is organized in a pre-defined hierarchical manner. So there must be "programs" that "write to" and "read from" this storage mechanism. The programs that "read from" the internet are what we call the browsers. They ask queries to the programs that "write to" and "maintain" Information that is requested for. In most basic terms, the programs that "write to" and "maintain" this information in the Internet are called Name Servers.


For accessing a sector of a floppy for example, we need some parameters ( such as sector number, the cylinder number etc ).In the same way, to access any Internet Domain, we need IP Address of the domain. So that is the parameter that the Browser on client's system queries for. The internet Domain in turn contains a program called Name Server that performs the task of answering the query. So a Name Server "can be primarily thought of as a 'program' that performs the task of returning the IP address corresponding to a name query ( eg., www.rediff.com, www.india.com.........)".

2. Zone

One can imagine Zones by looking at a very simple example. Imagine a small software company of 100 developers, with a name "www.scmpny.com". The programs that are written by the developers are stored in different hosts within the company which are interconnected to one another. So is the information related to the developers ( like say, i. User information, ii. Programs Developed and their permissions , iii. Information related to the programs ( such as their revision numbers ) etc... The above software company can be thought to be having a certain "centralized" set of "servers" ( or computers ) that perform the following tasks :

1. Providing the users ( in this case, the developers ), the "user space" ( for writing their programs into ).
2. Providing necessary services for monitoring ( or "administering" ) critical user information
and permissions.

Thus the above setup consists of a set of computers that have been "delegated" the "authority of administering the database of user information and data". Now, the above setup can be called a "Zone" that is administered by "the delegated servers".

But, the outside internet world need not necessarily know about the internal mechanism of administration and activities. They are interested in knowing about the software that has been developed by the organization and related details. So there must also be some "other" delegated servers which perform the above task. Those servers can be thought of as forming another so called "Zone". Though, it is particularly inappropriate to consider the above example in the strictest of terms, it is quite easily a way of appreciating the concept of Zones.

3. Recursion and Iteration:

Now that we know that browsers query for the IP addresses, we must define how they do so. Whom do they query ? The query put forward by the browsers, goes to 13 or 14 "root" programs which are conveniently placed in the Internet. These programs are the root name servers. They are represented by the symbol "." . Now, looking at the speed at which internet is growing, and the complexities that arise when only 13 to 15 programs have to answer all the queries, the same technique mentioned in the above example ( of www.scmpny.com ) is used for simplification. That is , delegation. The root servers delegate other servers with the job of answering the queries put forward by the millions of users in the internet. These delegated name servers are nothing but the programs that in turn handle ".com", ".org", ".biz" ... domains independently.

There are two ways in which a query can be handled. Say for example , host A queries for http://www.development.scmpny.com . Now, the query initially goes to one of the root servers, which in turn "query the name server that handles only ".com" type of domains. The name server that handles ".com" type of domains, in turn queries another name server that handles ".scmpny.com", to obtain the IP address. Provided there is a physical system ( or node ) that represents "development.scmpny.com" in "scmpny.com", its IP address is returned to the ".com"'s name server by the ".scmpny.com"'s name server. This is the first method of getting the IP address to host. This method as can be seen is too centralized, and provides a lot of burden upon the top level servers. Another such "method" can be used for answering such queries. The root ( "." ) server instead of making the host wait for the IP address, can ask the host ( the host making the query that is ), to go and query the name server handling ".com" queries. This way the root server is freed for answering other hosts. Again, the name server handling ".com" queries, "diverts" the query to one(s) that handle ".scmpny.com" ... and so on. This difference in type of query answering mechanism is what distinguishes whether the method is that of Recursion or Iteration.

4. Types / Uses of a Domain:

An Internet Domain can be used for hierarchical arrangement and administration of different "types" of data. Data may be just user names and passwords, as it is, in the case of a basic mail server. It might be just a internet mapping and searching program ( a search engine ). It might as well be a dedicated one to be only used by a very limited set of users in some remote locations( VPNs ). There exist domains that perform the tasks of each type mentionable on earth !

Dear all,

This blog has been started on 22nd June 2005. As of now, this blog is "intended" to provide information of the following types to people who might be interested:
1. Information related to Linux
a. Common Topics,
b. Administration,
c. Tweaking

2. Information related to Assembly programming, and

3. General Topics.

Even i am new to blogging, and i hope that i will be able to provide more detailed and relevant information relating more diverse fields and topics as days go by.

Suchindra C