Nagios Server monitoring tool and its Installation in Centos/Fedora/RHEL

Nagios is the industry standard in enterprise-class monitoring for good reason. It allows you to gain insight into your network and fix problems before customers know they even exist. It's stable, scalable, supported, and extensible.

Let me show you how to install nagios monitoring tool .

1- First install some tools : httpd, gcc, glib, glibc-common, gd and gd-devel

--> yum install httpd

--> yum install gcc

--> yum install glibc glibc-common

--> yum install gd gd-devel

2- Create nagios user :

#/usr/sbin/useradd -m nagios

#passwd nagios

3- Add nagcmd group

/usr/sbin/groupadd nagcmd

/usr/sbin/usermod -a -G nagcmd nagios

/usr/sbin/usermod -a -G nagcmd apache

4- Now go to http://www.nagios.org download files .

nagios-3.1.0.tar.gz nagios-plugins-1.4.13.tar.gz nrpe-2.12.tar.gz
 
tar  -zxvf  nagios-3.1.0.tar.gz 

cd  nagios-3.1.0

./configure --with-command-group=nagcmd

 #make all; make install; make install-init; make install-config; make install-commandmode; make install-webconf

5- Edit your email admin address :

vi /usr/local/nagios/etc/objects/contacts.cfg

6- Create a nagiosadmin account for logging into the Nagios web interfaceassign to this you’ll need it later.

    htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

 then enter the password.

7- Restart the httpd server :

#Service  httpd   restart


The second step : Extract and install plugins

1- Go to you downloaded nagios tools

 tar  -zxvf   nagios-plugins-1.4.13.tar.gz

2- cd nagios-plugins

./configure --with-nagios-user=nagios --with-nagios-group=nagios

make
make   install

3- Now you have to add nagios to Chkconfig

chkconfig --add nagios

chkconfig nagios on

4- Verify if you have a good config of nagios with the command

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

5- Check if there are no errors displayed; then start nagios with command :

service  nagios  start


To simplify the procesure please disable the selinux and iptables and ip6tables

now open your browser and http://localhost/nagios orr http://ip/nagios

Kishore

Server Security

Iptables to log messages to a different log file

According to man page:

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user defined chains.

By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.
Iptables default log file

For example, if you type the following command, it will display current iptables log from /var/log/messages file:
tail -f /var/log/messages

Output:

————————————————————————–

Oct  4 00:44:28 debian gconfd (anish-4435): Resolved address “xml:readonly:/etc/gconf/gconf.xml.defaults” to a read-only configuration source at position 2
Oct  4 01:14:19 debian kernel: IN=ra0 OUT= MAC=00:17:9a:0a:f6:44:00:08:5c:00:00:01:08:00 SRC=200.142.84.36 DST=192.168.1.2 LEN=60 TOS=0×00 PREC=0×00 TTL=51 ID=18374 DF PROTO=TCP SPT=46040 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0

—————————————————————————–

Procedure to log the iptables messages to a different log file

Open your /etc/syslog.conf file:

vi /etc/syslog.conf

Append following line

kern.warning /var/log/iptables.log

Save and close the file.

Restart the syslogd (Debian / Ubuntu Linux): /etc/init.d/sysklogd restart On the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux: 

/etc/init.d/syslog restart

Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:
DROP everything and Log it
iptables -A INPUT -j LOG –log-level 4
iptables -A INPUT -j DROP

For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:


iptables -A INPUT -s 64.55.11.2 -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ‘** HACKERS **’ –log-level 4
iptables -A INPUT -s 64.55.11.2 -j DROP

Where,

* –log-level 4: Level of logging. The level # 4 is for warning.
* –log-prefix ‘*** TEXT ***’: Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

You can now see all iptables message logged to /var/log/iptables.log file:
tail -f /var/log/iptables.log

  

Securing /tmp and /dev/shm

The first step is to check if /tmp is already secure. Some data centers do not create a /tmp partition while others do.
df -h |grep tmp

If that displays nothing then go below to create a tmp partition. If you do have a tmp partition you need to see if it mounted with noexec.
cat /etc/fstab |grep tmp

If there is a line that includes /tmp and noexec then it is already mounted as non-executable. If not follow the instructions below to create one without having to physically format your disk. Idealy you would make a real partition when the disk was originally formated, that being said I have not had any trouble create a /tmp partition using the following method.

Create a ~1000Mb partition
cd /dev/; dd if=/dev/zero of=tmpMnt bs=1024 count=1000000

Format the partion
mkfs.ext2 /dev/tmpMnt

When it asks about not being a block special device press Y

Make a backup of the old data
cp -Rp /tmp /tmp_backup

Mount the temp filesystem
mount -o loop,noexec,nosuid,rw /dev/tmpMnt /tmp

Set the permissions
chmod 0777 /tmp

Copy the old files back
cp -Rp /tmp_backup/* /tmp/

Once you do that go ahead and restart mysql and make sure it works ok. We do this because mysql places the mysql.sock in /tmp which neeeds to be moved. If not it migth have trouble starting. If it does you can add this line to the bottom of the /etc/fstab to automatically have it mounted:

Open the file in vi:
vi /etc/fstab

Now add this single line at the bottom:
/dev/tmpMnt /tmp ext2 loop,noexec,nosuid,rw 0 0

While we are at it we are going to secure /dev/shm. Look for the mount line for /dev/shm and change it to the following:
none /dev/shm tmpfs noexec,nosuid 0 0

Umount and remount /dev/shm for the changes to take effect.
umount /dev/shm
mount /dev/shm

Next delete the old /var/tmp and create a link to /tmp
rm -rf /var/tmp/

ln -s /tmp/ /var/

If everything still works fine you can go ahead and delete the /tmp_backup directory.
rm -rf /tmp_backup

You /tmp, /var/tmp, and /dev/shm are now mounted in a way that no program can be directly run from these directories. Like I have said in other articles there are still ways in but this is one of the many layers of security you should have on your system.

Nobody Check

==>What is Nobody Check?

Free Nobody Check security tool for cPanel/Pkesk and DirectAdmin based servers that will greatly enhance server security. Developed exclusively by WebHostGear.com

The Nobody Check tool is a new and unique security tool that can detect malicious processes that are running on your Linux server and report them to you in real time or by email. The tool can be configured to run at selected times and doesn’t eat up resources or interfere with server operations.

Installing Nobody Check

Login to your server as root.

This script get installed at /usr/local/

1) Login to your server as the root user through shell

2) wget http://www.webhostgear.com/projects/nobodycheck/install.sh

3) chmod +x install.sh
4) ./install.sh

Wait for the installer to finish

5) rm -f install.sh

6) Open the /usr/local/nobody_check/nc.conf and put in your email address and select your options. Change the to email address to the address you want reports to be sent to.

Check if cron entry below has been updated

vi /var/spool/cron/root

0 */1 * * * /usr/local/nobody_check/nobody_check >/dev/null 2>&1

Example root cronjob runs once per hour

And then restart CRON

/etc/init.d/crond restart

Reports are only sent when a detection is found.

How to disable direct root login

Following steps will show you how to disable direct root login. If you are using cPanel server make sure you add your admin user to the .wheel. group so that you will be able to .su -. to root, otherwise you may lock yourself out of root.

1. SSH into your server as .admin. and gain root access by su

2. Copy and paste this line to edit the file for SSH logins
vi /etc/ssh/sshd_config

3. Find the line
Protocol 2, 1

4. Uncomment it and change it to look like
Protocol 2

5. Next, find the line
PermitRootLogin yes

6. Uncomment it and make it look like PermitRootLogin no

7. Save the file

8. Now you can restart SSH
/etc/rc.d/init.d/sshd restart

