Wednesday, May 30, 2012

Troubleshooting DNS Server

Related to Previous Article: http://amar-linux.blogspot.com/2012/05/configuring-primary-dns-server-on.html

If you are unable to dig properly to your own Test DNS Server (Lab only, not a live DNS Server), here are some tips -


  1. Check whether the named service is running.

  2. [root@ns1 named]# service named status
    version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
    CPUs found: 1
    worker threads: 1
    number of zones: 17
    debug level: 0
    xfers running: 0
    xfers deferred: 0
    soa queries in progress: 0
    query logging is OFF
    recursive clients: 0/0/1000
    tcp clients: 0/100
    server is up and running
    named (pid  1235) is running...
    
     

  3. Check whether the FQDN is properly set in /etc/sysconfig/network and /etc/hosts

  4. [root@ns1 named]# cat /etc/sysconfig/network
    
    NETWORKING=yes
    HOSTNAME=ns1.testdom.inv
    GATEWAY=192.168.1.3
    
    [root@ns1 named]# cat /etc/hosts
    
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    192.168.1.13    ns1.testdom.inv    ns1
    
    

  5. It has to be ensured that the only nameserver IP in /etc/resolv.conf is the IP of the test DNS Server.

  6. [root@ns1 named]# cat /etc/resolv.conf 
    
    nameserver 192.168.1.13
    
    

  7. Check whether the zone files in /var/named have group ownership of named.

  8. [root@ns1 named]# ls -l /var/named/testdom-*
    -rw-r----- 1 root named 325 May 31 11:16 /var/named/testdom-fz
    -rw-r----- 1 root named 318 May 31 11:12 /var/named/testdom-rz

Primary DNS Server in CentOS 6 (without chroot)

Objective

We would be configuring the primary DNS Server for the domain testdom.inv (yes, the top level domain is inv i.e. 'invalid').  The FQDN (Fully Qualified Domain Name) of the server is ns1.testdom.inv. This is a simulation, so you better get your Server off the Internet-
  1. make sure the Server does not have any real IP
  2. make sure that the file /etc/resolv.conf does not contain any IP address of a valid DNS Server.

Here is the IP Database
  • DNS Server 192.168.1.13
  • Web Server 192.168.1.12
  • FTP Server 192.168.1.11

Procedure

Phase1:

The first thing when it comes to configuring any Server is setting up the hostname of the Server properly. We have to modify the following lines in the mentioned files -

[root@centu ~]# vim /etc/sysconfig/network

HOSTNAME=ns1.testdom.inv


[root@centu ~]# vim /etc/hosts

192.168.1.13    ns1.testdom.inv   ns1

Changing hostname like this sometimes takes effect after a Server reboot. To avoid that, we also set the hostname as ns1.testdom.com temporarily until the next reboot.

[root@centu ~]# hostname ns1.testdom.inv
[root@centu ~]# hostname
ns1.testdom.inv 

Finally, we set the resolver IP

[root@ns1 ~]# vim /etc/resolv.conf

nameserver 192.168.1.13

Phase 2:

We would be setting up the package bind to provide DNS service.The package can be easily installed using yum. First we remove any previous version of bind, bind-chroot and then we install the required packages.


[root@ns1 ~]# yum erase bind bind-chroot

[root@ns1 ~]# yum install bind
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package bind.i686 32:9.7.0-5.P2.el6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch          Version                       Repository      Size
================================================================================
Installing:
 bind          i686          32:9.7.0-5.P2.el6             myyum          3.5 M

Transaction Summary
================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 3.5 M
Installed size: 6.4 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 3.5 M
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : 32:bind-9.7.0-5.P2.el6.i686                              1/1 

Installed:
  bind.i686 32:9.7.0-5.P2.el6                                                   

Complete!


Phase 3:

 Now we prepare the configuration file /etc/named.conf


