Skip to main content

Shouldn't India have a Root Server ???

A Root name server is a name server for DNS root zone. Every new DNS query resolved by our local resolver first goes to Root Name Server and then root name server directs it to required domain server.

This means that if in any case, root name servers goes down, then whole internet goes down (don't worry this cannot be done so easily as most of root name servers are running on Anycast and located all over the world). Recently, an anonymous group posted, to target these 13 root name severs and to bring them down by DDOS attack on 31st March 2011, to protest against SOPA and PIPA. But as expected, they didn't succeed. The last time someone seriously tried to take out the root servers was about 4 or 5 years ago and they managed to take down six out of thirteen servers. I am not saying that it could not be done but it would be tough.

Every root name server is operated by different organization (except 'A' and 'J' which are operated by VeriSign) but they all point to 'A' root name server.
If any change needs to be done on root zone, it has to be done on 'A' and then all root name server will update its zone file through 'A'.
This creates a tricky situation because if the controllers of the root name servers decides to block any particular zone Or if they are forced to do so (may be in case of cyber-attack against any country or any similar situation), then that particular zone will be out of the whole internet.

Currently, there are 13 root name servers. The choice of 13 nameserver was due to the limitation exists in the DNS specification, which specifies a maximum packet size of 512 bytes when using UDP.
Root name severs are named in the form of, where letter ranges from A to M.

Out of 13 root name serves, 9 are running on Anycast. 2 root name servers are operated by U.S. Universities.
'B' operated by Information Sciences Institute of University of Southern California and 'D' operated by University of Maryland.

After the implementation of DNSSEC (DNS Security Extensions) and addition of IPv6 addresses for the root nameservers, 512 bytes limit doesn't remains valid and EDNS0 extension was added to DNS standard.

Now as previously exists limitation doesn't exist anymore, new root name servers can be granted by IANA.

There are approx. 2.27 billion internet users all over the world out of which 1 billion are in ASIA. And if figure out country-wise internet users, India has approximately 120 million internet users and china has 513 million internet users. On combining both of these, it comes out 633 million internet users, which is 28% of total internet users.

But the irony is, there are no Root name servers operated by any of these countries. Now the million dollar question is, shouldn't the IANA allocate new Root name servers as the limitation doesn't exist anymore after the EDNS0 extension to the DNS standards.

There are many things that goes against china, some are, it filters internet traffic and this is against the whole concept of internet itself, government influence over the internet and unpredictable behavior of government. so may be internet community shows reluctance in allocating new root name server to china.

But if we talk about India, it is the largest democracy of the world, a secular and sovereign country, has stable government since independence, ninth largest in the world by GDP, so it is the safe bet for allocation of new Root Name Server.

Shouldn't be IANA look into this and tries to decrease the internet infrastructure difference which exists between the North and the South????

Popular posts from this blog

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

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