Now, no one will be able to login to root with out first loggin in as admin and .su -. to root, and you will be forcing the use of a more secure protocol. Just make sure you remember both passwords!

Linux Environment Security 

Linux Environment Security is intended as a facility to quickly & easily secure RedHat/RPM based environments. It does such by enforcing root-only permissions on system binaries (binaries that have no place being executed by normal users), enforcing root-only path traversal on system paths, enforcing immutable bit on essential rpm package contents (i.e: coreutils), and enforcing immutable bit on shell profile scripts.

The combined usage of all LES options provides an increased level of local environment security, with the goal of preventing environment based attacks. Such attacks would consist of compromised system binaries; tainting the $PATH variable to point to invalid paths where trojan/malicious binaries are located; alterations to user profile scripts to activate key loggers or process based hi-jacking; traversal exploration of the system paths etc…; the possible attack trends are numerious hence the importance of hardening the local environment space.

Installation

wget http://rfxnetworks.com/downloads/les-current.tar.gz
tar -zxvf les-current.tar.gz
cd les-0.*
./install.sh

LES run

/usr/local/sbin/les –secure-bin on
/usr/local/sbin/les –secure-path on

Kishore

Server Monitoring Tools and Commands

Commands to monitor the process.

===> Find Out The Top 10 Memory Consuming Process

ps -auxf | sort -nr -k 4 | head -10

===> Find Out top 10 CPU Consuming Process

 ps -auxf | sort -nr -k 3 | head -10

===> Max cpu resource usage

ps -eo pcpu,pid,user,args | sort -r -k1 | more

===> To get the long list of a process, if we have pid

 ps -efm –columns 2048 | grep

Iostat

The command iostat report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS).

 ...MRTG(Multi Router Traffic Grapher)

  

MRTG (Multi Router Traffic Grapher) is an application that allows us to observe the traffic of a network.

Before Mrtg installation we have to install SNMP on the server.

#yum install net-snmp-utils net-snmp

And we start the server.

# chkconfig –level 345 snmpd

We can see that it is running in port 199.
# service snmpd start


# netstat -natv | grep ‘:199′

tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN

Configuration

We run ‘snmpwalk’ which creates a “tree” of information for our network. If you see an output like this one you may proceed with the MRTG installation. Else you should make some configuration first.
# snmpwalk -v 1 -c public localhost IP-MIB::ipAdEntIfIndex

ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.0.3 = 2

We keep a backup of snmpd.conf just in case anything goes wrong
# cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.original

# nano /etc/snmp/snmpd.conf

And do the follow changes:

* Replace following line

com2sec notConfigUser default public

with those

com2sec local localhost public
com2sec mynetwork 10.0.0.0/8 public

(where 10.0.0.0/8 we put what our network is)

* Replace following line

group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser

with those

group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
group MyROGroup v1 mynetwork
group MyROGroup v2c mynetwork
group MyROGroup usm mynetwork

* find and replace following lines

view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1

with this

view all included .1 80

* find and replace following line

access notConfigGroup “” any noauth exact systemview none none

with those

access MyROGroup “” any noauth exact all none none
access MyRWGroup “” any noauth exact all all none

* and finally replace those lines

syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root (configure /etc/snmp/snmp.local.conf)

with something like this

syslocation Linux, Fedora Core 6
syscontact Root root@localhost

We restart the server to take affect of the notices

# service snmpd restart

And we run again

# snmpwalk -v 1 -c public localhost IP-MIB::ipAdEntIfIndex

Now we should see something like that

IP-MIB::ipAdEntIfIndex.10.103.0.33 = INTEGER: 2
IP-MIB::ipAdEntIfIndex.127.0.0.1 = INTEGER: 1

(Where 10.103.0.33 is your ip address. )

MRTG Installation

# yum install mrtg
# mkdir /var/www/html/mrtg/
( in which our graphs and html pages will be kept)

And next run ‘cfgmaker’ for the configuration file to be created.

# cfgmaker –global “workdir: /var/www/mrtg” -ifref=ip –output /etc/mrtg/mrtg.cfg –global ‘options[_]: growright,bits’ public@localhost

With this command we tell MRTG to create a configuration file with the name ‘mrtg.cfg’ for the traffic of our computer (localhost). Instead of localhost you may put the address of any computer you may monitor as long as it runs SNMP.

Next we create our default index page

# indexmaker –output=/var/www/html/mrtg/index.html /etc/mrtg/mrtg.cfg

Apache configuration

MRTG creates a file ‘mrtg.cfg’ under /etc/httpd/conf.d we contains all the necessary for Apache. We change it to contain the ips we want to have access to our MRTG graphs.

Alias /mrtg /var/www/mrtg


Order deny,allow
Deny from all
Allow from 127.0.0.1 10.0.0.0/8

We run the following command

In case you get an error like this
# mrtg /etc/mrtg/mrtg.cfg

ERROR: Mrtg will most likely not work properly when the environment
variable LANG is set to UTF-8. Please run mrtg in an environment
where this is not the case. Try the following command to start:
env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg
 

You have to run the above command more than once till it runs without any error. This is normal.
# env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg

26-11-2010 17:28:53, Rateup WARNING: /usr/bin/rateup Can’t remove localhost_2.old updating log file

# env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg


Now you can access mrtg at

http://127.0.0.1/mrtg

Options Directive

Using this Options directive controls  we can set server features  for a particular directory.

Options  can be set to None, in which case none of the extra features are enabled.

All :

All options except for MultiViews. (Default Settings).

ExecCGI :

Execution of CGI scripts using mod_cgi is permitted.

FollowSymLinks :

The server will follow symbolic links in this directory.

Includes :

Server-side includes provided by mod_include are permitted.

Indexes :

If the directory does not contain any  DirectoryIndex (e.g., index.html) in that directory, then mod_autoindex will return a formatted listing of the directory.

MultiViews :

Content negotiated “MultiViews” are allowed using mod_negotiation.

You have to be very care full while using + and - symbols with Options

For example, without any + and - symbols:


Options Indexes FollowSymLinks


Options Includes

then only Includes will be set for the /home/sibu/test directory.

If the second Options directive uses the + and - symbols:


Options Indexes FollowSymLinks


Options +Includes -Indexes

then the options FollowSymLinks and Includes are set for the /home/kishore/test directory.

Kishore

TCPTRACK a server monotoring tool

TCPTRACK

Tcptrack provides a packet sniffer that displays TCP connections similarly to ‘top’.
tcptrack is a packet sniffer, which passively watches for connections on a specified network interface, tracks their states, and lists them in a manner similar to the Unix ‘top’ command.

It displays source and destination addresses and ports, connection state, idle time, and bandwidth usage.

 The following screenshot explains a lot:

Installation Steps:

kishore.kb@3wing57:~$ wget   http://www.rhythm.cx/~steve/devel/tcptrack/release/1.4.0/source/tcptrack-1.4.0.tar.gz
 kishore.kb@3wing57:~$ tar -xvzf tcptrack-1.4.0.tar.gz
 kishore.kb@3wing57:~$cd tcptrack-1.4.0
 kishore.kb@3wing57:~/tcptrack-1.4.0$ ./configure
 kishore.kb@3wing57:~/tcptrack-1.4.0$ make
kishore.kb@3wing57:~/tcptrack-1.4.0$ make install

 Some steps are given below to how to use the Tcptrack:

To run tcptrack, you need to specify an interface for it to sniff:

        tcptrack -i eth0

You can also provide a pcap filter expression:
   
        tcptrack -i eth0 src or dst 192.168.33.92 and port 80
       