[root@ns1 ~]# cp /usr/share/doc/bind-9.7.0/sample/etc/named.rfc1912.zones /etc/named.conf
cp: overwrite `/etc/named.conf'? y

[root@ns1 ~]# vim /etc/named.conf

#### Please add/modify the following lines ####

options {
        directory "/var/named"; // the path of the zone files
        forwarders {4.2.2.1; }; // in case of DNS query failure, the IP of the next DNS Server where the queries would be forwarded
};


// declaration of the forward zone
zone "testdom.inv" IN {
        type master;
        file "testdom-fz"; //forward zone file stored in /var/named
        allow-update { none; };
};

// declaration of reverse zone
zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "testdom-rz"; // reverse zone file stored in /var/named
        allow-update { none; };
};



Phase 4:

Now it's time to prepare the zone files. The zone files are stored in /var/named. The character '@' denotes a 'NULL' value in these files. Please be careful while writing as syntax errors in these files can easily occur. 
IMPORTANT: Every FQDN declared in the zone files has a '.' in the end.

Forward Zone

[root@ns1 ~]# cd /var/named
[root@ns1 named]# cp named.localhost testdom-fz
[root@ns1 named]# vim testdom-fz 

;Comment: this is the forward zone file

; IMPORTANT every FQDN has a trailing dot '.'

$TTL 1D
;Comment: FORMAT
;Comment: @      IN SOA  FQDN email (user.domain.tld) (

@       IN SOA  ns1.testdom.inv. user.testdom.inv. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        IN NS      ns1.testdom.inv.
        IN A       192.168.1.13
ns1     IN A       192.168.1.13
www     IN A       192.168.1.12
ftp     IN A       192.168.1.11

Reverse Zone

[root@ns1 ~]# cd /var/named
[root@ns1 named]# cp testdom-fz testdom-rz
[root@ns1 named]# vim testdom-rz 

;this is the reverse zone file

; IMPORTANT every FQDN has a trailing dot '.'

$TTL 1D
;FORMAT
;@      IN SOA  FQDN email (user.domain.tld) (

@       IN SOA  ns1.testdom.inv. user.testdom.inv. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        IN NS   ns1.testdom.inv.
13      IN PTR  ns1.testdom.inv.
12      IN PTR  www.testdom.inv.
11      IN PTR  ftp.testdom.inv.


Now, we have to change the ownership of the zone files to match the permission of the other files in the directory.

[root@ns1 named]# cd /var/named
[root@ns1 named]# chgrp named testdom-*

[root@ns1 named]# ls -l test*
total 48
-rw-r----- 1 root  named  325 May 31 11:16 testdom-fz
-rw-r----- 1 root  named  318 May 31 11:12 testdom-rz



Finally it's time to start the DNS Service.

[root@ns1 named]# service named restart
Stopping named:                             [  OK  ]
Starting named:                             [  OK  ]
[root@ns1 named]# chkconfig named on


Phase 5:

Finally it's time for testing.
[root@ns1 named]# yum install bind-utils
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package bind-utils.i686 32:9.7.0-5.P2.el6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package            Arch         Version                    Repository     Size
================================================================================
Installing:
 bind-utils         i686         32:9.7.0-5.P2.el6          myyum         173 k

Transaction Summary
================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 173 k
Installed size: 419 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 173 k
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : 32:bind-utils-9.7.0-5.P2.el6.i686                        1/1 

Installed:
  bind-utils.i686 32:9.7.0-5.P2.el6                                             

Complete!
[root@ns1 named]# 


We would be using the command dig for testing DNS configuration. The command dig sends a query and waits for answers. Here is a demo -

IMPORTANT: The first thing to look for is in the status NOERROR . If the value is anything other, then there is a problem i.e. NXDOMAIN - Non eXisting DOMAIN, SERVFAIL - SERVer FAILure

[root@ns1 named]# dig ns1.testdom.inv

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6 <<>> ns1.testdom.inv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37595
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.testdom.inv.        IN    A

;; ANSWER SECTION:
ns1.testdom.inv.    86400    IN    A    192.168.1.13

;; AUTHORITY SECTION:
testdom.inv.        86400    IN    NS    ns1.testdom.inv.

;; Query time: 1 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Thu May 31 11:39:52 2012
;; MSG SIZE  rcvd: 63


As we can see from the output, the ANSWER SECTION states that the A Record i.e. IP address of ns1.testdom.inv. is 192.168.1.13


[root@ns1 named]# dig -x 192.168.1.13

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6 <<>> -x 192.168.1.13
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6969
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;13.1.168.192.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
13.1.168.192.in-addr.arpa. 86400 IN    PTR    ns1.testdom.inv.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa.    86400    IN    NS    ns1.testdom.inv.

;; ADDITIONAL SECTION:
ns1.testdom.inv.    86400    IN    A    192.168.1.13

;; Query time: 2 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Thu May 31 11:41:27 2012
;; MSG SIZE  rcvd: 102


Again, as we can see from the output, the ANSWER SECTION states that the IP address 192.168.1.13 points to i.e. PTR Record ns1.testdom.inv.

The DNS Server should also work for www or ftp servers in testdom.inv. You can also check using nslookup and ping.

Hope this helps.

Thursday, May 17, 2012

How DNS Works


Domain Name System

In any network, the hosts primarily communicate between each other through IP addresses. For example, if my computer is doing a google search, my computer is actually communicating with the IP address of one of the web servers of google.com. However, even if the computer is efficient with numbers, humans on the other hand work better with names. For this reason, the TCP/IP protocol includes the Domain Name System (DNS)  to link between IPs and computer names i.e. hostnames. The DNS is a distributed database of computers that is responsible for resolving hostnames against IP addresses and vice-versa.

Any DNS query involves two parts.
  1. The Resolver: The resolver forms up or initiates the query. The resolver itself does not run as a program. /etc/resolv.conf is an example of a resolver.
  2. Name Server: The Name Server is the service running in the server that responds to the DNS query generated by the resolver i.e. answers to the question of the resolver.


Fully Qualified Domain Name

The fully qulified domain name is the full name of any server. Just like any human needs a full name in the real world, every server on the Internet also need a full name to work. The structure of a FQDN- host.domain.tld. For example, in www.qwe.netwww” is the hostname of the web server, “qwe” is the name of the domain and “net” is the top level domain (TLD). Other examples of TLD are .com, .org, .gov, .mil and so on.


The Root-Servers

As mentioned earlier, the DNS works as a distributed database. If a DNS server does not know the answer to a query, it forwards the query to another server upper in the hierarchy. The query keeps going upwards until it reaches the root. There are 13 root servers responsible for all DNS in the world. The root servers are named as a.root-servers.net to m.root-servers.net. These root servers continuously keep communicating with each other and update each other about what they know. Here is an interesting article about the root DNS server numbers: http://blog.icann.org/2007/11/there-are-not-13-root-servers/


Authoritative Name Servers

The authoritative name servers are servers that are responsible for a domain. For example, if we host the DNS for a domain qwe.net, then the domain requires at least 2 authoritative DNS servers i.e. ns1.qwe.net & ns2.qwe.net.

These two authoritative DNS servers are responsible for any DNS query about the qwe.net domain and should be able to answer any query regarding this domain. The root servers store only the records for the authoritative name servers for different domains.

How DNS Works

I found this step-by-step image in the web, and thought it's worth sharing. Here is the link to the full article- http://www.communityguy.ca/resources/cira-2009-elections-and-an-overview-of-how-dns-works/

How DNS works (Reference)


And now for the step-by-step analysis.

  1. The client initiates a query to find techsmb.ca. The client sends the query to the DNS server of the ISP. (The DNS Server IP in the client computer is set as the IP address of the DNS Server of the ISP)

  2. The DNS Server of the ISP first checks it's own cache to check whether it already knows the answer. But as the answer is not present, it generates another query. As the TLD of techsmb.ca is .ca, so the DNS server queries CIRA to find who is responsible for techsmb.ca.

  3. The CIRA responds to the ISP by answering the query.

  4. Once the ISP DNS Server knows the authoritative name servers, it contacts the authoritative name servers to find out the IP address for www.techsmb.ca. i.e. the IP address of host www in the domain techsmb.ca.

  5. techsmb.ca responds to the ISP DNS Server by answering the query and providing the IP address of the web server i.e. www

  6. The ISP DNS Server stores the answer in it's cache for future use and answers to the client by sending the IP address of the www server.

  7. The client may store the answer to the DNS query in it's own cache for future use. Then the client communicates directly with the www server of domain techsmb.ca using the IP address.

  8. The www server responds by sending the index.html page.

Hope this helps. ^_^

Wednesday, May 2, 2012

Using Citycell Zoom in Ubuntu

Thank you Anirban Da for sharing the information.

Ubuntu has proven again that it's one of the most user friendly operating systems. Using Citycell Zoom in Ubuntu is very easy.

Here's how it's done:
  • Click on the network icon on the upper right corner of the screen
Step 1

  • Go to Edit Connections > Mobile Broadband > Add
Mobile Broadband
  • Continue
  • Select country from the list
Selecting Country
  
  • Select the service provider
Selecting Service Provider
  • Finish
  • When prompted for username and password combination, type in the following:
    • username: waps
    • password: waps
  • Now anytime you wish to connect using zoom, go to the network icon and use your citycell connection for surfing.
Hope this helps.