Monday, April 14, 2014

How DNS Works_v2

This is one of my tutorials originally published at

Domain Name System (DNS) is one of the most critical services in the Internet. Without DNS, we would not be able to access the web. Before going into the details on how DNS works, a little on the background may be helpful.

When you are accessing, say, Google, your traffic originates from your computer, goes through the backbone of your ISP, and then their own upstream provider and so on; until it reaches Google's network. In the TCP/IP-based current Internet, the transit communication from your computer all the way to Google's network is driven by a set of intermediate routers based on the IP address of the destination web server of Google.

This means we need to know the IP address of Google's web server to access Google service. However, it is almost impossible for us to keep more than hundreds of IP addresses in our memory. What if there could be a mechanism to map IP addresses to domain names that are easy to remember? That is where DNS services come in, which keep directories of all domain names and their associated IP addresses. So if we want to communicate with a particular web server, we can use its domain name, say, DNS server then handles the translation of the domain name to its IP address, so that our computer can communicate with the destination web server with the IP address.

Advantages of using DNS

  • For end users, using Internet is far easier.
  • For service providers, DNS allows them to design, cluster, load balance, tune and backup the network without service interruptions. This is possible as they can control the server/host that a user communicates with simply by changing DNS records.
Before we get into the details of how DNS actually works, we need to understand some terms used in the industry.


The following section is a long list of definitions. To have a firm grasp on the operation of DNS, it is important that we understand them. However, if they are too much to digest all at once, especially for the beginners, you may read through them once and move on to the next part. You can come back later to go over the hierarchy again. Believe me; they will start to make sense as the pieces fall together.
Back on the topic, all DNS names are hierarchical. The standards and RFC regarding DNS can be found here. The most prominent among them is RFC 1035.


DNS Syntax

All DNS names are hierarchical and are typically divided into 3 major parts i.e., host.domain.tld. For example, for, the part www is the host part, .example is the domain part, and .com is the top level domain (TLD). The following sections explain these in details.


Root Servers and Root Zones

The root servers and root zones are amongst the highest order in the hierarchical world of DNS. The root zones maintain the top level domains. The servers that are used to host root zones are called root servers. There are 13 sets of root servers, which are named as,,, up to The number 13 refers to number of entities and not to the actual number of servers. Each entity may contain hundreds of devices in their network for clustering, load balance and redundancy. The root servers share a distributed database and communicate with each other for updates.


Top Level Domain

A top-level domain or TLD is the rightmost part of the name, e.g., .com, .org, .net, .gov, .mil. All domains have to be registered under a top level domain. TLDs are maintained by Root Zones.



A domain is a 'string' registered under a TLD to be used by an organization/user as a part of the name. The DNS is open to the users starting from domain and moving downwards in the hierarchy. In the name syntax, the domain part is written in the left of TLD. For example, in, the part example is the domain name. Domains are maintained by Authoritative Name Servers i.e., DNS servers maintained by the user/domain.


Sub Domain

A sub domain is an optional parameter and is written on the left of the domain. A user is free to delegate sub domains within a domain. The sub domains records are kept in the authoritative name server maintained by the domain. For example, in, the part branch-1 is actually a sub domain.



Hostname is typically the leftmost part of the name, and indicates the actual server that is hosting the services. The admins have full access to this part, and can delegate names as they want. For example, in and, the parts www and ftp are hostnames, and indicate actual web server and ftp server.


Authoritative Name Server

The Authoritative Name Server of a domain is responsible for keeping all DNS records that are relevant to the domain. Naturally, it is impossible, as well as inefficient for the root servers to contain all DNS mappings and records for every domain in the world. Instead, the authoritative name servers for each domain should contain all the records for the respective domains. The root servers contain information about the authoritative name servers for each domain.

How DNS Works

Let us assume a user is trying to access the site After the user typed the URL in the browser and hit enter, the page is loaded seamlessly in the browser. To make that happen, the following events take place behind the scenes.

