Tuesday, July 12, 2011

RootKits and anti rootkits

A rootkit is a collection of programs that enable an attacker to get the same privilage as the root user in a linux or unix system. The word is composed of two portions: ‘root’ – meaning the application will provide the highest access level of the root/administrator in the system and ‘kit’ – meaning it has a number of tools.
Attackers after getting access to a server, will install a rootkit to hide their identity and run desired scripts anywhere within the server. It makes the life of a hacker easy once installed. Rootkits are not easily detectable. Sometimes, if the rootkit is one of the latest ones without a diagnosis, the server will have to be rebuild from scratch.
A rootkit will have multiple applications for cracking the entire server, some of them are:
Server Access Applications (Back door application)
These applications will create a backdoor to log in to the hacked system without using the exploit again.
Log clearing Applications
These applications clear the logs of the events performed by the hacker or the applications used. They all the associated log files in the server.
Packet sniffing Applications
These applications monitor the data through the various interfaces in the server at particular ports.
Malicious Scripts
Many scripts will be installed like IRC bots, ddos daemons, spam servers, trojans, worms etc.
There are mainly two kinds of root kits. The application rootkit and the kernel rootkit.
Application rootkits
These rootkits mimic a particular application and will hide the attackers files/processes from being revealed by the original application. To illustrate, a rootkit ls application will perform all the task of a normal ls but will not display any of the files of the attacker. Other application rootkits will create backdoors for unauthorised access, packet sniffers etc which go undetected or are hidden by renaming. Application rootkits are the most common.
Kernel rootkits
Kernel rootkits modify the kernel and apply patches to the kernel and device drivers. They also hide the applications and files of the attacker. As antivirus and other applications run beneath the kernel, they are the most undetectable rootkits.
‘Prevention is better than cure’ – as this saying goes, it is always better to keep the system secure and updated when ever possible to stop these installations. There are some applications which help detect any known rootkits running in the system. One such is the chkrootkit.
chkrootkit is one of the popular rootkit detectors (an anti-rootkit) and it is know to detect common rootkits on unix/linux servers. chkrootkit relies on basic string processing techniques to determine the presence of rootkits. It scans specific sytem files and binaries targeted by rootkits for known signatures.
The following are the instructions to install chkrootkit version 0.49 in a server.
cd /usr/local/

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5

md5sum -c chkrootkit.md5 # to check if the downloaded file is intact

tar -xzf chkrootkit.tar.gz

cd chkrootkit-0.49/

make sense

./chkrootkit
chkroootkit will check all the files and display the status of the files analysed. This information may be logged for future reference. For this a cron job may be setup to be run at least once a month.
Inserting an entry like the one below into the systems cron tasks (executed atleast once a month) will send the report of the chkrootkit vulnerabilities to the administrator conserned.
/usr/local/chkrootkit-0.49/chkrootkit | mail -s "chkrootkit report $(date +%d/%m/%y)" "admin@domain.com"

All about SSL

