What is the secret?

[FC Domains]

So what is the secret?

By monitoring DAC and sending an email it seems impossible to catch a valuable domain. In fact one TAG is catching almost everything worth having. This is obviously not possible, if the system is working the way that Nominet tells us.

I'm assuming that on some days there will be a number of catchers all going for the same LLL domain and we all have systems that can send an email in under 20mS. You can only hit DAC every 125mS, so even if you had the best system and could send a request instantly, you would only expect to get about one in four at best, not all of them.

So there is a flaw somewhere in Nominet's system and somebody has found it. Maybe that's fair enough, but Nominet refuse to discuss it.

(Please don't mention TAG names or this topic will get moderated.)

 

[grantw]

I've run out of ideas now to try and beat the top two catchers, I can check/send request in well under 20ms and get beaten every time on the top names, even when I'm hammering the dac at 60ms??? Beyond me!!

Grant

 

[bb99]

If you read this post, it suggests that the answer lies in knowing the best time to send your request.

If everyone is sending REQUEST emails at the same lightning fast speed (which they may not be), then the answer surely lies in getting the timing right.

The post I link to above suggests that you can't work out the correct timing with only one DAC subscription. I wouldn't know anything about that.

I think it's all down to guile, cunning and research

 

[retired_member12]

Have you studied the exact drop time (if it is known) of a number of the domain names, relative to the second (atomic, etc)? Can you sync with Nominet's clock to a certain time frame within each second? Does Nominet drop half way through a second, or at some other point?
Just some thoughts from a non-TAG Holder.

 

[paul]

Or could it be queue jumping

 

[paul]

or maybe doing something to the requests in the queue in front that slows them down

 

[yesterday]

blurb and probably useless garbage but deleted anyway

yesterday

 

[retired_member2]

So what is the secret?

Now if they told you, they would have too kill you

Do you honestly think if someone can catch say for example a domain thats worth maybe £1,000 or more too them that they would tell anyone their secrets?

I could tell you and 1,000,000 other people the secret for £10 so you can make millions which is crap as the only person getting rich would be me from selling those one million secrets too people who want too know.

If you could make gold from your tap water would you honestly tell anyone else how to do it?

Regards

Mark

 

[Paullas]

i know many tag holders who have contacted nominet over it and nominet never reply so i would say yes they know and no they are not bothered as they have a zipped mouth approach to it.

maybe there system fix (cough cough) in june will solve it..

 

[paul]

My guess is when the epp is introduced the advantages will be lost, but what do I know

 

[aquanuke]

maybe there system fix (cough cough) in june will solve it..

Theres no DAC involved in that though is there ?

 

[aquanuke]

My guess is when the epp is introduced the advantages will be lost, but what do I know

My initial thoughts on the EPP would be its slower. Are there any beta testers on here, or is it too soon?

 

[Paullas]

Theres no DAC involved in that though is there ?

http://www.nominet.org.uk/registrars/systems/auto/

not sure to be honest but there is the link i got from them when i asked what changes are being made.

 

[aquanuke]

umm.. I suppose someone needs to calculate how long it takes to verify a PGP sig compared to passwd verification. Passwd should be faster but the EPP request seems rather bulky.

 

[richard]

Believe me or not. its your choice...

It was mentioned to me that the advantage is caused because of a unavoidable lag in the oracle database; essentially as the domain delete request is initiated on the database it takes a fraction longer to respond to dac queries due to the domain going through the deletion process; this fraction delay can then be used to prefire off the register requests. This is not fixable in its current form due to it being an oracle db issue

I gave up bothering with the DAC a long time ago once I found this out

 

[yesterday]

Thanks Richard,

Now delete your post :-D :twisted:

yesterday

 

[Slater]

Believe me or not. its your choice...

It was mentioned to me that the advantage is caused because of a unavoidable lag in the oracle database; essentially as the domain delete request is initiated on the database it takes a fraction longer to respond to dac queries due to the domain going through the deletion process; this fraction delay can then be used to prefire off the register requests. This is not fixable in its current form due to it being an oracle db issue

DAC response times are not fixed and fluctuate all the time, you would soon use up your registration quota if you fired off a domain request each time you detected a fluctuation.

I have run tests recently by using my entire 1000 queeries a minute DAC quota in a 6 second burst on the off chance that the domain dropped in this 6 second window, have had a domain drop in this window on a couple of occasions and was still beaten by one of the top catchers.

I beleive there probably is a way of pre-empting the domains drop prior to it showing up in the DAC but I'm buggered if I can find it.

 

[Pred]

maybe insider info came into play?
i'm a non-tag holder i don't give a monkey's , but it's not beyond the realms of possibility a Nominet i.t. engineer could be 'got at' lol
Let's get the conspiracy theories rolling, lol

 

[static]

If you blast off at a rate that exceeds the limit you will be blocked. However, requests received after the block begins are not rejected. When the block is lifted these requests are then duly processed. So, if you know when a domain is going to cancel you blast off to induce a block that is precisely calculated to lift just before the domain cancels. In this way the requests are already waiting at the server.

 

[aquanuke]

If you blast off at a rate that exceeds the limit you will be blocked. However, requests received after the block begins are not rejected. When the block is lifted these requests are then duly processed. So, if you know when a domain is going to cancel you blast off to induce a block that is precisely calculated to lift just before the domain cancels. In this way the requests are already waiting at the server.

There is a rule that if you over block you will get your account suspended.