That will make tcptrack only monitor web connections to or from 192.168.33.92 on eth0. The expression syntax is the same as you'd use for tcpdump and possibly other pcap-based sniffers.
   
While in tcptrack, hit 'q' to exit.

Commands and option:

   tcptrack [ -dfhvp ] [ -r seconds ] -i interface
        [ filter expression ]

       - d     Only track connections that were started after tcp-
              track was started. Do not try  to  detect  existing
              connections.

       -f     Enable  fast  average  recalculation. TCPTrack will
              calculate the  average  speeds  of  connections  by
              using  a  running  average.  TCPTrack will use more
              memory and CPU time, but averages will seem  closer
              to real time and will be updated more than once per
              second and may be more accurate under  heavy  load.
              The  number  of times per second that averages will
              be recalculated in fast mode is a compile-time set-
              ting that defaults to 10 times per second.

       -h     Display command line help

       -i [interface]
              Sniff packets from the specified network interface.

       -p     Do not put the interface being sniffed into promis-
              cuous mode.

       -r [seconds]
              Wait  this  many  seconds  before removing a closed
              connection from the display.  Defaults  to  2  sec-
              onds.  

Kishore

What is an Email and how it works

Email

Email, e-mail or electronic mail is the transmission of messages (emails or email messages) over electronic networks like the internet.

 Email and Postal Mail

To get a grasp of what email is it's best — the terminology indicates it — to think in equivalents of "traditional" postal mail.

* The email message - Instead of using a pen to write a letter on paper, you're using your keyboard to type an email message in an email program on your computer.
   
* Sending the email - When the email is finished and has been addressed to the recipient's email address, you don't put a stamp on it and post it but press the Send button in the email program. This makes the email message go on its journey.
   
* Email transport - Like postal services transport letters and parcel, email servers transmit email messages from sender to recipient. Usually, emails are not delivered to the recipient directly, though, but waiting at the "nearest" mail server to be picked up by them.
   
* Fetching new mail - If you've got new mail in your mailbox, you go and fetch it. Similarly, your email program can check for new email messages at your mail server and download them for you to read.

 How email works

 Email is based around the use of electronic mailboxes. When an email is sent, the message is routed from server to server, all the way to the recipient's email server. More precisely, the message is sent to the mail server tasked with transporting emails (called the MTA, for Mail Transport Agent) to the recipient's MTA. On the Internet, MTAs communicate with one another using the protocol SMTP, and so are logically called SMTP servers (or sometimes outgoing mail servers).

The recipient's MTA then delivers the email to the incoming mail server (called the MDA, for Mail Delivery Agent), which stores the email as it waits for the user to accept it. There are two main protocols used for retrieving email on an MDA:

• POP3 (Post Office Protocol), the older of the two, which is used for retrieving email and, in certain cases, leaving a copy of it on the server.
• IMAP (Internet Message Access Protocol), which is used for coordinating the status of emails (read, deleted, moved) across multiple email clients. With IMAP, a copy of every message is saved on the server, so that this synchronisation task can be completed.

For this reason, incoming mail servers are called POP servers or IMAP servers, depending on which protocol is used. 

 

                                                                                                                                   

To use a real-world analogy, MTAs act as the post office (the sorting area and mail carrier, which handle message transportation), while MDAs act as mailboxes, which store messages (as much as their volume will allow) until the recipients check the box. This means that it is not necessary for recipients to be connected in order for them to be sent email.

To keep everyone from checking other users' emails, MDA is protected by a user name called a login and by a password.

Retrieving mail is done using a software program called an MUA (Mail User Agent).

When the MUA is a program installed on the user's system, it is called an email client (such as Mozilla Thunderbird, Microsoft Outlook, Eudora Mail, Incredimail or Lotus Notes).

When it is a web interface used for interacting with the incoming mail server, it is called webmail. 

Kishore

 

Something about DNS Zone file and Resoursce Records

Zone Files

A zone file is a computer file in ASCII text format that contains all resource records for a given domain.

Below is a copy of a standard zone file containing the information for the Internet domain InetDaemon.com:

inetdaemon.com.  IN SOA  ns1.hostsave.com. contact.hostsave.com. (
               2001121123 ; serial
                  102000  ; refres
                  108000  ; retry
                  102000  ; expiry
                    3600 ); minimum


inetdaemon.com.     IN NS   1.hostsave.com.
inetdaemon.com.     IN NS   2.hostsave.com.
inetdaemon.com.     IN NS   3.hostsave.com.
inetdaemon.com.     IN A    207.150.192.12
inetdaemon.com.     IN MX   20 mail.hostsave.com.
inetdaemon.com.     IN MX   1 mail-incoming.hostsave.com.
inetdaemon.com.     IN MX  10 mail-incoming2.hostsave.com.

Resource Records

Nameservers contain zone files (database files for domains). Zone files contain resource records. Resource records describe specific network resources that are available. The ability to use names for resources such as e-mail exchangers, nameservers and web servers are configured within zone files using resource records.

SPECIAL Resource Record Types

Start of Authority (SOA) and Nameserver (NS) records are special because they must be included in every database zone file. Most DNS systems do not make distinctions between forward and reverse zones, the resolution process works the same.

The only difference between forward and reverse resolution is the files the DNS nameserver uses to find the answers to queries and the records inside those zone files.

    * Start Of Authority (SOA)
    * Nameserver (NS)

FORWARD Lookup Resource RECORDs

The following resource record types are used in zone files configured to provide forward resolution (name to IP address translation) of domains and host names.

    * Address (A)
    * Nameserver (NS)
    * Mail Exchanger (MX)
    * Canonical Name (CNAME)
    * Reverse Lookup Resource RECORDs


1.Start Of Authority (SOA)

The Start Of Authority (SOA) record is a special resource record included in every database file (also called zone files). The SOA record supplies certain basic information about the zone. An SOA record is included in both forward and reverse zone files.

 zippo.net. IN SOA apollo.zippo.net. james.zippo.net.
            1999102003 ; Serial Number
                 14400 ; Refresh every 4 hours
                  3600 ; Retry in 1 hour
                604800 ; Expire in 1 week
                 86400 ; Minimum TTL of 1 day

The above Start Of Authority (SOA) resource record identifies that our nameserver 'apollo' is the primary authoritative server for this domain, and that james@zippo.net is the e-mail address of the DNS Administrator for the domain. The settings in the SOA resource record affect solely nameservers that query the authoritative nameserver for domain or hostname information.

The SOA resource record should be followed by one nameserver resource record for each nameserver that is authoritative for that domain, which in turn should be followed by Address resource records defining the IP addresses of the nameservers.

A properly configured zone file with matching Start of Authority, nameserver and Address resource records will look something like this:

 zippo.net. IN SOA apollo.zippo.net. james.zippo.net.
            1999102003 ; Serial Number
                 14400 ; Refresh every 4 hours
                  3600 ; Retry in 1 hour
                604800 ; Expire in 1 week
                 86400 ; Minimum TTL of 1 day
;
; Primary Nameserver
zippo.net.        IN    NS    apollo.zippo.net.
;
; Secondary Nameserver
zippo.net.        IN    NS    hermes.zippo.net.
;
; Address Records for the Nameservers
apollo.zippo.net.    IN    A    199.144.219.10
hermes.zippo.net.    IN    A    199.144.218.10

According to the SOA resource record above, the secondary authoritative nameserver (lets call it "Hermes") will attempt to get a copy of the zone file from the primary authoritative nameserver every four hours and the secondary nameserver will try again once an hour until it can successfully retrieve the db.zippo.com zone file. If Hermes is unable to retreive the domain after 1 day, it will no longer provide the answers contained in this zone, but Hermes will still have the information in it's cache. If, after 1 week, Hermes is still unable to reach the primary authoritative nameserver to download the zone, it will delete the zone file information from cache.

