Showing posts with label Dns. Show all posts
Showing posts with label Dns. Show all posts

Sunday, November 13, 2011

Dns Stuff


Wild Card DNS

For the DNS, edit the DNS zone file and add the following:
Code:
* IN A x.x.x.x
(where x.x.x.x is the IP for the hosting account using the wildcard)
Edit your httpd.conf config file for your web server and add a
server alias wildcard for the host you want to have wildcards:
Code:
ServerAlias *.mydomain.com

OpenDNS error


change etc/named.conf from:
options {
directory “/var”;
auth-nxdomain no;
pid-file “/var/run/named/named.pid”;
to this:
options {
directory “/var”;
auth-nxdomain no;
pid-file “/var/run/named/named.pid”;
allow-recursion { 127.0.0.1; }
;

Thursday, September 15, 2011

Simple Management for BIND


Smbind is a PHP-based software tool for managing DNS zones for BIND via the web interface. This supports the per-user administration of zones, error checking, and a PEAR DB database backend.

1. INSTALLATION

Please download the smbind tar file from the download section using wget.
# wget http://jaist.dl.sourceforge.net/sourceforge/smbind/smbind-0.4.7.tar.gz
# tar -zxvf smbind-0.4.7.tar.gz
# cd smbind-0.4.7/
You will need to create a database, table structure, install and configure the PHP scripts, and modify your named.conf. You will need to adjust permissions on your system so that your web server user (www, apache, httpd, nobody, etc.) can read and write various files relating to BIND, such as rndc.

2. DATABASE

You will need to create a database, table structure and then copy the dump file smbind-mysql.sql to the respective database.
Create the smbind database.
[MySQL]         mysqladmin create smbind
[PG]            createdb smbind
Create the smbind tables.
[MySQL]         mysqldump smbind < smbind-mysql.sql
[PG]            psql -U dbuser -d smbind < smbind-pg.sql

3. WEB SERVER

Copy the contents of the php directory to a web server directory.
# cp -Rp php/* /usr/local/apache/htdocs
Secure the config file (private readable) and template_c (writable) directories. Your web server may not run as apache, it may run as www, httpd, nobody, or something entirely different.
# chown root.apache config.php template_c
# chmod 640 config.php
# chmod 775 template_c
Download the latest version of Smarty from http://smarty.php.net/. Untar the file, and copy the libs folder to the location specified in the smarty_path option in the config file config.php.
# mkdir /usr/share/smarty
# tar zxvf Smarty-2.6.1.tar.gz
# cp -R ./Smarty-2.6.1/libs/* /usr/share/smarty
Edit config.php, setting your database information and the locations of your named-checkconf, named-checkzone, and rndc binaries. smbind configuration examples are provided for both normal and chroot jailed BIND setups.
The typical config.php file with all necessary configurations will be as follows:
// Include paths.
$_CONF['smarty_path']   = “/usr/share/smarty”;
$_CONF['peardb_path']   = “/usr/share/pear”;

// Database DSN.
$_CONF['db_type']       = “mysql”; // mysql for MySQL, pgsql for PostgreSQL
$_CONF['db_user']       = “smbind”;
$_CONF['db_pass']       = “newpass”;
$_CONF['db_host']       = “localhost”;
$_CONF['db_db']         = “smbind”;

// Zone data paths (normal).
$_CONF['path']          = “/var/named/”;
$_CONF['conf']          = “/etc/smbind/smbind.conf”;
# Include this file in named.conf.

// Zone data paths (chroot).
#$_CONF['path']         = “/var/named/chroot/var/named/”;
#$_CONF['conf']         = “/var/named/chroot/etc/smbind/smbind.conf”;
# Include this file in named.conf.

// BIND utilities.
$_CONF['namedcheckconf'] = “/usr/sbin/named-checkconf”;
$_CONF['namedcheckzone'] = “/usr/sbin/named-checkzone”;
$_CONF['rndc']           = “/usr/sbin/rndc”;
Provided is a configtest.php script that will test permissions on everything to ensure that your configuration will work. It will be located at http://localhost.localdomain/src/configtest.php

4. BIND

Add the user that runs your web server to the group that runs the BIND server. This will allow BIND to access it’s files, while also allowing your web server to update and manage them. The example below assumes that apache is running as “apache” and that BIND is running as “named”. Apache must then be restarted.
# usermod -G named apache
# /etc/rc.d/init.d/httpd restart
Create a directory for the smbind zone file.
# mkdir /etc/smbind
# chown root.named /etc/smbind
# chmod 775 /etc/smbind
Add an include to your named.conf, adding smbind.conf to named.conf.
include "/etc/smbind/smbind.conf";
Modify the permissions on BIND’s zone file directory. Some distributions do not even allow named to write to its own zone directory.
# chmod 770 /var/named

5. TESTING OUT

Fire up a browser and view http://localhost.localdomain/src/configtest.php This script will verify that your web server can read and write every where it needs to. If it encounters any permissions problems, read the error message carefully and investigate as instructed. It is assumed that your BIND is running prior to this test.The typical configtest will output as follows:
smbind configtest

This script will try to check some aspects of your smbind configuration
 and point you to errors where ever it can find them. You need to edit
config.php and read the INSTALL file first before you run this script.

Testing config.php...OK
Testing PEAR DB...OK
Testing Smarty...OK
Testing templates_c...OK
Testing path...OK
Testing conf directory...OK
Testing conf file...OK
Testing named-checkconf...OK
Testing named-checkzone...OK
Testing rndc...OK
Testing (guess) /etc/rndc.conf...OK
Testing (guess) /etc/rndc.key...OK
Testing (guess) connection to localhost:953...OK
Testing rndc execution...OK
server is up and running
Testing database connection...mysql://smbind:newpass@localhost/smbind OK
Testing database SELECT from zones table...OK
Testing database SELECT from users table...OK
Testing database SELECT from records table...OK
Testing database INSERT into zones table...OK
Testing database INSERT into users table...OK
Testing database INSERT into records table...OK
Testing database UPDATE zones table...OK
Testing database UPDATE users table...OK
Testing database UPDATE records table...OK
Testing database DELETE FROM zones table...OK
Testing database DELETE FROM users table...OK
Testing database DELETE FROM records table...OK

Congratulations, your setup looks good. Please remember to add the
following line to your named.conf:
include "/etc/smbind/smbind.conf";
Web interface
Login to the web interface http://domainname/php/src/main.php
with the user 'admin' and password 'admin'.

Possible threats to the Internet


DNS is for the Internet, what oxygen is for life. Though we constantly use it, we are unaware of its presence. DNS has come a long way since Stanford Research Institute’s Network Information Center (SRI-NIC) maintained a file called hosts.txt which contained host-names and their corresponding IP addresses, to a complex network of databases called name-servers.
DNS was originally designed to make it easier for us to memorize names (host-names) rather than numbers (IP addresses). Gradually, many applications and protocols used the host-names and IP addresses as a basis to authenticate the host. Thus DNS security came into being, since wrong information from a DNS server, can disallow a legitimate request from a legitimate client.
Lets see in what ways our DNS infrastructure is vulnerable.

Cache Poisoning

Think of a scenario where you request for a website xyz.com. If your local name-server is not the authoritative name-server for the domain, or it’s corresponding IP address has not been cached in your local name-server, it will forward the query to a remote name-server as per the resolver configuration. Cache poisoning is when DNS information of a domain is not supplied by that domains authoritative name-server and this incorrect/malicious information is cached in a caching name-server.

Client Flooding

DNS uses User Datagram Protocol(UDP) for response data size lesser than 512 bytes. Since, UDP is a connection-less protocol, a single DNS query can get numerous responses from attackers name-servers. Thus the legitimate response may get lost among thousands of fake responses. Thus, the local name-server gets flooded by fake DNS responses resulting in corruption of its DNS entries.

Information Disclosure attacks

While it may seem to be harmless, DNS queries can be used to know the host-names of the system or the operating system details. An intruder can use DNS tools to query the IP addresses and find out which IP address(s) are still unassigned. He can then spoof the IP address and login to your system.

Vulnerability in sharing a name-server

Most of the hosting companies provide shared name-servers where many clients can use it for the domains registered by them. Imagine, a rogue client enters a zone entry for the domain paypall.com pointing to a.b.c.d IP address in the shared name-server. Other clients using the same name-server as their primary name-server when trying to access paypall.com will be redirected to a.b.c.d IP address.
Thus, all the clients are redirected to a false website, which would be a phishing site.

DDoS on DNS

It is possible to send multiple DNS requests to a name-server in such a quantity, that it’s normal service gets crippled. Various scripts are available, that can spoof IP addresses and send thousands of fake DNS request to a name-server. Legitimate requests on other hand get a “DNS request timed out.” message when they try to resolve a host-name.
These are the list of vulnerabilities in DNS. Many of them have been taken care of. Sometimes it is for a sheer mistake of the DNS administrator, that the whole DNS may get corrupted. There is a new kid in the block called DNSSEC (DNS Security), we will discuss it in the coming week.

Understanding SOA records


I’ve learned that there is nothing more peaceful than a sleeping child - Anonymous, Age 30
To an Internet Administrator, there is nothing more peaceful than a stable and optimized DNS server. The moment there is a wrong configuration, the server wakes up and starts crying, sites and email goes down. An important part of keeping DNS that way is properly setting up the SOA records.
What are DNS Records. DNS records or Zone files are used for mapping URLs to an IPs. Located on servers called the DNS servers, these records are typically the connection of your website with the outside world. Requests for your website are forwarded to your DNS servers and then get pointed to the WebServers that serve the website or to Email servers that handle the incoming email.
This is how a typical Zone file (containing many common DNS records) looks like.
;
; Zone file for mydomain.com
mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com.(
  2004123001
  86000
  7200
  3600000
  600 ) 

mydomain.com. 14400 IN NS ns.mynameserver.com.
mydomain.com. 14400 IN NS ns2.mynameserver.com.
mydomain.com. 14400 IN NS ns3.mynameserver.com.

mydomain.com. 14400 IN A 216.34.94.184

localhost.mydomain.com. 14400 IN A 127.0.0.1

mydomain.com. 14400 IN MX 0 mydomain.com.
mail 14400 IN CNAME mydomain.com.
www 14400 IN CNAME mydomain.com.
ftp 14400 IN CNAME mydomain.com.
In the rest of this article, we’ll analyze the various parts of this DNS record, starting from the top.

SOA Records

An SOA(Start of Authority) Record is the most essential part of a Zone file. The SOA record is a way for the Domain Administrator to give out simple information about the domain like, how often it is updated, when it was last updated, when to check back for more info, what is the admins email address and so on. A Zone file can contain only one SOA Record.
A properly optimized and updated SOA record can reduce bandwidth between nameservers, increase the speed of website access and ensure the site is alive even when the primary DNS server is down.
Here is the SOA record. Notice the starting bracket “(“. This has to be on the same line, otherwise the record gets broken.
; name  TTL  class rr  Nameserver   email-address
mydomain.com. 14400  IN  SOA
ns.mynameserver.com. root.ns.mynameserver.com.
(
  2004123001 ; Serial number
  86000 ; Refresh rate in seconds
  7200 ; Update Retry in seconds
  3600000 ; Expiry in seconds
  600 ; minimum in seconds )
mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com.(
can also be written as
;@ 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
or
14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
  • name - mydomain.com is the main name in this zone.
  • TTL - 14400 - TTL defines the duration in seconds that the record may be cached by client side programs. If it is set as 0, it indicates that the record should not be cached. The range is defined to be between 0 to 2147483647 (close to 68 years !)
  • Class - IN - The class shows the type of record. IN equates to Internet. Other options are all historic. So as long as your DNS is on the Internet or Intranet, you must use IN.
  • Nameserver - ns.nameserver.com. - The nameserver is the server which holds the zone files. It can be either an external server in which case, the entire domain name must be specified followed by a dot. In case it is defined in this zone file, then it can be written as “ns” .
  • Email address - root.ns.nameserver.com. - This is the email of the domain name administrator. Now, this is really confusing, because people expect an @ to be in an email address. However in this case, email is sent to root@ns.nameserver.com, but written as root.ns.nameserver.com . And yes, remember to put the dot behind the domain name.
  • Serial number - 2004123001 - This is a sort of a revision numbering system to show the changes made to the DNS Zone. This number has to increment , whenever any change is made to the Zone file. The standard convention is to use the date of update YYYYMMDDnn, where nn is a revision number in case more than one updates are done in a day. So if the first update done today would be 2005301200 and second update would be 2005301201.
  • Refresh - 86000 - This is time(in seconds) when the slave DNS server will refresh from the master. This value represents how often a secondary will poll the primary server to see if the serial number for the zone has increased (so it knows to request a new copy of the data for the zone). It can be written as “23h88M” indicating 23 hours and 88 minutes. If you have a regular Internet server, you can keep it between 6 to 24 hours.
  • Retry - 7200 - Now assume that a slave tried to contact the master server and failed to contact it because it was down. The Retry value (time in seconds) will tell it when to get back. This value is not very important and can be a fraction of the refresh value.
  • Expiry - 3600000 - This is the time (in seconds) that a slave server will keep a cached zone file as valid, if it can’t contact the primary server. If this value were set to say 2 weeks ( in seconds), what it means is that a slave would still be able to give out domain information from its cached zone file for 2 weeks, without anyone knowing the difference. The recommended value is between 2 to 4 weeks.
  • Minimum - 600 - This is the default time(in seconds) that the slave servers should cache the Zone file. This is the most important time field in the SOA Record. If your DNS information keeps changing, keep it down to a day or less. Otherwise if your DNS record doesn’t change regularly, step it up between 1 to 5 days. The benefit of keeping this value high, is that your website speeds increase drastically as a result of reduced lookups. Caching servers around the globe would cache your records and this improves site performance.

Reducing DNS bandwidth

There is constant bandwidth usage between primary and secondary(backup DNS) servers. This depends a lot on the Refresh value. If the refresh value is say 3 hours, your secondary server is polling your primary server every 3 hours and updating the cache. Lets assume you have a 1000 zone files, each with 3 hours refresh rate. You can imagine the bandwidth that must be getting used. This is especially true if the servers are on 2 separate physical servers.
An increase in the Refresh rate can effectively reduce bandwidth usage between the primary and secondary server.

Increasing site speed

The time it takes to access a website on a browser includes the time it takes to look it up on the domain name server. By increasing the “Minimum” value, we’re telling the contacting clients to keep their copies of the zone file for a longer time. In effect, reducing the lookups to the nameserver. By reducing the number of times a client has to lookup, we’re increasing the site speed.
However, this also means that if you make changes to the DNS record, it will take longer to propagate. If you require to make frequent updates to your DNS records, make sure your Minimum value is lesser than 1 day. That means longer lookup times, but accurate information for the clients
If you are planning a major update on the DNS zone file(say moving to another server or hosting service), reduce the Minimum value a couple of days prior to the change. Then make the change and then jack up the minimum value again. This way the caching clients all over the world will pick up the changes quicker and yet you do not need to sacrifice on site speed thereafter.

How to improve backup

Always keep a secondary DNS server and keep a higher Expiry value. This will mean that even if the Primary server goes down, the secondary will have the cached copy(for as long as the Expiry value stands) and it will keep serving lookups. Keeping a secondary server but a low expiry value defeats the purpose of a Backup.

How to test SOA records

You have set the new SOA values, and you want to know whether the update has taken place. “Dig” is a good tool to troubleshoot and check for DNS information.
For example to check out the SOA records of yahoo.com from all the nameservers, primary and secondary, all you need to do is
# dig yahoo.com +nssearch
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
 2005122907 3600 300 604800 600 from server ns2.yahoo.com in 0 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
2005122907 3600 300 604800 600 from server ns3.yahoo.com in 0 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
 2005122907 3600 300 604800 600 from server ns1.yahoo.com in 239 ms.
SOA ns1.yahoo.com. hostmaster.yahoo-inc.com.
 2005122907 3600 300 604800 600 from server ns4.yahoo.com in 280 ms.

Understanding MX records


What is an MX Record

MX stands for Mail Exchange Records. MX records are used in DNS records(or Zone files) to specify how email should be routed.
Lets take an example of say liz@mydomain.com.
This is how a typical DNS record(for mydomain.com) looks like.

;
; Zone file for mydomain.com

@ 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
   109157199
   86000
   7200
   3600000
   600 )
mydomain.com. 14400 IN NS ns.mynameserver.com.
mydomain.com. 14400 IN NS ns2.mynameserver.com.
mydomain.com. 14400 IN NS ns3.mynameserver.com.

; A Record
mydomain.com. 14400 IN A 216.34.94.184

localhost.mydomain.com. 14400 IN A 127.0.0.1

; MX record
mydomain.com. 14400 IN MX 0 mydomain.com. 

mail 14400 IN CNAME mydomain.com.
www 14400 IN CNAME mydomain.com.
ftp 14400 IN CNAME mydomain.com.

Notice the line with the “MX” in it. This is called the MX record.
mydomain.com. 14400 IN MX 0 mydomain.com.
The MX record shows that all emails @ mydomain.com should be routed to the mail server at mydomain.com. The DNS record shows that mydomain.com is located at 216.34.94.184. This means that email meant for liz@mydomain.com will be routed to the email server at 216.34.94.184. This finishes the task of the MX record. The email server on that server(say sendmail) then takes over, collects the email and then proceeds to distribute it to the user “liz”.
It is important that there be a dot(“.”) after the domain name in the MX record. If the dot is absent, it routes to “mydomain.com.mydomain.com”. The number 0, indicates Preferance number. Mail is always routed to the server which has the lowest Preferance number. If there is only one mail server, it is safe to mark it 0.

Multiple mail servers

Multiple email servers are useful for the sake of redundancy. If the Highest Priority email server (one with the lowest Preference number) is down, then the email is routed to the Server with the second highest Preference number.
For example
mydomain.com. 14400 IN A 216.34.94.184
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 0 mydomain.com.
mydomain.com. 14400 IN MX 30 server2.mydomain.com.
You can have unlimited MX entries for Fallback.
If all the MX records are equal Preference numbers, the client simply attempts all equal Preference servers in random order, and then goes to MX record with the next highest Preference number.

Pointing MX records to an IP

Its not possible to have an MX record pointing directly to an IP. For example ‘mydomain.com. 14400 IN MX 0 216.34.94.184“ is wrong. Define an “A Record” first and then have the MX record pointing to it.
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 30 server2.mydomain.com.

MX records for Subdomains

A Subdomain is something like this “Subdomain.mydomain.com”. Assume you want to send an email to liz@subdomain.mydomain.com and to capture that on another server.
mydomain.com. 14400 IN A 216.34.94.184
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 30 mydomain.com.
subdomain.mydomain.com. 14400 IN MX 30 server2.mydomain.com.
In this configuration, liz@subdomain.mydomain.com would go to 216.34.94.185 and liz@mydomain.com would go to 216.34.94.184.

Testing the MX record

Once you setup your MX record, always test it to see if it is setup correctly. You can do with tools like nslookup.

[root@localhost sangeetha]# nslookup
> set q=mx
> yahoo.com
Server: 192.168.1.1 Address: 192.168.1.1#53
Non-authoritative answer:
yahoo.com mail exchanger = 1 mx1.mail.yahoo.com.
yahoo.com mail exchanger = 1 mx2.mail.yahoo.com.
yahoo.com mail exchanger = 1 mx3.mail.yahoo.com.
yahoo.com mail exchanger = 5 mx4.mail.yahoo.com.
Authoritative answers can be found from:
yahoo.com nameserver = ns2.yahoo.com.
yahoo.com nameserver = ns3.yahoo.com.
yahoo.com nameserver = ns4.yahoo.com.
yahoo.com nameserver = ns5.yahoo.com.
yahoo.com nameserver = ns1.yahoo.com.
mx1.mail.yahoo.com internet address = 4.79.181.14
mx1.mail.yahoo.com internet address = 4.79.181.15
mx1.mail.yahoo.com internet address = 67.28.113.10
mx1.mail.yahoo.com internet address = 67.28.113.11
ns1.yahoo.com internet address = 66.218.71.63
ns2.yahoo.com internet address = 66.163.169.170
ns3.yahoo.com internet address = 217.12.4.104
ns4.yahoo.com internet address = 63.250.206.138
ns5.yahoo.com internet address = 216.109.116.17
>

How spammers read your MX

Spammers will typically target your lowest priority Email servers, in the hopes of encountering a poorly configured box. The Spam program reads the MX records, locates the Email server with the lowest Priority(highest Preference number) and attempts to spam with that server.
So it is important to equally update all your email servers with Antivirus and Antispam.

Wednesday, September 14, 2011

Load Balancing - Things you should know about


We’ve all heard about the wonders of Load Balancing, and how it can improve the performance of a site(s) or service. In this post we’ll take a look a few things you should know about before going ahead and setting it up for your site.

Mirroring your data

Since the site data is going to be served by multiple servers, it is important to make sure that the site data served by all is the same. Depending on the way the sites are designed, this could be an easy or a complicated process. If you are serving simple static sites in which the site code itself does not change much, then you can simply copy the data to all servers and leave them there. However, if your site involves constant updates to the code itself, then you’ll have to find a way to propagate these changes to other servers. You can implement some form of file sharing, or setup a program to sync data on all servers.
Please note, the changes I am referring to here are changes to the code of the website files itself. If the changes are made to a database, then it should just be enough to make that database accessible from all servers. However, in this case, the database becomes a single point of failure. If the database crashes, non of the servers will be able to serve the site. To avoid this, you’ll have to load balance the MySQL service, or setup Master-Slave or Master-Master replication. This will make sure that there are more than one instances of the database available.

Session Persistence

Another important issue that one must not forget to address is the issue of sessions. Each time a customer visits a load balanced site, various information pertaining to that session will usually be stored on the server handling that request. If as part of the load balancing, the customer is switched to another server half-way during a session, the session details will be lost. There are various means by which this can be overcome. Some hardware load balancers ensure that all requests from a particular customer are always sent to the same server. The disadvantage is that true load balancing does not occur as customers are sent to the server they were first connected to, and not the server with least load. This can be overcome by not storing session data on the server. That can be done by either storing session data in a central database, or storing it in the clients browser. If using a database, the problem mentioned above could still occur. Session data stored in a clients browser is usually in the form of cookies. Just make sure they are properly encrypted, in case sensitive information needs to be stored.

Hardware or Software Load Balancers

Depending on your budget you can choose between Hardware or Software Load Balancers. If you are availing of the Load Balancer service from your DC, inquire as to what they are using. Hardware Load Balancers are more robust and are more efficient at Load Balancing, but are more expensive. There are many Software Load Balancers available today that do a pretty good job, but they are still limited to the server hardware on which they are installed. If you plan to go for a Software Load Balancer, make sure you setup a fail-over. You could have two Load Balancing servers handling all requests and passing them to the back-end server. If one fails all requests should be sent to the other. Some Software load balancers come with this feature and will monitor the other load balancer. If one fails that other takes up all the incoming requests.

Keep these points in mind when you are thinking about setting up a Load Balancer for your servers. In most cases they fit right it and you shouldn’t have to worry. But instead of setting them up and then correcting the problems, it would be best to plan ahead. Most negative reviews for load balancer setups are because of people don’t analyze their current setup before going ahead.

Benefits of a DNS cluster


A DNS cluster is a number of nameservers that share records. This allows you to physically separate your nameservers, so that in the event of, for instance, a power outage, you still have DNS functionality. This way, visitors can reach websites on your server more quickly after the web server comes back online.
If you are already using WHM/cPanel for your webservers, setting up a DNS cluster is quite simple. For optimal performance, it is recommended to have dedicated DNS servers along with your webservers. So you can install the “cPanel DNSONLY” control panel on those server for easy integration with your current WHM/cPanel servers. You can download it here. The instructions on how to setup the DNS cluster using cPanel are mentioned here

This post is for those readers who mainly need to now the advantages of using a DNS cluster.

Benefits:
1. 0% downtime due to DNS service being down. If the DNS service is down in the server, the domain DNS will be served by the other servers in the cluster.
2. If a server is down (say being rebooted), and at that point if someone tries to send an email to a domain on that server, they will get a delivery failure message and the mail will not be sent again. This is because the senders mail server will assume the domain does not exist. But in case a DNS cluster is setup, the mail server sending the mail will only assume the mail server is down, and hold the mail in its queue to be retried again. No delivery failure report message will be sent.
3. It is easy to transfer domains among servers. The client will not have to change the nameservers used by the domains. The same nameservers can be used to point the domain to the new server.
4. You can use Global nameservers for all your servers. No need to set specific nameservers for each server.

There aren’t many demerits except that there should be a slight affect on the performance, which should be negligible. Also 0% downtime does not stand true, if the webserver is down. Then the site will be down, even if DNS is responding.
DNS clustering together with Load balancing will definitely give you the fastest performing servers with absolutely no downtime at all.

I hope this tutorial will help you achieve faster response times for your sites.

Saturday, September 3, 2011

dns tips while configuring

Just sharing some DNS tips, which needs to keep on mind while configuring your DNS server.

1. An A Record must ALWAYS contain IP address (map host to IP)

Whenever you specify A record it must contain IP address on the Right side. The A record is so important in DNS without which the meaning of mapping hostnames to IP would be absurd. So remember this!

2. CNAME (Alias) must contain hostnames. No IPs here

3. NS an MX records must contain host names. No IPs allowed.

4. Use the DOT in the end, whenever you specify a domain name in the DNS zone file. This DOT is so important and if you forget this you will have nightmares with your dns configuration.
For example
example.com. IN NS ns1.example.com.

Why DOT? simply because it tells to start query from root servers (denoted by dot)

5. MX records (for mail servers) should contain hostnames NOT IPs.

6. Allow Port 53 for both UDP and TCP connections
If you use firewall make sure you do not block port 53 for DNS tcp and udp requests. By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.
-Port 53 UDP = Dns Requests
-Port 53 TCP = Zone transfers

7. CNAMEs cannot co-xist with MX hosts.
Do not specify CNAME or aliases pointing to MX records.

domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ----------> WRONG

Instead use A record to map directly to IP address.

mail IN A 11.33.55.77 ---> CORRECT

8. No duplicate MX records
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com ----> DUPLICATE

In case if some information provided above is incorrect, please feel free to update me.
Will surely add more tips & tricks in the coming future.

Load Sharing with Round Robin DNS

One of most common implementations of DNS is the Berkeley Internet Name Domain (BIND). This allows address records (A records) to be duplicated for a specific host, with different IP addresses. The name server then alternatively rotates addresses for any one name that has multiple A records, and is known as DNS round robin.
As an example, your company has three web servers. Their real names and IP addresses are as follows: 

www.yourcompany.com128.1.1.1
www.yourcompany.com128.1.1.2
www.yourcompany.com128.1.1.3
You want to set up the servers so that DNS requests by clients (in this case, web server access) are round robin rotated. This is accomplished by placing multiple A records in the authoritative name server files.
For the above example, we want all clients to access our site by using www.yourcompany.com, but we want these requests to be shared between our three servers using DNS round robin. To do so, we need to place the following A records in the name server file:
www.yourcompany.com.INA128.1.1.1
www.yourcompany.com.INA128.1.1.2
www.yourcompany.com.INA128.1.1.2
Note the '.' after the name www.yourcompany.com on each A record. This is mandatory.
A Time To Live (TTL) field is often added to the A records. The TTL value is the maximum time that the information should be held to be reliable. By setting the TTL to a fairly small amount time e.g. 60 seconds, the effectiveness of the distribution can be maximized. A lower value may be specified, but this causes more DNS traffic in updates, which improves the load sharing on the web servers at the expense of increasing the local on the name server.
www.yourcompany.com.60INA128.1.1.1
www.yourcompany.com.60INA128.1.1.1
www.yourcompany.com.60INA128.1.1.1
When a DNS request for an IP address is received, BIND returns one of the IP addresses and makes a note of it. The next request will then return the next IP address in the file and so on until the last one, after which BIND returns to the first address again.

Advantages of DNS Round Robin:

An obvious advantage of using DNS Round Robin for load distribution is that it is seamless to the user. It is also simple and cost-effective to implement. It is standard software in most systems or else may be obtained at no or low cost. For this reason, it is very effective for small to medium size businesses or organisations and it is extremely popular among ISPs, e-commerce sites, universities and other cost sensitive sites.

Disadvantages of DNS Round Robin:

It should be noted that DNS is a load sharing mechanism rather than a load balancing mechanism. It does not gauge the "load" on the server in any way, but rather it shares the load among multiple hosts. One or more of the hosts in the pool will tend to get more activity than the other servers. DNS Round Robin should be quite effective up to about 10 servers per virtual cluster.
DNS has no way of detecting physical failure e.g. when the hard disk on server2 (www2) fails. As requests come in for www.yourcompany.com, the DNS will continue to forward one out of every three requests to www2 - which will fail. Effectively, 33% of all requests to www.yourcompany.com are now connecting to a black hole. This is an improvement over having just one web server and having all the requests being lost due to a hardware failure, but only to a certain degree.
It is very common for a computer to request data from the same host several times in any given session. It is also common for many hosts from the same site to make requests from the same servers. Usually, these requests are made to a local name server that in turn ask another name server for the resolution of the domain. In order to minimize network traffic these responses are cached - possibly on each name server along the way. This helps the network to respond quickly with domain name resolution, but it can also defeat the round-robin load distribution.
However, this caching problem may be resolved by using the TTL value. The protocol requires that local and intermediate DNS servers dump these entries from their cache when the TTL runs out. Most systems, such as Solaris, NT and Linux (and others) support BIND 4.9 and later versions. DNS round robin supports pools of servers for any applications, not just web servers. Pools of web, email, ftp, database and other servers can all be setup to load share using DNS.

Dynamic Load Balancing DNS: dlbDNS

Another approach to solving the problem of network traffic congestion is to add a dynamic load balancing feature to the existing DNS.
Distributing a request across servers can be implemented by monitoring the servers regularly and directing the request dynamically to the 'best server'. This way of dynamically directing a request across multiple servers based on the server load is called dynamic load balancing. This feature can be added to the pre-existing DNS, as it already plays a prominent role in resolving client requests and can be configured to direct client requests across multiple servers in an effort to avoid network traffic congestion. Here, the 'best server' refers to the server with the best rating, based on a rating algorithm.
There are several load balancing models available. The model implemented by dlbDNS is an internal monitoring system, that monitors the performance of the servers and provides feedback to the DNS. It is easy to maintain and administrate. Other advantages include closeness to the source of addressable problems and no security hazards.
As there are several load balancing models available, there are also a number of load balancing algorithms available. The rating algorithm implemented in dlbDNS, which determines the best server, is based on the number of users and load average shown. The algorithm is reasonable, as it favors the host(s) with the smallest number of unique logins and lower load averages.
The Server-Side Algorithm is added to the pre-existing DNS feature. During configuration, a new attribute called DNAME is added to distinguish the hosts taking part in dynamic load balancing. If the service requested is of type DNAME, do the following:
  1. Determine the set of participating servers for this service
  2. Request ratings from all participating servers by establishing a concurrent connectionless (UDP) connection with each server
  3. Using the ratings returned, determine the best server
  4. Handle error conditions such as:
    • Server is too busy to return the rating within the time frame
    • The rating returned by the server gets lost on its way back to the dlbDNS
    • All servers have same rating
    • A server is down
Rating Demon Algorithm is run on each server taking part in dynamic load balancing and is as follows:
  1. Receive request for rating from dlbDNS and respond by returning the host rating
  2. Calculate the host rating once every minute rather than calculating it at the time of request, as quick response time is a most important factor
  3. Ensure the host rating is updated every minute, independent of the dlbDNS request
  4. Handle error conditions such as dlbDNS closing the UDP sockets without waiting for host response
Implementation of the dlbDNS provides efficient utilization of system resources and ensures that facilities newly added to the existing network will be utilized. Since DNS is used, applications such as FTP and TELNET will also utilize dlbDNS.
See figure: dlbDNS This dlbDNS algorithm was proposed by the Computer Science department of Wichita State University, due to the uneven distribution of load across the servers thus causing major problems for the department. It should be noted that there is further work to be done on this approach. In particular the rating algorithm is incomplete. An algorithm that takes into account the number of processors, CPU and memory utilization would make the rating algorithm more efficient. Also, a more extensible design is needed, as Linux servers are the only servers that can participate in the dynamic load balancing scheme.

Conclusion:

The most common implementation of DNS load sharing is most certainly the DNS Round Robin technique. It is very feasible for small to middling companies and organizations. However, it is not sufficient for larger organizations and they should probably take into account other load balancing sc

Friday, September 2, 2011

How a DNS works - Simple Example


  • A User opens a web browser and tries to connect towww.google.com. The operating system not knowing the IP Address for www.google.com, asks the ISP's DNS Server for this information.
  • The ISP's DNS Server does not know this information, so it connects to a Root Server to find out what name server, running somewhere in the world, to know the information about google.com.
  • The Root Server tells the ISP's DNS Server to contact a particular name server that knows the information about google.com.
  • The ISP's DNS Server connects to Google's DNS server and asks for the IP Address for www.google.com.
  • Google's DNS Server responds to the ISP's DNS server with the appropriate IP Address.
  • The ISP's DNS Server tells the User's operating system the IP Address for google.com.
  • The operating system tells the Web Browser the IP Address for www.google.com.
  • The web browser connects and starts communication withwww.google.com.
Graphical Representation

What is GLUE Record

A glue record is an A record that is created as part of a delegation. If a zone is delegated to a name server whose hostname is a Descendant of that particular zone, then a glue record for that hostname must be included in the delegation.

Tuesday, July 12, 2011

Detailed explanation of Domain registration and it’s complete process

Websites have become a integral part of an organization in today’s world. The only medium to introduce oneself in today’s online business is by his website. Nowadays everyone are smart enough on spending some money to build an attractive website to enhance the business. Along with the appearance the name of the site too must be a catchy one. Here we discuss everything about the domain registration, transfer of domains and their status.

Domain Name

A domain name is essentially your website’s name (without www). Every domain name ends with a top level domain(TLD) name, which is always either one of a small list of generic names (three or more characters).Some instances are .com, .info, .in, .net, .org, .biz etc. For eg : “www.google.com”—->”google.com” makes the domain name and “.com” the top level domain and “www” the lower level domain. As simple as that.

Domain registration

Internet domain registration involves three entities:
Registrant who wishes to register the domain name.
Registrar who provide services to registrant.
Registry that provides services to registrar while serving as an authorative body of all information to resolve names registered in the registry’s TLD.

How to register a domain

An end-user cannot directly register and manage their domain name information with ICANN. A designated registrar must be chosen. We can register our domain with the domain registrars like Mark Monitor and Godaddy. A domain name registrar is a company, accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), to register Internet domain names.
Here are some quickies to clear with the registration
1. Effective name for an effective growth
It’s important that your website name is being found in the major search engines like Google and yahoo. For that you need to chose a domain name that suits the business as well as includes the keywords that visitors would search for in the main search engines. A short, descriptive and catchy domain name may just be money in the bank.
2. Renewal
The registrars assign the domain name on a lease for a particular period of time (maximum is 10 years which varies with TLD). After the period the domain name becomes free and anyone in the internet can register with the same. So it’s neccessary to renew the lease period.Also make sure that your domain registrar will send a remainder when your domain name is about to expire.
3. Prevention is better than worry
It would be advisable to protect your domain name by registering with multiple extensions. For example if you have registered with .com then you can also register with other extensions like .org, .net etc. You don’t need to build a site on all domains and can reserve them from others registering it.

Choosing a domain name

Choosing an effective domain name is very essential in the online business. The domain name can be of any length upto 67 characters, which includes the 26 letters of the English alphabet, numbers 0-9, and hyphens – provided that it can not begin with hyphen. More than 128 million domain names are registered and thousands are added daily. So it is a herculean task to choose a right and apt one. It would be preferable if you select a name that is related to the content in your website. Make a list of these words and try different combinations. Also try to make a name that is short, memorable, not easily confused and related to the content in your website. Make a list of these words and try different combinations. Also try to make a name that is short, memorable, not easily confused and related to the business.

Choosing a registrar

Some of the important aspects that should be considered while choosing a registrar for domain name:
    1. ICANN accreditation: The registrar should be accredited by ICANN(Internet Corporation for Assigned Names and Numbers). 2. Reliabilty: The registrar must be reliable as they are the ones who protect the domain of domain registrants from losing their domains. 3. Contract Agreement: It’s not like that once you have registered the domain names,is yours forever. The contract that you sign with the registrars may affect in many ways.They have the right to cancel the domain name for for certain reasons, generally when you use the domain for illegal or spamming purposes. So make sure that you have thoroughly gone through the contract. 4. Price: Prices differs from one registrar to other. While comparing prices, you must also look for factors that are provided by the registrar, that are customer support, testimonies etc. 5. 24×7 Support: Make sure that registrar is providing the 24×7 support. 6. Contact Information: One must look for the contact information of the registrar where you can easily get to them without any effort. You might want to test them to confirm whether they are available before you buy from them. 7. Management: Domain management is most important factor to be considered. It’s important that how they manages the domain. Many of them provides a control panel which allows you to simply log in on the web and update the information

Domain Name Registry

The domain name after the registration will be stored in a registry. It is a database of all domain names registered in top-level domain. They actually store the information about your domain name and it’s location so that it is accessible all around the world. A registry operator (also caled as Network Information Center) is the part of the Domain Name System (DNS) of the Internet that keeps the database of domain names, and generates the zone files which convert domain names to IP addresses. Each NIC is an organization that manages the registration of Domain names within the top-level domains for which it is responsible, controls the policies of domain name allocation, and technically operates its top-level domain. Domain names are managed by an hierarchy named IANA (Internet Assigned Numbers Authority).

Whois Record

It is a query/response protocol used for querying an official database to determine
Registrant: The person who holds the domain or registered the domain name.
Administrative Contact: The person/organization responsible for all administrative issues related to the domain name and the registrant information.
Billing Contact: The person/organization responsible for all the billing issues related to the domain name.
Technical Contact: The person/organization responsible for all the technical issues related to the domain.
The other information that is retrieved by the whois service is
Registrar of record: The domain name registration that registered/approved the domain name.
Record last updated: The last update made to the domain’s whois record.
Domain Creation date: The date the domain was initially registered.
Domain Expiry date: The date on which the domain name expires.

How to transfer a domain name

Domain names can be transferred from one registrar to another. You could save money on domain name renewals by transferring them to a different registrar. There are certain steps to be followed for transferring a domain from one registrar to another.
For domain transfer you need to obtain an auth code from the old registrar. Auth code is a 6 to 26 bit character code (password)assigned by the registrars to the owners as a security measure . Auth code basically is a password for the domain name. This authorised code must be submitted to the new registrar for the transfer. After receiving the auth code the new registrar will initiate the transfer. They will send an email confirmation to the holder which must be approved within 5 days otherwise will lead to failure of transfer. This is the first approval which is done by the holder. Even if you have approved the email and your domain name is locked or suspended for non-payment at the loosing registrar end then the transfer fails.
As a second approval loosing registrar sends you a mail to cancel the transfer request,ignoring the mail will complete the transfer within 5-7 days according to the ICANN. If you cancel the request the transfer will fail.Even on his step if the loosing registrar lock or unlock your domain name then the transfer fails.
Furthermore please make sure that
  1. If you recently registered or transferred your domain name, please wait 60 days before applying for transfer.
  2. Domain name is not locked by the loosing registrar.
  3. Domain name has not been deleted.
The Administrative Contact and the Registered Name Holder, as listed in the Losing Registrar’s publicly accessible Whois service are the only parties that have the authority to approve or deny a transfer request to the gaining registrar. Registrar’s may use whois data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request.
New Registrar’s Requirements
The transfer request must be done by the registered name holder. An authorised code must be submitted by the holder and the authorisation must be done via a valid Standardized Form of Authorisation (FOA). The FOA labeled “Initial Authorisation for Registrar Transfer” must be used by the gaining Registrar to request an authorisation for a registrar transfer from the administrative contact. Another FOA labeled Confirmation of standard authorisation may be used by the registrar for the confirmation of the transfer request which is done through email as explained earlier.
Transfer Disputes
Disputes between registrars over alleged violations of the transfer policy may be initiated by any ICANN-accredited registrar. If you believe that your domain name was transferred to a new registrar without your authorization or consent, please contact the original registrar. If you believe that your transfer request was inappropriately denied by your registrar, please contact the registrar to whom you wish to transfer for assistance.