Monitor your .IN whois

[phptech]

Or risk losing it on Feb. 28:

http://www.inregistry.in/policies/advisory_la02

 

[jaydub]

Wow...I will be interested to see if they follow through...
All my ducks are in a row.....
Nice "heads up" post phptech..

Jim

 

[mole]

What a mess.

 

[TLDnetworks]

Directi better get it in gear.... :td:

 

[phptech]

This should throw a wrench in Directi's auction grab

 

[-db-]

It has come to our notice that there are several domain names regarding which the actual Registrant's Contact details has not been provided by the Registrars. As a result there are number of domains where the WHOIS Database reflects that the domain is being held in the temporary account of the Registrars.

The Registrars are hereby informed to provide the data of the actual Registrants so that it is reflected in the WHOIS Database of the Registry. Registrars are given 10 days, up to 23:59 Indian Standard Time on February 28, 2005, to update the contact details of the Registrants. Failure to update all such domains regarding which the actual Registrant details are not given will be summarily deleted from the Registrars Account. In addition, other financial penalties and legal actions may be applicable.

Those of you that used Directi, is that what your domains currently show?

 

[mole]

Dear DirectI Reseller,

We have gotten the Live .IN Registration system to start working. We are still working on some minor bugs and further optimizations to improve the stability and speed of .IN registrations. We just wanted to update you that you should be able to register your .IN domains far more smoothly than what we had managed to put up yesterday.

For those of you, who are interested in knowing more about what went wrong - please read below:

1. Registry Connectivity Issue

The registry initially had a policy that each registrar can submit only 2 subnets to the registry from which they can connect to the registry. We used one subnet for our primary .IN pre-registration system and another subnet in a totally different datacenter in a totally different city for the backup system. Both of these were in India to ensure that we get a very fast connectivity to the registry. Towards the end, the registry changed this policy and allowed for 3 subnets, so we could add one more for our live registration systems which is hosted in the US. However, we did not submit the third subnet as we were concerned that the registry tech support may make some mistake which could stop us from connecting through our pre-registration systems too (we had reason to be concerned as we were aware of a mistake made by the registry while making a subnet modification during this period). We were told by the registry tech support team that they would add our subnet within 2-3 hours of us submitting the request. Due to this time frame given to us, we decided to request the addition after the registry goes live and our pre-registration system has completed its job (i.e. about 20-30 mins after the registry went live). When we submitted the new subnet to the registry, they once again confirmed that they would add this in 2-3 hours. However, after 4 hours, they changed this answer and said that it would take 24-48 hours. We don't really blame them as they too were bogged down with many requests. After calling the .IN registry tech support an unimaginable number of times we were told that the subnet was added (this was at about 3 am our time). However, there was some mistake made by them (thank god we didn't send this request before we completed pre-registration), which was rectified on Thursday afternoon. This is when we got connectivity to the registry.

2. Issues because of no of connections to the registry

Once we got connectivity through our live registration systems, we ran into some new road blocks for providing Live .IN Registrations.

A good number of check availabilities were failing with a status unknown error. This was primarily because we get 5 connections from the registry and if all these 5 connections are being used by people using the system, the rest of the people who click on check availability do not get a connection and hence our system throws a status unknown error.

We were facing this issue primarily because:

a. Load Balanced Architecture:

Unlike other .IN registrars who are using a single server for their live registrations - we have a load balanced system with 'N' Nodes - as a single machine is incapable of serving our requirements, 'cause we have a large number of customers and resellers using the system simultaneously. A user of our system is automatically forwarded to one of these nodes. Also, this helps in ensuring that if one server goes down, the system works normally for the users.

Each activity with the registry requires at least one connection. The issue with having a load balanced architecture when the no of connections provided is limited, is that - if node1 is holding on to 2 connections, node2 is holding on to 3 connections, then a user on node3 , node4 etc does not get any connections as the registry allows for a maximum of 5 connections

b. System built with the assumption of adequate connections:

Our system and code base for all TLDs is common. Until now we built it with an assumption that we will not run out of connections as all the other TLDs supported by us provide adequate no of connections. Due to this assumption, we use multi-threading to improve speeds and simultaneously open multiple connections to the registry for all actions instead of using one connection and sending one action after another.

We tried asking for more connections from the registry. However, we were refused as they currently have a policy to not give more than 5 connections per registrar (as compared to .com (100+ connections can be made)). We were told that any policy change will take a very large amount of time and could run into several weeks.

We then got a large portion of our development team to start re-coding the entire method we use for registration and management for .IN TLDs. Our development team, senior management, and system admin team has worked very hard since (they have practically had no sleep) in fixing these issues. This required some major changes in code which would typically take a real long time as the current system is extremely large and complex and re-writing large modules in this time frame has been a very difficult task for us. Due to the short time frames, we have not been able to do adequate testing, and are still fixing the minor bugs as and when the testing team is finding something.

After a lot of optimization and changes to the old code base we have reached the current stage. We are still working on some fixes and optimizations and hope to have these too on live soon.

Warm Regards

DirectI Tech Support

 

[phptech]

Those of you that used Directi, is that what your domains currently show?

Yes, see: http://www.directi.com/in_notice.htm

 

[IAmAllanShore]

So .in gets off on a "pissy" note, although I do understand their concern, I s'pose.
-Allan

 

[phptech]

In case we have successfully registered a domain for which we have received multiple applications - as announced earlier on, we were going to allot domains using a silent auction.

However, we have received a notification from the .IN Domain Registry (Advisory No. LA 01) in the last 24 hrs stating that .IN domain registrars cannot auction or sell .IN domains at prices higher than they usually charge from their customers.

Due to this notification we may no longer be able to use the auction process even though we do not wish to go back on the initial process that we had announced.

We are still finalizing the new allocation process after getting more clarifications from the registry. We will be posting an update once this process has been finalized by us. As of right now, we believe that we should be finalizing the allocation process by Tuesday, 22nd Feb and finishing the allocation latest by Friday, 25th Feb.

Refunds to Customers:

If the domain is not registered or not allotted to you, we will automatically credit your advance account with the FULL amount that you have paid for such unregistered domain name. All refunds will be credited to your advance account in less than 2 weeks from today.

In all fairness and perhaps even legallity, shouldn't they "allocate" domains according to the time stamps they were pre-registered? Registrants would need access to said time stamps though

 

[tinggg]

Don't know about names regged with Good Luck Domains when .in went live - but for those who pre-regged with them the WhoIs still shows the names still defaulting to GLD.

 

[wot]

The whois on all of my .co.in / .in show my details apart from 2 via Directi which will resolve this week.

www.TajMahal.co.in