How DNS Works

  1. The user computer checks its own DNS cache for the IP address. If it is not found, the user forwards a query to the configured local DNS server, typically the DNS server operated by the user's ISP.
  2. The local DNS server checks its own cache for the IP address to check whether it already knows the answer. If it is not found, the local DNS server queries the root servers for the authoritative name servers for the domain. This type of query is called a recursive query. As the TLD for the domain is .com, the responsible root servers should be able to answer the query.
  3. The root servers reply with necessary information about the authoritative name servers.
  4. The local DNS server now queries the authoritative DNS servers of directly, which should have all DNS records within the domain.
  5. The authoritative DNS server of answers the query by providing the IP address for the host WWW.
  6. The local DNS server stores the information in the cache for future reference, and returns the IP address to the original user.
  7. The user computer stores the IP address in its DNS cache as well. Then the web browser generates an HTTP request to the WWW server of located at
  8. The WWW server of happily responds to the query, and sends the page to the user.

To sum up, surfing through the Internet is very easy thanks to DNS. Underneath it, however, a lot of activities take place in the background. The Internet that we know and love today would collapse without it.

Hope this helps.

Wednesday, June 5, 2013

BGP Looking Glass - Zebra || CentOS 6

Using Zebra Routers with Looking Glass

The syntax for the Zebra Router is provided with the configuration file. Adding devices is very simple-

vim /var/www/html/lg/lg.conf

<!-- Zebra Router Section  -->
<Router Name="Zebra-1 " OSType = "Zebra">
                       <URL>telnet://pass@IP:port </URL>
<!--EXAMPLE   <URL>telnet://login:123456@,2605</URL> -->

Issues with Trace and Ping 

I was not able to use Trace or Ping using Zebra router as the commands are not built in with Zebra. However, the BGP commands should work without any problems.

Ping Using Zebra

Trace Using Zebra
 Hope this helps :)

Tuesday, June 4, 2013

Setting Up BGP Looking Glass - CentOS 6

Setting Up Looking Glass 


A looking glass is a server that allows someone from outside the network to get information about the how traffic is routed through the network backbone of an organization. For example, suppose Alpha Corp. has one router in the US and another in Australia. An outside user wants to know how traffic towards Japan is routed from both of these Routers. As the user does not have credentials to the Routers, he cannot run traceroutes. The solution: a Looking Glass. If Alpha Corp. has a looking glass, the user can query about ping, trace, BGP and other information through the web-based looking glass without needing to authenticate to the actual router.

Setting Up 

Before we start please make sure SELinux is disabled. Also, iptables should allow the required ports, from the top of my head – 23, 2601, 2605, 80. 

Phase 1: Working YUM Server 

Make sure that your server has access to a good yum server, preferably repoforge. Information about how to add the repository of repoforge can be found at

Phase 2: Downloading Necessary Prerequisites 

Fortunately, the LG looking glass does not have many prerequisites. The following should suffice-

yum install wget  perl-Net-Telnet perl-Net-Telnet-Cisco perl-XML-Parser httpd

Phase 3: Installing Looking Glass 

Looking glass is freely available and can be downloaded and extracted using the following commands-

cd /root
tar zxvf lg-1.9.tar.gz
mkdir /var/www/html/lg

Necessary files have to copied to /var/www/html/lg and permissions need to be corrected as well

cd /var/www/html/lg
cp /root/lg-1.9/lg.cgi . 
cp /root/lg-1.9/favicon.ico .
cp /root/lg-1.9/lg.conf  .
chmod 644 *
chmod 755 lg.cgi

Phase 4: Tuning the Web Server

vim /etc/httpd/conf/httpd.conf

    Alias /lg/favicon.ico "/var/www/html/lg/favicon.ico"
    ScriptAlias /lg "/var/www/html/lg/lg.cgi"

service httpd restart
chkconfig httpd on

Part 5: Adding Routers 

All routers are added in the file /var/www/html/lg/lg.conf. Luckily, the file is self explanatory-
vim /var/www/html/lg/lg.conf

<!-- Test CISCO Router Section  -->

                <Separator>Sample Routers </Separator>

                <Router Name="Router-1">
        <!--EXAMPLE   <URL>telnet://login:123456@</URL> -->

                <Router Name="Router-2">

                <Router Name="Router-3">

Now, we should be able to access the Looking Glass via the URL: IP/lg e.g.

Phase 6: Tuning (Optional)

 Log File 

touch /var/log/lg.log
chown apache:apache /var/log/lg.log

vim /var/www/html/lg/lg.conf


Copy the logo file to /var/www/html/images

mkdir /var/www/html/images

vim /var/www/html/lg/lg.conf
    <LogoImage Align="center" Link="">/images/logo.png</LogoImage>


vim /var/www/html/lg/lg.conf
<HTMLTitle>ASXXXX-Looking Glass</HTMLTitle>