Note that host names are completely up to the administrator. It is not necessary to name a host according to it's function to get name resolution to work, nor must the host name configured on the host itself match the name in DNS. (ie. it is not necessary to call a nameserver ns.domain.com, or a mail server mail.domain.com). Host names are usually completely arbitrary, but for sanity's sake, administrators usually make sure that the names configured on hosts and the names in DNS match.

Also note that the ';' character is used within a zone file to indicate comments and are ignored by the DNS software.

Serial Number

The serial number is used to indicate which copy of the zone file is the most current. If the Primary nameserver's serial number is less than or equal to the secondary nameserver's serial number, no transfer of the zone file from the primary authoritative nameserver to the secondary authoritative nameserver will take place. It is common to use a date/version format for the serial number such as YYYYMMDDVV for Year Month Day and Version. In the example above, the file was modified the 20th of October, 1999, and this is the third version of the file produced that day. When editing zone files, you must increment the serial number by one make sure the secondary authoritative nameserver performs an update.

Refresh

The refresh value determines the interval between successful zone transfers of the entire zone file from the primary nameserver to the Secondary nameservers. The number indicates the number of seconds betwen refresh attempts.

Retry

If a zone transfer to refresh the zone file data fails, it will wait the designated number of seconds listed in the retry field to perform additional attempts to load the zone file. More than one attempt an hour is considered poor netiquette if someone else is providing secondary DNS for your domain as this creates extra queries to the nameserver and extra load.

Expire

When a zone transfer fails, a countdown clock begins. When the number of seconds set in the expire field elapses, the nameserver stops answering for that zone file. It is assumed that if the secondary nameserver cannot get the information from primary authoritative nameserver in this period of time, the data is incorrect or out of date.

Minimum TTL

The Minimum Time to Live is the number of seconds an external caching nameserver should keep any responses from the nameserver (apollo in our example). If ns.berkeley.edu queried our apollo.zippo.net nameserver, ns.berkeley.edu would delete the answer after holding it in it's cache for 1 day.


2.Adress Records (A)

When you use the Internet, you really aren't using the names of websites or computers, you're using IP addresses, but since most computers use DNS, you can use a website name and DNS takes care of finding the IP address for you. Address Resource Records are placed in a zone file stored on an authoritative nameserver so that when the nameserver is queried with a hostname, it can answer with the correct IP address.

Address resource records provide the base hostname to IP Address resolution service provided by a DNS nameserver. An Internet Address record is configured the same way for all hosts; however, additional records may be necessary if the host being resolved provides additional services such as DNS or E-mail.


Web Servers

   zippo.net.     IN A 198.204.18.190
   www.zippo.net. IN A 198.204.18.190

The example above allows both http://zippo.net and http://www.zippo.net to resolve to the same IP address. Most people, including most web hosting providers, forget to set this up. This makes accessing a web page easier on your customers. This can be accomplished another way using a CNAME record, but isn't necessary.

User's Workstation or Standalone Server

   zorba.zippo.net.    IN    A    198.204.18.131

Every computer that should be reachable from the Internet must have an Address record. Networks that are not directly part of the Internet also need DNS resolution if you want to use the computer's name instead of it's IP address to connect to it.

The Address resource record places the fully qualified domain name of the host on the left and the IP address on the right.


DNS Name Servers

   zippo.net.         IN    NS    ns1.zippo.net.
   ns1.zippo.net.     IN    A    198.204.18.131

DNS nameservers require an additional NS record. Note that if you have additional nameservers that aren't part of your domain, you do not use an A record for them in your zone file for your domain.
  
3.Mail Exchanger (MX)

Basic Mail Exchanger Setup

Mail exchanger records consist of a domain on the left hand side, a preference number and a fully qualiied host name on the right hand side. They look something like this:

  zippo.net.          IN   MX  10 mercury.zippo.net.
  mercury.zippo.net.  IN   A   198.204.18.5

MX DOMAIN

The domain should be the domain the mail exchanger serves and should be fully qualified if it appears. In the example above, the domain zippo.com. (note the trailing dot) is the domain. Note the trailing dot after the domain. This is important as the server will add the local domain the zone file was written for if the dot does not appear at the end.
MX PREFERENCE Value

The MX record preference values indicate which mail server to use and in which order to try them when they fail or don't respond. A larger preference number is less preferred. Thus, a mail exchanger with a preference of zero (0) is always preferred over all other mail exchangers. Setting preference values to equal numbers makes mail servers equally preferred.

A mail exchanger is a server configured to processing SMTP messages (E-MAIL!). The users of zippo.net would have 'username@zippo.net' as their e-mail address. The mail still has to be delivered to a specific machine, so you must tie the domain name (zippo.com) to a mail machine. In our example we used the name 'mercury' for the mail server, but we could have used ANY legal DNS host name. After we tie the domain name to the name of a specific machine (mail.zippo.com) we still have to get the IP address for 'mail'. The IP address information is provided by the IP address.
MAIL DELIVERY

Mail will be delivered to the machine with the lowest preference value that is available and responding. If that machine's fully qualified domain name is not the same as the domain that lists it as a mail server, it will look up the domain and try to deliver the mail to the next 'closest' mail server, a server with a smaller preference number (smaller preference numbers indicate the server is more preferred).
Configuring a Backup Mail Exchanger

For example, if we configure the zone like so:

  zippo.net.         IN MX 10 mercury.zippo.net.
  zippo.net.         IN MX 20 venus.zippo.net.
  mercury.zippo.net. IN A  198.204.18.5
  venus.zippo.net.   IN A  198.204.18.6

Mail will attempt delivery to mercury first, but if mercury can't be reached, then it tries venus.
Load Balancing on Mail Exchangers

Since DNS resolution works in a round robin fashion, you can uses maill servers with identical preferences to create a load balancing situation between mail servers. Take the following example:

   zippo.net.         IN MX 10 mercury.zippo.net.
   zippo.net.         IN MX 10 venus.zippo.net.
   mercury.zippo.net. IN A  198.204.18.5
   venus.zippo.net.   IN A  198.204.18.6

Mail for the zippo.net domain will get delivered to mercury, then venus and then mercury again.

Using CNAMES with MX records can cause problems, including making your zone fail to load. Check out the section on CNAMEs for more info.
Using Your ISP as a Secondary Mail Server

If your ISP supports it, you can add an MX record for your domain that points to your ISP's mail servers. If your mail server is unavailable, mail will be queued at your provider's mail server until such time as your server returns to service. Most mail servers hold onto mail and retry delivery if they fail. Adding your ISP can increase this buffering time as the sender buffers the mail, then forwards to your ISP who buffers the mail for a time before the mail finally times out and dies. You set up your ISP as a secondary MX only after consulting with them and finding out whether they allow and support such services.

   zippo.net.         IN MX 10 mercury.zippo.net.
   zippo.net.         IN MX 10 venus.zippo.net.
   zippo.net.         IN MX 30 mail.isp.net.
   mercury.zippo.net. IN A  198.204.18.5
   venus.zippo.net.   IN A  198.204.18.6

Note that in the examle above, the ISP's IP address is NOT listed in the zone file for the zippo domain. That's because the ISP will take care of the DNS resolution for their mail server because it is in their DNS domain. Also note that the MX record pointing to the ISP's mail server has the largest preference number. This makes sure that the ISP's mail server will only be used if none of the other servers are available. If the ISP's mail server had the higher preference, you may end up with a mail loop.
ANTI-SPAM:  REVERSE LOOKUP OF MAIL EXCHANGERS