SSL or Secure Sockets Layer (Notice the last s in sockets) is used to secure the communication over the internet. This technique was introduced by Netscape. It uses the RSA public key cryptography for encryption/decryption.
In the protocol stack used in the internet. The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP.
The SSL protocol includes two sub-protocols:
1) SSL record protocol
2) SSL handshake protocol
The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection.
Now SSL for the layman
SSL basically creates an encrypted communication channel between the two parties involved in the communication. For a third person involved in the middle of this communication channel, the data seems to be garbled.
Suppose Alice (A, the browser) wishes to communicate with Bob (B, the server) then the exact steps that takes place inorder to begin the encrypted communication are:
1) A -> B hello
Alice contacts Bob and requests for a private communication (request for an https link at port 443)
2) B -> A Hi, I’m Bob, bobs-certificate
Bob send back to Alice his certificate. A certificate authenticates that it is Bob who is actually communicating with Alice. It is like a unique ID card displayed.
3) A -> B prove it
Alice requests Bob to prove his identity.
4) B -> A Alice, This Is bob { digest[Alice, This Is Bob] } bobs-private-key
Bob sends back a message and its digest encrypted with his private key. This step can also be like sending a document with a digital signature (when you have Alice’s public key).
5) A -> B ok bob, here is a secret {secret} bobs-public-key
Alice sends back to Bob some secret. Usually a session key encrypted using Bob’s public key obtained from his certificate
6) B -> A {some message,MAC}secret-key
Next Bob generates a secret key from Alice’s secret (earlier step) and sends back to Alice the real message and its MAC encrypted with this secret key. This is actually the encrypted website.
Terminologies
Certificate
This is actually bobs public key containing document which is digitally signed by a certificate issuer’s private key (like Verisign). In this process Verisign gets all the necessary documents to verify that Bob’s identity is correct and it gets Bob’s public key (and some other data like certificate expiry period, Bobs identity) and encrypts it with its own private key. Now Verisign’s public key comes built-in along with every browser (so that the browser can get bobs public key from within it).
Digest
Digest or more appropriately Message Digest is like a summary of the actual message or a portion of the message. The digest of a message is is unique for every unique message, it is a one way function such that obtaining the digest, it is never possible to recover the original message (This does not involve using any key in the process). Message Digest always appears with the original message. Upon reception of this Message and its digest at the receiver’s end, the receiver can once again calculate the digest from the original message and verify the integrity of the message.
Digital signature
Let Bob send a document to Alice which is digitally signed. For this Bob must have Alice’s public key and Alice must have Bob’s public key.Bob takes the document, encrypts it first with Alice’s public key and next with its own private key(Bob’s)
B -> A [{message}alices-public-key ]bobs-public-key
Session Key
The only secret which is communicated using public key encryption is a session key. Now the session key is chosen from the ‘secret’ that the parties accept. the session key could be the secret itself or a portion of the secret or the result when the secret is passed through a previously agreed algorithm. The SSL encrypted communication does’t necessary have to be created using a public key encryption technique (This uses a lot of overhead, i.e. processing and time), it may be simple symmetric cypher(less overhead) using this session key once agreed upon. There are a variety of cypher suites available (IDEA Blow-fish RSA DES MD5 KEA) and both the parties may choose some encryption technique based on the protocol used (SSL1.0 SSL2.0 TLS etc)
MAC
MAC or Message Authentication Code is similar to the Message Digest we have discussed. It is used to verify the integrity of the Message.
MAC := Digest[ some message, secret ]
Files associated with SSL
CSR
CSR or Certificate Signing Request is a string of text generated by the server. This file is sent to the SSL vendor while purchasing an SSL. In the process of generating your CSR, you provide a number of details regarding the domain being registered. Excerpts of text from all these are taken to generate your private key. This private key is present only within the server and nowhere else. The content of the CSR basically contains the public key along with all the details you have used. You get this as domain.com.csr or domain_com.csr.
CA bundle
CA (Certificate Authority) bundle file is one which contains the public key of the Certificate Issuer (Like Verisign’s public key). Usually this is not required while installing the SSL and most browsers will have this detail in advance to decrypt the SSL certificate (the CRT file) from the server. You get this as domain.com.cabundle or domain_com.ca-bundle.
CRT
This is the actuall SSL certificate as obtained from the SSL vendor. It is a file (containing the public key of the domain secured with SSL and other details like the expiry date, owner information, address etc of the SSL) which is encrypted with the private key of the SSL vendor (Digitaly signed by the SSL vendor). You get this as domain.com.crt or domain_com.crt .
Key file
This is the file which holds your private key (strictly confidential material). The file will have the RSA private key as generated by your server software. You get this as customcardsplus.com.key or customcardsplus_com.key. This file is not usually send to your SSL vendor unlike the CSR. You get this as domain.com.key or domain_com.key .
SSL in a cPanel server
Any service can be secured in a communication channel which is encrypted with SSL. Each of this service on the encrypted channel will be on a different port. Some of them are as follows:

service

normal

ssl

http80443
telnet23992
imap143/220993
pop109/110995
smtp25465
A domain served as a secure webpage will require a dedicated IP (in a shared environment). SSL protocol is designed to use IP-based mapping. SSL does not support host headers. Therefore, you should have a unique IP address assigned to your secure site. These pages are served from the port 443. Let us examine the configuration of such a website in the apache’s config file /usr/local/apache/conf/httpd.conf.
Every website (in our example domain.com with username: doma) enabled with SSL has a unique set of directives in the VirtualHost section for the 443 port as:

 Dedicated IP of the domain

ServerName domain.com #Domain name secured with SSL
ServerAlias www.domain.com

DocumentRoot /home/doma/public_html

ServerAdmin webmaster@domain.com
UseCanonicalName off
CustomLog /usr/local/apache/domlogs/domain.com combined

CustomLog /usr/local/apache/domlogs/domain.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
ScriptAlias /cgi-bin/ /home/doma/public_html/cgi-bin/
SSLEngine on #This directive enables the SSL on this domain
SSLCertificateFile /etc/ssl/certs/www.domain.com.crt #Location of CRT file
SSLCertificateKeyFile /etc/ssl/private/www.doma.com.key #Location of Private key
SSLCACertificateFile /etc/ssl/certs/www.domain.com.cabundle #Location of CAbundle file
CustomLog /usr/local/apache/domlogs/domain.com-ssl_log combined #Log specific for the SSL served webpage
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown


SSLOptions +StdEnvVars #This directive will pass mod_ssl environment variables to the server scripts.




Some times the directive SSLCertificateChainFile is used in place of SSLCACertificateFile. The minimal addition you will have to make to enable SSL in your httpd.conf file is:


DocumentRoot /var/www/html
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/DigiCertCA.crt