vim /var/www/html/lg/lg.cgi
#### In the closing section of the HTML tag i.e. </HTML>, the following line can be added-####
  Please email questions or comments to
 <A HREF="mailto:$email">$email</A>.
Powered By: <a href="">Looking Glass 1.9</a></P>


TATA: AS6453

NovoCom: AS132267
  Hope this helps :)

Tuesday, March 12, 2013

OTRS - Adding new columns to customer database

Finding proper documentation on OTRS has been difficult for me so far. Maybe the reason behind this is, OTRS supports tons of great features, and to document everything that can be done is difficult. Nonetheless, OTRS is a fantastic software.

Recently, our company needed to add some columns in the OTRS backend database. As I work in a company that deals with the Internet, we needed to integrate customer bandwidth and prefix information to OTRS database. After some stumbling and trial and error, here's what can be done -

Part 1: Creating the columns

mysql -p
mysql> use otrs;
mysql> ALTER TABLE customer_user ADD bandwidth VARCHAR (50);
mysql> ALTER TABLE customer_user ADD prefix VARCHAR (250);
mysql> quit;

Part 2: Tuning OTRS

vim /opt/otrs/Kernel/Config/

## And we add the following lines
[ 'UserBandwidth',    'Bandwidth',   'bandwidth',    1, 0, 'var', '', 0 ],
[ 'UserPrefix',       'Prefix',      'prefix',       1, 0, 'var', '', 0 ],

service otrs restart

And we are ready. The customer panel in OTRS should contain separate fields for bandwidth and prefixes now.

Hope this helps.

Thursday, February 21, 2013

Observium vs. Cacti v2

Recently, I have setup an observium server for our office. After about two weeks of operation, here's what I think of them-



  • Has thousands of templates.
  • Auto discovers which templates are applicable for a host
  • Comparatively better interface


  • Comparatively more processor intensive.
  • Does not work without DNS (/etc/hosts tuning is helpful)
  • Adding users and controlling view can be tricky
  • The bandwidth graph of cacti is better
  • I could not find any "zoom" feature for the graphs



  • Very good for bandwidth graphs.
  • Very good for user portals and controlling user views.
  • Easily customizable graph trees


  • No auto discovery feature
  • Adding new templates can be tricky, very tricky.
  • Needs 64 bit counters for bandwidth graphs over 100 Mbps. Learnt it the hard way.

Wednesday, December 12, 2012

Sendmail: Bypass DNS and Forward Emails to Smart Host

Scenario: We need a dumb mail server that would forward all outgoing mails (originated in the server) to a relay host/smart host. We don't want our mail server to do any DNS queries (we leave the noble task for the smart host, after all, he's "smart").
Here's how it's done in sendmail-

  • Create a new file in the /etc/mail directory
vim  /etc/mail/service.switch

####### start of file #########

hosts files
aliases files

####### end of file ###########

  • We add the "relay host" IP to
vim  /etc/mail/

### obviously, replace the relay host address based on your requirements
### end ###

m4 /etc/mail/ > /etc/mail/
service sendmail restart
NOTE: Make sure there is no dnl in the beginning of the line. The compiler will treat any starting with dnl as a comment.

And it's done. Now our mail server will not do any DNS queries and forward all outgoing mail to smart host located at

Hope this helps :)

Sunday, December 2, 2012

Password Protecting Grub

To protect grub using md5 encrypted password, we can use this simple technique-

[root@zimbra ~]# grub-md5-crypt
Retype password:

 This command generates a MD5 encrypted password that will be added to the file grub.conf. Here is my sample file-

[root@zimbra ~]# vim /etc/grub.conf

password --md5 $1$zsPMx0$DkhqPFB1ouY/W7uhvCJZL1
title Red Hat Enterprise Linux (2.6.32-220.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/vg_zimbra-lv_root rd_NO_LUKS rd_LVM_LV=vg_zimbra/lv_root LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto rd_LVM_LV=vg_zimbra/lv_swap  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM
        initrd /initramfs-2.6.32-220.el6.x86_64.img

And we are ready. The system can be rebooted safely, and will never ask for password during booting.

However, the system will ask for a password if someone tries to access grub menu entries, for example, to get to single user mode.

Grub asking for password

Hope this helps. :)

NOTE: You could try experimenting with "password" placement in different places of grub.conf. This parameter may be used multiple times in the file.