Friday, June 24, 2005

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

2 Comments:

Blogger Bratrat said...

Hey Such,
good stuff man! however, for an absolute newbie/layman like myself, most of the info pretty much is OHT (Over Head Transmission!!)... ;D
No offense, but if you could maybe do the public good deed of introducing the benefits and usability of linux to the layman in his language, I'd say, that would be a super achievement!!!
Hope to add some value to this work...in the future! :o)
cheers!
Bratrat

6:44 AM  
Blogger suchi said...

Dear bratrat ! ,
I had written another document detailing what a domain is, and this document is infact the second one that followed. The first one is very simple and "sane". Well, i will defnitely add more. Have too much stored in brain, don't know what to add. I would like to increase intereast in Linux in others' minds this way. Well, more later, one more article added on 11th july. I am really happy that you have seen and added ideas and would like to thank you for your encouragement and ideas.

Suchi

9:58 AM  

Post a Comment

<< Home