There are two locations where you are likely to find the SSL related files in your cPanel server. Usually the crt, key and the ca bundle are present in the home directory of the user in /home/username/ssl/, if it was installed using the client’s cpanel. However if the WHM was used instead to install the same, you will find it in /etc/ssl/. In either of these locations you will find two directories: certs/ and private/. certs contain the crt and cabundle while the private contains the keys.
Now you know how ssl works in your server, Any more questions? just comment!

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.

Who manages your domain names & your ISPs IP Addresses

IANA & ICANN – That’s the shortest answer! Now here comes the boring explanation ;)
The assignment of identifiers such as addresses and names, to ensure that they are created and allocated in a way that is acceptable to all is the main factor for the success of the Internet. So some sort of centralized organization is required. The organization originally responsible for this task was Internet Assigned Names and Numbers (IANA). IANA was originally charged with the task of managing which IP address blocks had been assigned to different companies and groups, and maintaining periodically-published lists of Internet parameters such as TCP and UDP Port Numbers. It also was in charge of DNS registrations. As the Internet grew, there was the requirement of a additional authority to manage the growing load. So by the mid 90s the Internet Corporation for Assigned names and Numbers (ICANN) came into existence.
ICANN is now officially in charge of all of the centralized registration tasks including IP address assignment, DNS domain name assignment, and protocol parameters management.
This development would have meant that IANA would have been completely replaced by ICAAN. But that did not happen. Instead, IANA was put under ICANN and is now in charge of IANA. Both organizations are responsible for IP addresses and parameters. Thus there are basically no differences between the two. These two together are at the top level of the Internet’s Name and Addresses registration and their delegation process. They also maintain the 13 root servers in the world which are at the top of the DNS tree.
For the functioning of the whole DNS system, 2 factors are to be maintained :
  1. NAMES (Domain Names)

  2. NUMBERS ( IP & TCP-UDP protocol numbers)

NAMES or DOMAIN NAME SYSTEM (DNS)

The domains at their top level are classified as :
  1. gTLD (generic Top Level Domain)
  2. ccTLD (country code Top Level Domain)
