Skip to main content

GOV.IN (A Domain Reserved for Indian Government): Managed and Run by U.S. based Company


Recently, after Edward Snowden disclosure about the NSA activities about spying on whole internet and of against all major countries of the world (which includes Britain, France, Canada, German and others), whole world rethinks about the privacy and content security of online data.

India’s condition is also no more different. Our government also brings law for the content security and individual privacy in online world. One such law states, Government content should be hosted/kept in Indian Territory only.

.IN is the ccTLD (Country-Code Top Level Domain) of India and GOV.IN domain is reserved for hosting (or providing services) the government websites and there related stuffs only. Few such websites hosted in gov.in domain are:-

     1.    India.gov.in
     2.    Mail.gov.in
     3.    Incometaxindia.gov.in
     4.    Drdo.gov.in
     5.    Barc.gov.in

The websites mentioned above and all other *.gov.in websites (or contents) is accessible till gov.in domain is accessible (which in turn is available till .IN domain is up and running).
.IN is the first level domain and .GOV.IN domain is the second-level domain in the hierarchy of internet and all websites under .GOV.IN domain comes under third-level domain. 

Hierarchy level of *.gov.in. domain


In hierarchy level, .IN is the first level domain, which runs by NIXI (who in turn outsource the same to Afilias, a U.S. based company).
.GOV.IN is the second-level domain (reserved for Government stuff) and is managed by Afilias (as clearly visible in below pic), and the hosting of all the domains/websites under gov.in domain is managed by NIC (National Informatics Centre).



In internet world, every domain depends on its parent domain for its availability and accessibility. This means, all Indian government online content is available to general Indian public (incl. all common and government personal) as long as .GOV.IN domain is up and answering correctly.
Indian government has setup various IT departments (incl. NIC, C-DAC and others) for helping out the government in IT related stuff, in managing government online content (and its other interest) and for R & D purposes. NIXI is a non-profit company works under DEITY (Min. of Communication and IT) which manages the .IN domain and recently becomes the LIR (Local Internet Registry) for managing and distributing the IP number resources to Indian organization.

.IN domain is managed by NIXI and NIC is the Registrar for .GOV.IN domain (i.e., responsible for all the domains entry under .gov.in domain). Nameserver are the one which owns the Name-to-IP resolution & IP-to-Name resolution for a domain. A domain is accessible as long as its corresponding Nameservers are responding and answering properly. When we access any website (or any other content) over web, first thing which happens is DNS resolution because machine only understand IP numbers and they can only bring the content, if they get the desired IP for that domain.

For e.g.:-
For accessing www.india.gov.in in a browser, my machine will first asks for IP number of india.gov.in from DNS Server (which is 164.100.129.97) and then send a request packet for www page of www.india.gov.in to its IP address. Server will responds with the web page of the same. In this whole process, DNS Name Resolution is the key thing on which whole internet depends. There are 2 possibilities in Name resolution where I can face an issue:- 
·         DNS is not responding
·         DNS is replying me with a wrong answer ( DNS Hijacking)
In first scenario where DNS is not responding, I will not be able to access the content and browser with throw the “Page Not Available” error.
In Second case where DNS is misbehaving (or replying me an error answer), I will browse the wrong page and it may cause a serious threat to user content/credentials security. Credentials hijacking of bank account is the best example of the same (by page or DNS spoofing).


.GOV.IN domain is managed by Afilias, a U.S. based company (NSA is also a U.S. organization) having expertise in managing domains and ccTLD’s (Although we have NIC, C-DAC and others which can manage .GOV.IN domain but the task has been outsourced to Afilias).

Now first thing which comes in our mind after seeing this is why a domain which is specifically reserved for Indian government usage is managed by any foreign organization??

What impression/message our government is sending to whole world. Are we not capable enough to manage even a single domain which is there for our governmental purposes?

Till now we talks about the image of our country and our capability. But there is another bigger technical issue related to this. Let consider a case where our relations with U.S. got hampered due to any issue whatsoever it is, and they impose sanctions on India & blacklist us and ask all U.S. companies to stop serving us and immediate disconnection of their services to all Indian government organization and attached offices. What will happen in that case?

As .GOV.IN domain is managed by Afilias (a United States company, which is bind with their laws and judiciary), and if Afilias was forced by their government for stop serving the Name Services (i.e. DNS Services) to Indian government, then our whole *.GOV.IN domain will be out of whole internet network and we will not be able to browse or access any services (be it www or mail or any other) which are hosted on .GOV.IN domain.

A total blackout of Indian government domain (i.e. .GOV.IN domain) from the Internet and this is only because of our dependency of foreign companies (in this specific case, because of our dependency on Afilias).

Shouldn’t our domain or any other mission critical services should be run and managed by ourselves only. Aren’t we are not capable to handle and run our show.

If not, then what’s the need of NIC and C-DAC (in this particular case)?


Popular posts from this blog

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a