The most used application on the planet for sending SMTP is sendmail. This application checks both the sender's and receiver's addresses in both the mail headers and the envelope. To block spammers, many companies use reverse resolution to verify that the host that is sending the mail is indeed who it says it is. This blocks some of the SPAM, but not all of it. If you don't want to find yourself unable to send mail to an ever growing number of sites, it's a good idea to make sure your mail exchanger is properly configured in the correct reverse zone file. Often, this will require your ISP to set up the DNS for this as the zone file for a range of IP addresses resides with the owner of the IP's themselves.


 4.Canonical Name (CNAME) Resource Records

Canonical Name (CNAME) records function as aliases. zippo.com could be aliased to www.zippo.com using a CNAME. CNAMEs allow you to alias one host name to another, however, the host that you are aliasing to MUST have an A record. You cannot define an alias using another alias that does not eventually point to an address. Let's take an example of setting up a web server:

   zippo.net.     IN CNAME   www.zippo.net.
   www.zippo.net. IN A       198.204.18.190

I cannot stress this next point enough:

WARNING!! USING CNAMES WITH MX RECORDS IS HAZARDOUS TO YOUR DOMAIN'S HEALTH! IF YOU ARE READING THESE PAGES FOR REFERENCE YOU SHOULDN'T BE USING CNAMES!!

The fastest way to get yourself fired from your job if you're new to DNS is to use CNAMES with MX records to point multiple mail exchanger records to one host name using CNAMEs. You CANNOT CNAME a host named in an MX record to something else. This will BREAK the mail service, AND prevent the zone from loading causing ALL DNS TO FAIL FOR ALL HOSTS INCLUDING YOUR WEB SERVER!!! Your e-mail will break, your website will break, your FTP server will break and anything else that is in that zone file will stop working because noone will be able to find the IP addresses of those devices.

If you're running true Microsoft Active Directory (no WINS), users won't even be able to log in unless they are on Windows XP or 2000 clients and the default login policy hasn't been altered to prevent login when the domain controller can't be reached.

As we said before: CNAME records are hazardous for inexperienced DNS administrators.


 5.Reverse Lookup Resource RECORDs

The reverse zone has only three types of records, PTR, NS and SOA. Reverse zones allow DNS nameservers to turn IP addresses into fully qualified domain names (FQDN). Why is reverse resolution important and why do we need to set it up?

With the growth of SPAMHAUSES (places that send out unsolicited bulk commercial e-mail) it is easier to translate the IP address back into a domain name and block the domain name than to block the individual IP addresses of the spammer's e-mail servers. Some mail servers automatically block mail received from hosts they cannot reverse resolve, assuming it is an attack or junk mail.

Another use is for the authorization to download software with encryption capabilities. If the IP address of the host contacting the dowload server can be reverse resolved to a host in a domain that is registered inside the continental United States, then the download can be permitted.

When performing reverse  lookup, a specific resource record type is used:

    * Pointer (PTR)



Pointer (PTR) Resource Records

Pointer records (PTR) look like this:

   190.18.204.198   IN   PTR   www.zippo.net.
   1.18.204.198     IN   PTR   cerebrus.zippo.net.

Note that we are trying to resolve 198.204.18.190 back to www.zippo.net. PTR records list the IP addresses in reverse order, from most specific to least specific, just as names are done. When you think about it, it makes sense. The most specific part of a fully qualified host name is on the left as is the most specific part of the IP address if you turn it around. In the fully qualified host name www.zippo.net, the host name www is the most specific part, and it's on the left. In the IP address 198.204.18.190, 190 is the most specific part but it's on the RIGHT, so we have to reverse the order of the octets to put it on the left. This way the software which does forward resolution can do reverse resolution the same way. Have a look at reverse resolution if you haven't done so already.

Kishore

DNS Server Functions

The DNS server functions are mainly four types. Those are given below:

1. Resolution which is having three types
     a.Forward
     b.Reverse (in-addr.arpa)
     c.Round Robin
2.Delegation
3.Caching
4.Zone Transfers

Resolution

Resolution is the process of turning a name into an IP address or an IP address back into a name. The process begins with asking the root servers which nameserver to ask about the domain name that is being resolved. The root nameservers will refer you to another name server which will refer you to another name server and so on. Finally you will be refered to the nameserver which is authoritative for the domain name. The authoritative server will look in its zone files and respond with an answer.

DELEGATION

Delegation is the process of distributing the responsibility for resolving names or IP addresses across multiple DNS servers maintained by different organizations. The delegation process is how DNS names, domain names, are resolved.

FORWARD vs. REVERSE

When the process turns a name into an IP address, it is referred to as forward resolution. When an IP address is resolved back into a name the process is called reverse resolution.
RESOLUTION

 a.FORWARD RESOLUTION

The Domain Name System (DNS) is designed to resolve host names into IP addresses. The process of resolving names into IP addresses is called 'forward resolution'. The DNS tree is organized into an upside down tree structure with the least specific portions of the address at the top, and the most specific part of the address at the bottom.

Step by step, here is how this address is resolved (refer to the diagram above when needed):

   1. A user on another network types in eos.cs.berkeley.edu on his local machine.
   2. The Resolver built into the application he is using sends out a 'recursive resolution request' to the local DNS server.
   3. The Local DNS server checks it's own database. If it finds an answer, it responds with the IP address.
   4. If it does not find an answer in it's own database, it queries the Root DNS servers (currently at InterNIC).
   5. The Root DNS server checks it's database and finds the names and addresses of the nameservers at Berkeley.
   6. The Root DNS server sends back the names/addresses of all the Berkeley nameservers it has in its databse as a 'delegated referral'.
   7. The local DNS server randomly picks a Berkeley nameserver and queries it. This random choice spreads out the load of successive requests across several machines.
   8. The Berkeley nameserver queried checks it's database and finds it has delegated the cs.berkeley.edu domain to a nameserver on the Computer Science network.
   9. The Berekeley.edu DNS server sends back the names/addresses of all the cs.berkeley.edu nameservers it has in its databse as a 'delegated referral'.
  10. The user's local DNS server randomly chooses one of the cs.berkeley.edu servers and then queries that nameserver for the host 'eos'.
  11. The cs.berkeley.edu nameserver responds with an authoritative answer for the IP address of EOS.
  12. The local user's machine now opens a TCP connection to the IP address of the machine EOS.

This resolution process can take up to two minutes, but it distributes the load of resolution across several machines, and allows local network administrators to have direct control over the resolution responses for their network.

 b.REVERSE RESOLUTION

Reverse Records (in-addr.arpa)

There are circumstances where it is necessary to translate an IP address back into the name of the device. This is especially useful in the traceroute application allowing the user to see the names of the machines through which packets are flowing instead of raw (and unrecognizable) IP addresses.

Reverse DNS resolution is performed the same way forward resolution is performed, except that the IP addresses and names are in opposite places. You can think of the computer storing everything in an upside-down tree-like structure with the top level domain at the top and the second and third level domains underneath it. For forward host name such as www.netscape.com, the .com is at the top, just under that is the .netscape part, and below that is the www part. Where the nameserver stores the www is also where it stores the IP address.

Reverse resolution is handled by placing it as a special branch off the root called .in-addr.arpa. This special branch allows for reverse resolution by placing names at the nodes corresponding with the IP address that is being resolved.