Generic Top Level Domian (gTLD)
The initial gTLDs and their original intended organization types were:
.ARPA : A temporary domain used many years ago for transition from hosts (flat file) to DNS. Its name refers to the ARPAnet, the precursor of the modern Internet. Today this domain is used for reverse DNS resolution.
.COM : Corporations and businesses.
.EDU : Universities and other educational organizations.
.GOV : Government agencies.
.MIL : Military organizations.
.NET : Organizations that implement, deal with or manage networking technologies
.ORG : Other organizations that don’t fit into any of the classifications above.
The .ARPA domain is the “Address and Routing Parameter Area” domain and is designated to be used exclusively for Internet-infrastructure purposes. ( Refer:http://encyclopedia.thefreedictionary.com/Address+and+Routing+Parameter+Area ) It is administered by the IANA in cooperation with the Internet technical community under the guidance of the Internet Architecture Board.The .arpa domain currently includes the following second-level domains: ARPA, IN-ADDR.ARPA, IN-ADDR.ARPA, IRIS.ARPA, IP6.ARPA, URI.ARPA, URN.ARPA . So the ARPA domain was not for commercial registration purposes. This left only six categories for all other organizations. Also, the TLDs weren’t all used as was originally foreseen; for example, the .GOV and .MIL domains were not used for all types of government and military organizations, but primarily for the United States federal government and military. .EDU ended up being used only for universities, again in the United States. This left only three common top-level domains – .COM, .NET and .ORG – for almost all other groups and companies that wanted to use the organizational hierarchy. Since there were only three such TLDs, they quickly became very “crowded”, especially the .COM domain. A new fourth domain, .INT for international organizations, was added fairly soon to the original seven, but it too was only for a small number of organizations, such as international standards bodies.These TLDs are intended to provide a place for all companies and organizations to be named based on their organization type. There were originally six such domains, but this has been expanded so that there are now fifteen to meet the growing needs. Please refer to the below link for the complete list :
Country Code Top Level Domain (ccTLD)
In theory, the gTLDs would have been sufficient to meet the needs of all the individuals, companies and groups in the world. This is especially true since .ORG by definition is a “catch all” that can include anyone or anything. However, back at the beginning of DNS, its creators recognized that the generic TLDs might not meet the needs of everyone around the world. There are several reasons for this, chief among them:
American Monopoly of the Generic Domains : The United States organizations and companies dominate the generic TLDs. This is not surprising, given that the Internet was first developed in the U.S.A., but it still presents a problem for certain groups. For example, if the United States military controls the .MIL domain where does, say, India’s military fit into the name space?
Language : Most of the generic domains are populated by organizations that primarily do business in English. There are hundreds of languages in the world, however, and it’s easier for the speakers of those tongues if they can more readily locate resources they can understand.
Local Control : Countries around the world rarely agree on much, and they certainly differ on how organizations within their nations should have their Internet presence arranged. There was a desire on the parts of many to allow nations to have the ability to set up subsets of the name space for their own use.
For these and other reasons, the Internet’s name space was set up with a set of country code top-level paralleling the generic ones, sometimes called / ccTLD / or geopolitical TLDs since they are based on geopolitical divisions of the world. In this hierarchy, every country of the world is assigned a particular two-letter code as a top-level domain, with a specific authority put in charge of administering the domain. For example, the ccTLD for Great Britain is “.UK”, the one for Canada “.CA” and the one for Japan is “.JP”. The codes often are more meaningful in the local language than in English, incidentally; Germany’s is “.DE” and Switzerland’s “.CH”. Refer to the following link for the complete list :
Each country has the authority to set up its TLD with whatever internal substructure it chooses; again, this is the power of a hierarchical structure. Some countries enforce a further geographical substructure at the lower levels. For example, the .US domain for the United States was originally set up so that all second-level domains were two-letter state abbreviations (this was later changed). Below  is the reason
Disadvantage of strict ccTLD implementation :
For eg: We need to know about a company which is located in Germany, say BMW (wow!). As per the ccTLD basis the company site should be somewhat www.bmw.de . The question is, what if we never knew the location of company ? We will obviously not sit and try suffixing those 200 ccTLDs out there. The most obvious URL that we Internet users would type into the browser would be www.bmw.com since we know it is a commercial organization. So this is where the popularity of gTLDs  are exhibited. (Ofcourse with today’s search engines like google, we can manage to find that out. But what if it is the domain of a small store in an unknown country and we do not have the time to google it out ?)
Another fine eg would be this : In the U.S , the authority in charge of this domain chose to make it follow a strict geographical hierarchy, so every domain must be of the form “organization.city.state-code.US”. So, to use this part of the name space, a company “xyz”in Boston must be within the “xyz.boston.ma.us” domain. This format has made the name more longer and harder to guess. Further,  if you weren’t aware of the city in which the company is located,  it would have added to the trouble finding it out. Finally, the .US authority eventually abandoned the strict geographical hierarchy due to its non-acceptance.
IANA is responsible for management of the DNS root zone. The role is in assigning the operators of top-level domains, such as .UK and .COM, and maintaining their technical and administrative details.
Root Zone Database : IANA’s Root Zone Database contains the authoritative record of the operators of various top-level domains. The Root Zone Database represents the delegation details of top-level domains, including gTLDs such as “.COM”, and country-code TLDs such as “.UK”. As the manager of the DNS root zone, IANA is responsible for coordinating these delegations in accordance with its policies and procedures.
DOMAIN NAME REGISTRY, DOMAIN NAME REGISTRAR & DOMAIN NAME REGISTRANT
or  simply
REGISTRY, REGISTRAR  &  REGISTRANT
A domain name REGISTRY, is a database of all domain names registered in a top-level domain. A registry operator, also called a Network Information Center (NIC), 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 organisation 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. It is potentially distinct from a domain name registrar.
A domain name REGISTRAR is an organization or commercial entity, accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or by a national country code top-level domain (ccTLD) authority, to manage the reservation of Internet domain names in accordance with the guidelines of the designated domain name registries and offer such services to the public. Such a registrar is know as “Accredited Registrar” or “Designated Registrar”.
A domain name REGISTRANT is a person/organization who/which  owns a domain name in the webspace ( i.e. in the world of Internet) so that he /it can create a website and start sharing information on the Internet. Or going by the name, a registrant is the one which approached a registrar and has registered a domain name in his name and is the owner of it. Once became a registrant of a domain name, he is the sole owner of it and no other person on the planet can request for the same domain name in the Internet’s webspace or namespace until the domain name gets expired and is deleted from the registry thereby becoming publically available.
Did you know a few hosts out there, register the domain name in their own names and not yours ? Get the domains registered in your name.
Explanation
Please refer to the links for the list of gTLDs & ccTLDs. In the tables for gTLDs and ccTLDs, Sponsoring Organisation mentioned, is the “Domain Name Registry” for the respective domain. These organisations have been directly authorized by ICAAN to hold the Root Zone Database for the domains they are handling i.e. a  domain registry comes just  below the  ICANN/IANA  in the  DNS  authority hierarchy. One of the famous registry is “Verisign” which handles .COM and .NET domains, NeuStar Inc. for .BIZ etc. This means that they are the ultimate authority (excluding ICANN/IANA) for matters pertaining to the TLDs they handle.
In the young age of the DNS, they (Sponsoring Organisation) handled all the name registrations of the domain under their authority. Later on as the Internet became more crowded, the load on them increased. Further more, these organisations increased the charges for registration (Grreeed is human nature :-D ). So with the aim to increase competition in this field and decrease the rates, ICANN made the domain name registration more public i.e. they started lending out the registration right to other private firms. These firms will now have the power to register a domain name into the world of Internet. For this, they will have to register with ICANN for the TLD domain they are interested in. Once they get registered, they will be an ICANN “Accredited Registrar” or “Designated Registrar” or simply a “Domain Name Registrar” (eg: goDaddy). For becoming an accredited registrar, one need not contact ICANN directly. They will have to find out which is the “Domain Registry” for the TLD they are interested in and just register at the particular registry’s website. This is one of the main differences between a “registry” and a “registrar”. A particular TLD’s registry has the power to authorize a 3rd party as that TLD’s accredited registrar and people who wish to start a domain(or website) can buy a domain name from this registrar. One can become an accredited registrar for more than 1 TLDs. For eg : if a company needs to become the accredited registrar for the TLDs – .com , .biz  and  .coop , they will have to individually register with the : VeriSign Global Registry Services, DotAsia Organisation Ltd. and DotCooperation LLC respectively. Once they get registered  they attain the “Accredited Registrar” status for the TLDs .COM, .BIZ & .COOP. Their company name will automatically be entered into the “Accredited Registrar” list of ICANN. The company can then go onto provide domain names under .COM, .BIZ & .COOP to clients.
So the IANA/ICANN is responsible for  maintaining the DNS ROOT which is the upper-most part of the DNS hierarchy, and involves delegating administrative responsibility of “top-level domains”, which are the last segment of a domain name, such as .com, .uk and .nz. Part of this task includes evaluating requests to change the operators of country code domains, as well as day-to-day maintenance of the details of the existing operators.

NUMBER SYSTEM

IANA is responsible for global coordination of the Internet Protocol addressing systems, as well as the Autonomous System Numbers (ASN) used for routing Internet traffic. Just like maintaining the Name system, IANA has its subsidiaries for looking after the Number system.
The IP address is a Number resource that IANA manages in addition to many others. The task of assigning IPv4 and IPv6 to the end user in Internet is done in a 2 level hierarchy :
Level 1  : RIR – Regional Internet Registry( there is no such technical term for this hierarchy separation as “level 1″ & “level 2″…just mentioned for clear understanding)
The RIRs manage the allocation of IP addresses on a continent basis. These RIRs have the authority to re-allocate them within their respective geographical areas (of continental scope). There  are accordingly  5  RIRs covering the whole globe. The RIRs are the ones which are directly below the IANA in hierarchy. They are :
AFRINIC (for African Continent) : AfriNIC is a non-government, not-for-profit, membership based organization, based in Mauritius that serves the African Internet Community. AfriNIC is the Regional Registry for Internet Number Resources for Africa.   (http://www.afrinic.net)
APNIC ( for Asia Pacific region) : APNIC is a not-for-profit organization providing Internet addressing services to the Asia Pacific. It includes India , China , Japan, Aus etc..http://www.apnic.net/)
ARIN (North America Region) : American Registry for Internet Numbers (ARIN). It covers USA, Canada etc…(https://www.arin.net)
LACNIC (Latin America and some Caribbean Islands) : It is a Latin American and Caribbean Islands Internet Registry. (http://lacnic.net/)
RIPE NCC (for Europe, Middle East and parts of Central Asia) : Réseaux IP Européens Network Coordination Centre. (http://www.ripe.net/)
Level 2 : NIR – National Internet Registry
( this is an intermediate registry only for APNIC. for other RIRs it will have another name. )
The NIR is an organization directly under the umbrella of a RIR with the task of coordinating IP address allocations and other Internet resource management functions at a national level within a country.
The following NIRs are currently operating in the APNIC region:
* CNNIC, China Internet Network Information Center
* JPNIC, Japan Network Information Center
Level 2 : Local Internet Registry or Internet Service Provider
( this is again level 2 since it is for RIRs other than APNIC )
An Internet Service Provider(ISP) , also sometimes referred to as an Internet Access Provider (IAP), is a company that offers its customers access to the Internet. The ISP connects to its customers using a data transmission technology appropriate for delivering IP datagrams as dial-up, DSL, wireless or dedicated high-speed interconnects. In India we have the following ISPs : BSNL, Reliance, TATA etc..
And finally from the organisations in the Level 2 we the end users get the connection.
Thus in the paragraphs above we saw the authority hierarchy in the management of Internet’s NAMES & NUMBERS.
In addition to this IANA also directly manages  :
1) .INT : designed for the sole use of cross-national organisations, such as treaty organisations, that do not naturally fit into a specific country’s top-level domain. For example, the World Health Organisation uses who.int for its Internet presence, whilst NATO uses nato.int
2) .ARPA : The .arpa domain is used internally by Internet protocols, such as for reverse mapping of IP addresses
3) IDN Practices Repository : Internationalized domain names are domain names represented by native language characters. The native language domain name will be followed by .com or .net. IANA maintains a collection of “IDN tables”, which represent permitted code points (letters) allowed for Internationalised Domain Name registrations in particular registries
4) Protocol Assignments :  IANA is responsible for maintaining many of the codes and numbers contained in a variety of Internet protocols.
Note : Having understood all these one might still wonder the difference between IANA & ICANN. IANA is one of the Internet’s oldest institutions, with its activities dating back to the 1970s. Today it is operated by ICANN, an internationally-organized non-profit organization set up by the Internet community in Sept. 30 1998 to help coordinate IANA’s areas of responsibilities. Thus basically there is no difference between them. So their names are used interchangeably in many contexts.

The domain name to IP resolution process

ROOT NAME SERVERS
The process involved in the resolution of a Domain Name to IP is a very complex one when comparing to the time it takes to do that. We type name of the website into the browser, gets converted to IP and there we have it ! All of it just happens in a fraction of a second. This document is intended for all those who would like to know the processes happening in this split time. The explanation of this process would be incomplete if I do not brief you about ROOT NAME SERVERS which are at the top of the DNS tree.
The Operators
Root servers are operated by twelve organisations often referred to as the “root server operators”. They are
A – VeriSign Global Registry Services
B – Information Sciences Institute
C – Cogent Communications
D – University of Maryland
E – NASA Ames Research Center
F – Internet Systems Consortium, Inc.
G – U.S. DOD Network Information Center
H – U.S. Army Research Lab
I – Autonomica/NORDUnet
J – VeriSign Global Registry Services
K – RIPE NCC
L – ICANN
M – WIDE Project
The letters A-M represent the 13 numeric IPv4 addresses at which the service is provided. These 13 IPs correspond to servers located at about 130 physical location around the globe in about 53 countries. These servers contain a file called ‘root.zone’ which makes them special. The root zone file lists the names and numeric IP addresses of the authoritative DNS servers for all top-level domains (TLDs) such as ORG, COM, NL and AU. There are currently 13 root-servers ( to be more specific, 13 IPs . The number of individual machines mapped with these IPs are more than 150 !)worldwide, described in further detail later in this chapter. The IPs of root-servers are known to every name server in the world using a special zone file, which is distributed with all DNS software.
Below is the general implementation of the DNS and position of the root servers :
The black spots denote authoritative NS (name servers) for the domains beside them.
The Purpose
Each domain name in the Internet name space will have at the least 1 authoritative NS associated with it (the accepted convention is to have at least 2). This name server will be the one which helps to resolve this domain and the and the domains under it ( sub-domains, add-on and parked ) to an IP. It does it by having a “Zone File” of the particular domain. In the Zone File will be an entry called the A Record which maps the domain name to an IP ( a much more detailed explanation on this resolution process will be dealt with in PART II of this document ) . So when we type in a domain into the web w browser, it will be resolved to an IP only if the query from our machine reaches the authoritative name server. But how does this query reach the correct name server ? This is where the Root Servers come into play. But as I mentioned, these servers are not contacted every time IP for a domain is queried. There are some mechanisms called “Caching” which helps to store the NS of a domain once it is queried for the first time.
You may find the root servers locations from this site :
It is a good one!

DOMAIN NAMES


Before I go on to the query process, I would like to present a small briefing about Domain Names :
The Domain Name System uses a tree (or hierarchical) name structure. At the top of the tree is the root node followed by the Top-Level Domains (TLDs), then the Second-Level Domains (SLD) and any number of lower levels, each separated with a dot. TLDs are split into two types:
1. Generic Top-Level Domains (gTLD): For example, .com, .edu, .net, .org, .mil, etc.
2. Country Code Top-Level Domains (ccTLD): For example, .us, .ca, .tv, .uk, etc.
For instance abc.com, is actually a combination of an SLD name and a TLD name and is written from left to right with the lowest level in the hierarchy on the left and the highest level on the right:
sld.tld
The term Second-Level Domain is technically precise in that it defines nodes at the second level within the domain name hierarchy. There are also Third-Level Domains, which are especially relevant with ccTLDS. Any name just which is to exist in the Internet’s name space just to the left of the gTLD or ccTLD ( i.e. SLD ) should be brought from an Accredited Registrar or simply, Registrar.
So what is www.abc.com?
From our reading previously, we can see that if we assume a domain name www.abc.com, is built up from www and abc.com. The domain name abc.com part was delegated from a gTLD registrar, which in turn was delegated from ICANN. The owner of the domain chose the www part since they are now the delegated authority for the abc.com domain name. They own everything to the left of the delegated domain name, in this case abc.com *. The leftmost part, the www in this case, is called a host name. Keep in mind that only by convention do web sites use the host name www (for World Wide Web), but a web site can be named efg.abc.com—few may think of typing this into their web browser, but that does not invalidate the name! Every computer that is connected to the Internet or an internal network and is accessed using a name server has a host name.
Consider some examples:
www.abc.com  a company web server
ftp.abc.com  a company file transfer protocol server
pc17.abc.com  a normal PC
A host name must be unique within the delegated domain name, but can be anything the owner of abc.com wants. Say, he can make ftp.abc.com as the web server. There is no protocol or convention to name web servers starting with www. It is usually given for better understanding that the name starting with www will be the web server and that starting with ftp will be the ftp server.
One more thing to note is that q1.abc.com & q2.abc.com need not be 2 different hosts (separate machines). It can also be 2 different sub-domains of abc.com on the same host!
To summarize: the owner can delegate, in any way they want, anything to the left of the domain name they own (or were delegated). The delegated owner is also responsible for administering this delegation.
* For .name TLD, the registry handling it, Verisign Inc., places some restrictions regarding the registration of third level domain names and it’s ownership. You may find further details on it at :
http://www.verisign.com/domain-name-services/domain-information-center/name-faq/index.html

THE PROCESS

When we type in a domain name to the browser the ‘Resolver’ program (the client-side of the DNS is called a DNS Resolver) is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, i.e. translation of a domain name into an IP address) it will consult a NS for the IP. For the resolver to consult, it’s IP(NS’s IP) will be provided in /etc/resolv.conf file in linux machines.
Consider that we want to resolve www.abc.com. Let it be the web server of the domain abc.com (a separate host machine) and a website hosted on it. Also consider that it has ftp.abc.com as its ftp server and many others. When the resolver query reaches our NS there are 3 possibilities to consider :
(i) the information about the particular domain is already cached
Consider that another machine using the same NS as ours had queried for www.abc.com and resolved successfully to an IP. Since ours is caching NS it will cache (store) the IP of both the domain & NS which contained the ‘A’ record for www.abc.com (this is called the Authoritative NS for the domain abc.com). So next time when any other machine queries this NS for www.abc.com , it will directly take the IP from the cache and display the website. So caching helps to reduce the load on other DNS servers to high extent since DNS queries do not go beyond the caching NS.
(ii) no ‘A’ record information in the cache
If the caching server does not find the answer to a query in its cache, it has to find another DNS server that does have the answer. In our example it will look for a server that has answers for all names that end in ‘abc.com’. In DNS terminology such a server is said to be “Authoritative” for the “domain” ‘abc.com’(as I have mentioned earlier).
In many cases our caching server already knows the address of the authoritative server for ‘abc.com’. If someone using the same caching server has recently surfed to ‘ftp.abc.com’, the caching server needed to find the authoritative server for ‘abc.com’ at that time and, being a caching server, naturally it cached the address of the Authoritative server. So it will directly contact this NS and get the A record (IP) for ww.abc.com
(iii) the NS cache is completely empty
This is the situation when the NS has just been set up and the cache is completely empty, Consequently it neither knows the answer to your query nor does it know where the authoritative servers for ‘abc.com’ are. However it does know that it is possible to ask questions for ‘abc.com’ to an authoritative server for ‘com’. As per the DNS protocol : “In case authoritative servers for a name are not known, strip off the leftmost part of the name including the first dot and send the original query to an authoritative server for that name”.
One main point to note: In our example an authoritative server for ‘com’ does not know the answer to a query about ‘www.abc.com’, because the ‘abc.com’ servers hold that information, but it does know which servers are authoritative for ‘abc.com’ queries. So instead of an answer to the query, the ‘com’ server will answer with the list of authoritative servers for ‘abc.com’, a referral in DNS terminology. Then the authoritative servers for ‘abc.com’ will give the IP for ‘www.abc.com’ or ‘ftp.abc.com’. In addition, being a caching server, it will cache both the answer and the list of authoritative servers for ‘abc.com’ for further use.
But hold on, we assumed the cache was empty in the first place, so how does our caching server know where the authoritative servers for ‘com’ are? In other words what happens once we have stripped off all parts of a domain name and still do not know where to go for an answer?
For this case there is a special set of authoritative servers, the DNS root servers or simply ‘Root Servers’. They know the addresses of all authoritative servers for names that do not have a dot in them, the Top Level Domains (TLDs) such as ‘org’, ‘com’, ‘ch’, ‘uk’.
Root servers are the only DNS servers that have to be found without any other information being cached. To solve this all servers in the Internet’s name space acting as a NS will have a pre-configured list of numeric addresses for all root servers. This list is embedded with the NS software (BIND etc.). When starting up, a caching server will send queries for the current list of root servers to each of these addresses in turn until it obtains an answer. Once it has obtained the current list, it knows where to send queries for names without dots.
So here is what happens:
When a caching server that just started receives a query for the address of ‘www.abc.com’. After it started, the server obtained a list of root servers and their addresses. When the query arrives it will not find the answer for ‘www.abc.com’ in the cache, nor will it find the address of an authoritative server for ‘abc.com’, neither the address of an authoritative server for ‘com’. Having no other choice it will then ask a root server for the address of  ‘www.abc.com’. The root server are authoritative for TLDs i.e. they have the answers for the list of Authoritative NS of the TLDs. So when our query for ‘www.abc.com’ reaches the root servers it will strip off the part for which it is not authoritative. So ‘www.abc’ will be stripped off. The remaining part of the name is ‘.com’ and it is authoritative for that. So it will answer with a referral containing the list of all authoritative servers for ‘.com’ TLD. This list of NS for ‘.com’ domain will have the list of NS for all the SLDs under ‘.com’. Our caching server will then send its query for ‘www.abc.com’(please note: always it sends a FQDN) to one of them and they will strip off ‘www’ and we will get another referral with the list of all authoritative servers for ‘abc.com’. When sending the query to one of them it will get the answer (IP of www.abc.com). All this typically happens in less than a second.
From here on the caching server can answer the same query again and again from the cache without asking another server. It can also send any query for ‘ftp.abc.com’ or ‘something.abc.com’ directly to an ‘abc.com’ server and send any question for another name ending in ‘.com’ directly to a servers authoritative for ‘.com’. Only when the next query ends in something different from ‘.com’ does it have to ask a root server again. Quickly the cache will contain lists of authoritative servers for all popular domains, especially for all popular TLDs; usually our caching server will not have to query for this information again for several days. This design ensures that only a tiny fraction of all queries will have to be processed by the root servers or by authoritative servers for TLDs.
Below is a pictorial representation of the above :
So this is the process regarding the name to IP conversion. I hope you have gained a basic understanding.
Note: Please note that when a query goes to any NS including the root servers, the FQDN-Fully Qualified Domain Name is sent, i.e we query the root servers for the Authoritative NS for ‘com’ TLD. For that, the resolver does not particularly send ‘com’ in it’s query. It sends the complete domain name for which it needs the IP. www.abc.com is a FQDN but abc.com is not. A FQDN is the complete name containing the hostname, domain name and TLD. It is then the duty of the particular NS to strip off the part of the domain name for which it is not authoritative and then provide the answer to the query for the part for which it is authoritative.


As I have mentioned in the above paragraphs, all the NS in the Internet will be aware of the IP of root servers. This information is provided in a file which comes along with the name server software package. The file is named.root or named.ca (it varies). This file is called the Root Hint file. It holds the name of the root servers and the corresponding IP at which it should be contacted. This file is usually located in /var/named as named.ca or named.root (if the NS package is BIND). I have attached below a screen shot of a part of the file.
Here you may see the name of the root server to the left hand side and its IP to it’s right. The list I have put here has the severs up to D only. This list continues till M ( M.ROOT-SERVERS.NET.) .
The IP of these root servers do not change frequently but it does, once in while. Thus no one cares to update this file. So it is advisable to update this file for anyone running a busy NS. You can easily fetch this file with a dig utility:
dig @a.root-servers.net . ns > root.hints
or
dig @a.root-servers.net . ns > named.ca
You can easily set-up a crontab entry to perform file update once in month.
What makes Root Servers so special than other servers?
The key file that makes root servers so special is ‘root.zone’. This is contained in all the root severs from A – M. You can download this file too and view it ! Just note the screen shot in the above page. Two ftp servers are mentioned in the top : FTP.INTERNIC.NET & RS.INTERNIC.NET . Just do an ‘anonymous’ ftp to the above server and get the file by navigating to the specified directory. I have attached a screen shot of a part of it below.
In the two screen shots, we can observe the name of the Authoritative NS for the gTLD ‘.com’ and ccTLD ‘.in’ . These Authoritative NS for ‘.com’ and ‘.in’ will have the IP of Authoritative NS for the domains ( second level or third level ) under it. Similarly all the existing ccTLDs and gTLDs have an entry for their NS in this file.
Now you might wonder: Only the names of the authoritative servers are mentioned here and where to get the IP of these? You need not worry. The IPs are mentioned in the same file after listing NS for all the TLDs. To make things clear I have put a screen print below:
The above is an entry in the same file ( root.zone). A.GTLD-SERVERS.NET. is an Authoritative NS for .com TLD. It’s IPv4 and Ipv6 addresses are mentioned. Similarly, there will be an IP entry for all the all the authoritative name servers for all the TLDs.
Please Note: I recommend the reader to compare the above informations with PART III of this article. It will help in clear understanding.
Okay. Then who updates this root.zone file?
In 2004, ICANN took over responsibility for the maintenance of the root- servers TLD master file—the file that lists the authoritative servers for each TLD. Distribution of this file to each of the operational root-servers is carried out using secure transactions. To further increase the security, the server providing the root updates is only accessible from the operational root-servers. It is not a publicly visible server.