When looking up the IP address 192.234.42.5 the request is reformatted by the local resolver and sent to the nameserver as 5.42.234.192.in-addr.arpa. This looks like it's backwards, but if you look at the picture of the tree structure above, you can see that the name server stores the information in least-specific to most specific order. Resolution actually works better that way because the resolver begins with the least specific part of any name or address (.com in a name, and .in-addr.arpa in an IP address lookup) and works it's way to the most specific part (the www part of www.company.com in a name, and .5 of 192.234.42.5. What screws most people up is not knowing that IP addresses are actually backwards to start with. We're just putting them in the correct order when we do the lookup.   ;-)

    www . company . com
    <== most  specific  least ==>

    192  .  234  .  42  .  5
    <== least specific   most ==>

    5 . 42 . 234 . 192 . in-addr . arpa
    <== most  specific   least ==>

By the way, the 'in-addr' part simply means 'inverse address', and 'arpa' stands for ARPANET, which just goes to show you how old this process really is if you know what the ARPAnet is...

This 'backwards' way of representing things makes it possible for the programmers to be lazy and not have to write special logic or code to do reverse resolution. It's a strange workaround to the problem, but it works better because it uses the same steps as forward resolution would, and follows the same rules. This makes it's behavior predictable and logical because it doesn't differ greatly from forward lookups of domain names.


 c.ROUND ROBIN DNS

The Berkeley Internet Name Daemon (BIND) has a function built in called round-robin resolution. The standard domain name resolution process starts when a client which makes a request to a resolver. It is the resolver's job to discover the best sources for DNS information and to choose the best and closest sources for information. Closeness is defined as being within the domain or one of the sub-domains that are members of the domain. A server whose fully qualified name is part of the domain will be preferred over a server which is not. When more than one record of a specific type exists, the BIND software will rotate the answers it provides. This provides load sharing functionality so that answers requested will come from different servers.

When requesting information from a DNS server it will provide a list of servers. If you immediately query the server a second time, the order of the servers listed will change. Not all servers perform the round robin DNS functionality, though Microsoft claims to support it by default.

FIRST QUERY

Note the order of the names of the nameservers is listed as ns1, ns2, ns3, ns4. That they are listed in alphabetical order is a coincidence in this query. The point is to look at the results from the second and third queries.

C:\Documents and Settings\johnp>nslookup
...
> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10

> set norecurse
> set q=ns
> google.com.
Server: nameserver.inetdaemon.com
Address: 10.0.10.1

Non-authoritative answer:
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
google.com nameserver = ns3.google.com
google.com nameserver = ns4.google.com
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10

 SECOND QUERY

Notice that the order of the names of the nameservers listed has changed: ns3, ns4, ns1, ns2. What has happened is that at least one other query from someone else on the Internet was run since we ran our first query. Round robin would have handed us ns4, ns1, ns2, ns3.

> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10

google.com nameserver = ns3.google.com
google.com nameserver = ns4.google.com
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10

THIRD QUERY

Notice that the order of the names of the nameservers listed has changed again: ns4, ns1, ns2, ns3.

> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10

google.com nameserver = ns4.google.com
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
google.com nameserver = ns3.google.com
ns4.google.com internet address = 216.239.38.10
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
>
 
SUMMARY

Note that the order of the servers listed changed between queries. As long as there are multiple resource records of the same type, the DNS server should rotate the answers listed. This rotation is referred to as round-robin. This rotation is completely deterministic, which means it does not rotate the list of servers based on load or the number of queries, but rather rotates the list the same way on every single query.

 DELEGATION

Domain name resolution begins with a query to the Root Domain Servers (a.root-servers.net, b.root-servers.net etc.). To decrease the load on the root servers, two techniques were developed. The first was delegation, the second, caching.

Delegation is the process of referring DNS resolution requests to the Authoritative Server. For instance, InterNIC delegates berkeley.edu to the nameservers at the University of California at Berkeley. More properly, InterNIC delegates authority over the berkeley.edu domain to the University.

CACHING

Name servers and client resolvers store answers they get from other name servers. This information is added to their an internal database called the cache.  Information about hosts is etained for a period of time equal to the time to live value sent by authoritative name server when it returned an answer about a particular host. The cache can contain both authoritative and non-authoritative information, depending on where the answer to the query for that particular host was provided from.

Storing these responses is called caching and allows a nameserver to respond more quickly to multiple queries for the same domain or host. If you are on a website, and want to retrieve the next page on the site, you click a link. Your web browser takes the name of the server, sends it to the the local name server to be turned into an IP address. Once your computer gets an answer, it does not have to look up the host again. Your local computer actually has its own DNS cache as well. Provided the time to live value hasn't expired, that answer will remain in the cache for some time. Once the time to live decays to zero the nameserver will delete the entries containing the host and address information. On your local computer, the cache is emptied when the local computer's default timeout is reached. This is an arbitrary value and is set to approximately 5 minutes on most Windows computers.

ZONE TRANSFER

A standard DNS architecture will have a primary authoritative server that the DNS administrator configures with domain information in one or more zone files. This primary server will be registered with the domain registrar. This information should of course be backed up on a secondary (slave) server. Once the zone files download succesfully, the secondary server should respond authoritatively if queried. This provides fault tolerance, as well as load balancing of DNS resolution requests.

All that is necessary to configure on the secondary server is a list of domains for which the secondary is to be authoritative. This is done by configuring a list of zone file on the secondary server. When a secondary server is started it downloads these files from the primary DNS server. The secondary server is totally reliant upon the primary server. If the information is not on the primary server, it will never appear on the secondary.

A secondary server performs a 'zone transfer' to download zones from the primary server. When the expire time in the Start of Authority (SOA) resource record decays to zero the secondary server opens a TCP connection on port 53 to a primary server to download the zone file. The server will permit or deny the transfer request depending upon its configuration. This allows the secondary server to mimic the primary, and to contain a backup copy of all DNS information configured in various zone files on the Primary server.

The secondary server will not transfer (download) any zone that contains an error or unrecognized record types (such as WINS records, or records containing the underscore character). The secondary server will not transfer any zone that is not properly configured and does not list the secondary DNS server in the SOA record and where no name server (NS) record for the server doesn't exist.

BIND 8.0 and later contains an additional feature called dynamic update. Normally a zone transfer is initiated by the secondary server after refresh time set in the zone's SOA record has expired. A primary server running BIND 8.0 and later will send out a notification to all its configured secondary DNS servers whenever its zone files are modified and the version number has increased. This allows for faster updates between the secondary servers and the primary server.

Kishore

DNS Servers

DNS Server Types 

1.Authoritative
      a.Master
      b.Slave
2. Non-Authoritative
3. Caching / Recursive Servers
4. Iterative Servers



1.Authoritative Servers

DNS Servers can be configured to host more than one domain. A server can be primary for one domain, and secondary for another. The term authoritative refers to any DNS servers that has a complete copy of the domain's information, whether it was entered by an administrator or transferred from a primary server. Thus, a secondary server can and should be authoritative for any domain for which it performs secondary authoritative resolution.
What is Authority?

Any DNS server that contains a complete copy of the domain's zone file is considered to be authoritative for that domain only. A complete copy of a zone file must have:

    * A valid Start of Authority (SOA) record
    * Valid Name Server (NS) records for the domain
    * The listed NS records should match the servers listed in the SOA record. Servers listed in the zone file, but not in the SOA record are called lame servers.

It is considered standard practice to have a primary authoritative DNS server AND a secondary authoritative DNS server. When registering your domain with an accredited domain name registrar, the primary authoritative DNS server is the server you list first, all other DNS servers you list will be secondary. The secondary server and the primary server should be on different IP subnets and the hardware should be located in different physical locations. By putting the two DNS servers on different subnets and placing them geographically apart, you greatly reduce the risk that a single catastrophe will take down the entire system of DNS servers for your domain. Having more than one secondary DNS server for your domain is also good practice, but you can only designate ONE primary DNS server with your registrar because DNS can only point to a single primary DNS server for your domain.
Authoritative Responses

Any response to a DNS query that originates from a DNS server with a complete copy of the zone file is said to be an 'authoritative response'. What complicates matters is that DNS servers cache the answers they receive. If a DNS server has an SOA record, it fills in a field in the response that signals that the server queried is authoritative for the domain and that the answer is authoritative. Any DNS server external to that domain that retrieved the authoritative response will cache that answer. The next time the server is queried, it will say that the answer it is giving is authoritative, even though it is not authoritative for that domain.

In other words, it IS possible for a DNS server that is NOT an authoritative server for a domain to give an 'authoritative response' to a DNS query for a domain it does not serve.

Non-authoritative responses come from DNS servers that have cached an answer for a given host, but received that information from a server that is not authoritative for the domain.

 Master DNS Server

A Master DNS server contains the following:

   1. A complete copy of zone files for the domain which the master server is authoritative. These files are created by the local DNS administrator.
   2. Each zone file contains an SOA record which lists the Master and Slave DNS servers (in that order)
   3. The primary and secondary are the first two name server (NS) resource records in the zone file.
   4. A complete copy of all information for all hosts in the DNS domain. This list of hosts is contained within the zone file. Slave servers download copies of the domain information on a regular basis. The domain information on a master server is manually entered by an administrator.

Master servers are often called primary servers.

Slave DNS Server


A slave DNS server transfers zone files for which it is authoritative from the master server.

2. Non-Authoritative DNS Servers

Non authoritative servers do not contain copies of any domains. Instead they have a cache file that is constructed from all the DNS lookups it has performed in the past for which it has gotten an authoritative response. When a non-authoritative server queries an authoritative server and receives an authoritative answer, it passes that answer along to the querier as an authoritative answer. Thus, non-authoritative servers can answer authoritatively for a given resolution request. However, non-authoritative servers are not authoritative for any domain they do not contain specific zone files for. Most often, a non-authoritative server answers with a previous lookup from its lookup cache. Any answer retrieved from the cache of any server is deemed non-authoritative because it did not come from an authoritative server.

NON-AUTHORITATIVE DNS RESPONSES

DNS servers cache responses so that if another local user requests the same host or IP address from the local nameserver, the answer will already be in the local nameserver's DNS database. The server will not have to go outside the network to resolve that same host again.

 3.THE CACHING FUNCTION

Caching

As mentioned elsewhere in this tutorial, name servers and client resolvers store answers they get from other name servers. This information is added to their an internal database called the cache. Information about hosts is etained for a period of time equal to the time to live value sent by authoritative name server when it returned an answer about a particular host. The cache can contain both authoritative and non-authoritative information, depending on where the answer to the query for that particular host was provided from.

Storing these responses is called caching and allows a nameserver to respond more quickly to multiple queries for the same domain or host. If you are on a website, and want to retrieve the next page on the site, you click a link. Your web browser takes the name of the server, sends it to the the local name server to be turned into an IP address. Once your computer gets an answer, it does not have to look up the host again. Your local computer actually has its own DNS cache as well. Provided the time to live value hasn't expired, that answer will remain in the cache for some time. Once the time to live decays to zero the nameserver will delete the entries containing the host and address information. On your local computer, the cache is emptied when the local computer's default timeout is reached. This is an arbitrary value and is set to approximately 5 minutes on most Windows computers.

Caching is why it takes longer to contact a website on the first try but subsequent requests for pages on the same site are somewhat faster.
Negative Caching

The DNS application BIND version 4.9.3 and later supports negative caching as well (You'd better be on the latest version of BIND if you don't want to get hacked. --InetD). If the local server queries an authoritative server for information and receives an answer indicating that there is no such host, the local DNS server or resolver stores this answer as well, as there is no reason to look up this host twice if it does not exist. The host being down will not cause this response, but not having ANY record of it in the authoritative DNS server's database will cause this.
DNS Server Reloads

To flush the cache in BIND, you issue the following command:

# rndc flush

Why would you want to clear the name server cache file? Unfortunately caching is a two-edged sword. It speeds up resolution by storing recent answers, and short-circuiting the normal resolution process. However there is a down side. Because DNS servers cache answers, and don't delete these answers until the time to live expires, it can take hours, days or even weeks for the entire Internet to recognize changes to DNS information within your zone. In most cases, it is NOT possible to clear the nameserver's cache without shutting down the nameserver and restarting it. Since the server cannot resolve IPs or names while it is shut down, this effectively shuts down Internet communication for most users. This is usually not something a DNS administrator at a major ISP is willing to do without good cause. It is rare in the extreme to see major Tier 1 providers restart their DNS servers for any reason other than their own scheduled reload as this can prematurely reset version numbers, time to live and many other settings that will ripple through the Internet and cause other major headaches. If you ever find your job depends on getting them to restart their servers at anything other than their usual scheduled times, you'd better start looking for a new job. A restart of their servers means an outage for hundreds of thousands of companies and millions of users.
Clearing Your Resolver's Cache

The process differs depending upon which operating system you are using.

Windows

Windows provides the means to dump your local resolver cache. If you suspect your computer has stored a negative answer "host/domain not found" for some reason, then you can issue the following DOS command to clear your resolver's cache:

c:\ipconfig /flushdns

Mac OS & older BSD

Mac OS X and later uses 'lookupd'--a binary that provides diretory information and name caching functions. This function may require root privledges to run, which is dependent upon your local security configuration.

shell$ lookupd -flushcache

Linux

The client resolver is called 'nscd' (name service cache daemon). To wipe the cache, restart the daemon service with the following command:

/etc/rc.d/init.d/nscd restart

BSD

Some BSD systems don't come with resolver/caching software and simply use BIND. Be careful when issuing the flush command listed above.


4.Iterative Resolution

Resolvers in client software such as a web browser, are not designed to hunt down answers about hosts and domains on their own. They rely on the local DNS server to do this for them. For this systemof having client software relying on a DNS server to work, a recursive DNS server must be available for these clients.

An Iterative DNS query results in a single DNS server being queried, and only getting a single response. If the DNS server has the answer, it sends it. If not it sends a "host/domain not found" error message, but the DNS server does not do any additional resolution. It does not query any other DNS servers.

Because recursive lookup takes the DNS server longer and requires more memory to store records, it sometimes is more efficient to separate the DNS services for external (Internet) users from the internal (LAN) users. To do this, a recursive DNS server is provided for the internal users, and a non-recursive or 'iterative' server is provided for Internet users to enable them to resolve ONLY your domain.

A Domain Name Server which provides for iterative lookup performs resolution using the information within it's own lookup tables. It does not query other name servers for information. When a client request is sent to the server, it searches it's local database, and if it has an answer, it will reply. If it does not have an answer, it will respond with a 'host not found' message.

Iterative servers are useful when you wish to provide resolution for your own zone, and only your zone. All users pointed at this server to fail to resolve anything not entered on the DNS server. This restricts the nameserver to responding for only information stored on it, and thus is useless for resolving anything else. This decreases the usefulness of the

Kishore

DNS (Domain Name Service)

DOMAIN NAME SERVICE

The Domain Name Service (DNS) protocol provides a distributed name resolution service. We need DNS because we humans have trouble remembering the numerical IP addresses of computers, so we let the computers running Domain Name Service perform the name lookup, changing a computer's name into the IP addressees computers need to communicate. Domain Name Service (DNS) is the mechanism used to translate the name of a computer into computer's IP address. DNS is provided by a special computer (a server) running DNS software such as Berkeley's Internet Name Daemon (BIND), Microsoft DNS or another DNS server application. Using DNS your web browser can translate an Internet domain name such as www.inetdaemon.com, into an IP address where the website is located. DNS servers provide this translation by performing a 'lookup'. When they lookup a name and return an address, it is referred to as forward DNS lookup. Domain Name Service can also translate IP addresses into domain names which is called reverse DNS lookup.

DOMAIN NAMES

A Domain includes all devices that fall under a particular part of the Domain Name System hierarchy. For instance, the domain name inetdaemon.com would be used for all computer names that belong to InetDaemon. Basically, a domain name is used as the identifier for a group of computers that as far as DNS are concerned are all part of the same group.

The IP address for eos.cs.berkeley.edu. would be stored at the eos node.

Domain Names as supported in the Domain Name System must be less than 63 characters in total length, begin and end with a printable character, and can contain only letters, numbers and the hyphen character (the hyphen '-' must be in the middle somewhere). Underscores are not valid.

FULLY QUALIFIED DOMAIN NAMES (FQDN)

Fully qualified domain names (FQDNs) are names that have been spelled out all the way to the root of the DNS hierarchy. Using the example DNS hierarchy diagram above, the true, fully qualified domain name for the host eos would be eos.cs.berkeley.edu. (note the trailing dot after the edu in the name). Most DNS resolvers are smart enough not to need the last dot and it is assumed to be there; however, when troubleshooting domain name service issues with applications such as nslookup, its a good idea to use the period at the end.


The domain can be divided into :
1. Top Level Domains
       --Country Code Top Level Domains (ccTLD's)
2. Second Level
3. Sub-Domains

1.Top Level Domains

Top Level Domains are the very top level of the DNS hierarchy. Sub-domains are installed under each of these. There are servers responsible for the root level resolution of various domains. These top-level domains are the first step in resolution and can be divided up into categories:

COUNTRY CODE DOMAINS ( ccTLDs)

* .ca (Canada)
* .fr (France)
* .it (Italy)
* .gr (Germany)
* .us (United States)
* .tw (Taiwan)

Of course, these are not the only top level country code domains (cc-tld's). Also, in many countries, they use smimilar sub-domain patterns as follows:

* .net.tw
* .com.tw

US RESTRICTED TOP LEVEL DOMAINS

These domains are restricted to certain specific organizations and may not be used by any other entites. The .gov TLD is restricted to the United States Government. The .mil TLD is restricted to various branches of the United States Armed Forces. The last is the .edu organization, which, while not as restricted as .gov and .mil, still requires proof of accreditation as an educational organization to obtain a registration as part of the .edu TLD.

* .gov - US Government
* .mil - US Militiary
* .edu - United States educational organizations

US PUBLIC TOP LEVEL DOMAINS

These are the well-known and popular domain names everyone in the United States knows and loves. (gee... I own one myself -- InetD)
The following are the original domains:

* .com
* .edu
* .net
* .org

The following domains were added to the DNS system and are supported by the InterNIC as of November 2001:

* .aero
* .biz
* .coop
* .info
* .name
* .museum
* .ps


DOMAIN NAME DISPUTES

Well, if you want to register your company's trademarked name as a domain name and someone else already owns it, you can file a claim to get it even if someone wants 42 bajillion dollars for it. Good luck though. Getting your domain free from the sqatters is like pulling eyeteeth and a hell of a lot more painful.

* Domain Disputes

INTERNIC ROOT ZONE FILE

A copy of the root zone file for all top level domains can be downloaded from the InterNIC:

* ftp://rs.internic.net/domain/root.zone.gz

2. Second Level Domains

Speaking in a very general sense, second level domains belong to the organization who registered them, and are therefore their responsibility to resolve. Using IBM for an example, IBM is responsible for ibm.com. The IBM part of ibm.com is the 'second level'.

For country code domains, such as Taiwan's .tw, the top level is extended to include .com.tw, .net.tw, .org.tw, etc. Companies such as Abit (computer component manufacturers) would be abit.com.tw. Because the root registry in that region controls both the country code domain and the organization level domain, the owner is still the second level domain. Thus 'abit.com.tw' is still considered a second level domain.

In strictest resolution sense, abit.com.tw is actually a third level domain. Just exactly what you call such a domain is a bit esoteric and depends on the domain and who you are discussing it with. Generally, it is accepted that the term 'second level domains' are managed and owned by the organizations that purchased the right to register that particular domain name.


3. Sub-Domains

A sub-domain is a domain that an organization's DNS administrator created to make managing the DNS simpler or at least more logical.

Take a college campus for example. The DNS administrator for Berkeley might create a sub-domains for:

* Administration
* Faculty
* Computer Science Department
* Liberal Arts departments
* Science departments
* Research labs

...or for whatever else the administrator might set up. Note that sub-domains are totally at the discretion of the DNS administrator. Once the root has delegated to the DNS server managed by the organization who registered the domain, the organization can do whatever they please with resolution.

The DNS administrator would configure the berkeley.edu DNS server to delegate responsibility to another DNS machine located in the Computer Science department. The Computer Science department might delegate to their laboratory's DNS server for the Laboratory's DNS.
 
DNS ZONES

A zone contains all the names and IP addresses of a given group of hosts. Zones are a concept, not really a configurable object themselves, though most DNS administrators speak of zone files when configuring BND (named). Assuming a zone is the same as a zone file is not quite technically correct as a zone file contains additional information that just the host information. To configure a complete zone, you need one or more zone files, each containing resource records for all the hosts in the zone. The term zone is used to refer to a group of names that are part of a common unit and grouped together into a namespace. Namespace itself is another concept that refers to a group of names. The terms namespace, domain, and zone are frequently and incorrectly used interchangably, but for the purposes of most discussions, the differences aren't enough to worry about.

    

Examples of the proper use of the terms are shown below:

• The DNS namespace contains all domain names.
• My domain is inetdaemon.com.
• The DNS zone bored.bla-blather.org could contain the hosts silly, stiff and tears.

The DNS system is hierarchichal. For example, in the United States, the top level of the DNS hierarchy are the .gov, .com, .net, .org, .edu domains. Abroad, there are the country code domains (.fr, .it, .uk, .cn, .ca etc.). At the second level are domains registered with the registrars (company.com, department.gov, school.edu). Within the second level domains are sub-domains managed by the owner of the domain. A zone contains all the hosts that fall into a single namespace. The top level domain .com is the namespace that contains all .com domains. Likewise, yahoo.com contains all the yahoo.com names, such as mail.yahoo.com, www.yahoo.com and others.
Let's use the example of a fictional global company called "Zap O Matic Inc." who has registered the domain name "zapomatic.com". Let's say the headquarters is in the United States and they have divisions in the Netherlands, Australia and Japan. If each division is self-supporting, with it's own management, human resources, accounting and sales departments, then they would probably set up something as follows:
zapomatic.com might contain:

• netherlands.zapomatic.com (which would itself contain..)
  • management.netherlands.zapomatic.com
  • hr.netherlherlands.zapomatic.com
  • accounting.netherlands.zapomatic.com
  • sales.netherlands.zapomatic.com
• australia.zapomatic.com (which would itself contain..)
  • management.australia.zapomatic.com
  • hr.australia.zapomatic.com
  • accounting.australia.zapomatic.com
  • sales.australia.zapomatic.com
• japan.zapomatic.com (which would itself contain..)
  • management.japan.zapomatic.com
  • hr.japan.zapomatic.com
  • accounting.japan.zapomatic.com
  • sales.japan.zapomatic.com

From this example, you can see that we happen to have three identical department namespaces under each of the unique countries. Together, the countries (and everything under each of them) are part of the namespace for Zapomatic.com. It is this idea of a hierarchy of namespaces that enables DNS to be a distributed function that is managed by the administrators of each domain.