New Nominet Drop Process - 13th Sept 22

[Transcom ISP]

Well time is looming, so heres an update on whats going to change.

In basic terms, Nominet will now publish the drop date and time for 65 days after the expiry date grace period of 30 days, ie, t(otal 95 days), then it will drop at that precise moment, this stamp is available through the EPP Domain:check lookup, and also on the new RDAP server (not available yet).

For catchers, the important part is the pending delete grace period, the last 5 days, where the domain cant be renewed, and will therefore inevitably drop without fail.

This now means that the entire drop catching comminuty will be hitting the DAC and EPP servers at the exact same time, (can the pipe take this ?) and for a single tag / dac holder this is 1000 lookups within a one minute period. (so those with multiple tags still have an advantage)

Our Software
What does this mean for our current software, nothing at all, it will still function as it does now, but the user source of drop information is direct from Nominet, with all the dates and times, but we will add a burst parameter to enable max hits if required.

Backorders
Some nice changes here, as well as the current event stamp, an RDAP drop stamp will also be shown when a user enters a domain to catch, and the database will be polled continuosly to place dropping domains in the queue at the precise moment for execution by the dropcatch servers.

Hope this helps
Bill

 

[webber]

This now means that the entire drop catching comminuty will be hitting the DAC and EPP servers at the exact same time

The DAC will no longer be of any meaningful use in the dropcatching process following the Production and OT&E release (2022-09-13) of the new domain expiry process and droplists for .uk
In fact Nominet is hoping that the resources made available by dropcatchers no longer hammering the DAC will allow them to increase other limits like the epp <domain:check> after the 3 months review of the new process.
Please see this post from Nominet staff:

1. There is now a known drop time when each domain becomes available for re-registration, irrespective of whether the actual purge of the domain has completed.
2. EPP domain:check will show a domain as available after its drop time, even if the purge of the actual domain is still to process.
3. EPP domain:create will still succeed after its drop time, even if the purge of the actual domain is still to process - essentially the CREATE command completes the drop.
4. In contrast, WHOIS, RDAP and EPP domain:info will still show a domain as registered until purge is complete; remembering that purge can be triggered by a CREATE.
So, the thing to test is not around the drop per se, but the ability to target a specified CREATE timestamp. If you can successfully achieve your targeted timestamps then you are in with a chance.

So the current method of checking a domain is available via DAC before sending the EPP <create> will become obsolete. While you could still do this exclusively via the EPP using <domain:check>, in practice this will probably mean your <create> commands will be sent quite a bit later than everyone else's. The best method, as far as I can see right now, is to work out the time offset between your server and the EPP server and calculate the latency of your connection, then fire the <create> at the correct time accounting for these variables.

Also,

for a single tag / dac holder this is 1000 lookups within a one minute period. (so those with multiple tags still have an advantage)

That's not correct now, nor will it be after September. There is no advantage for multiple tag holders in regards to the DAC as you suggest. The DAC quota and rolling limits are per account (or linked accounts), not per tag.

Hope this all makes sense.

 

[Transcom ISP]

Thanks, correct in a sense, but Nominet actaully say :

"The real-time DAC and time-delayed DAC will continue to operate as they do today. However, we recommend the usage of both drop lists and EPP <domain:check> responses to confirm drop times because they will provide you with the UTC timestamp a drop will happen."

So theres a choice, hit the EPP $register on a response change (as now) with max under the allowable use policy
or
hit the EPP $resister based on the drop time with max under the allowable use policy

With the dac, theres the added $result (as the software does now) with pre calucating any propogation delay and hence the timing to prevent wasted EPP hits.

On your second answer, again correct,

however, each TAG has to adhere to the AUP not only for DAC (if used) but for EPP as well, whch is "not exceed 1,000 in any 24 hour period", so , if someone has multiple tags under different names (god forbid...) this is TAG's x EPP allowance , so if used on the same domain, theres still a big advantage.

Of coures, any one with a single TAG is probably not going to use 1000 EPP hits for one domain in 24 hrs

Cheers
Bill

 

[super-whois]

So theres a choice, hit the EPP $register on a response change (as now) with max under the allowable use policy

That's not what they say, domain:check will give the time it will be available for registration, this could be in the past if the domain hasn't been purged yet. The old registration will purge as part of the create command once that time condition is met.

 

[Transcom ISP]

according to them, the Domain:reason within the check xml of EPP Domain:check will vary in realtime as below, the change of date and DAC status will occur precisely on re reregistration, as now.

1. Registered and > Expiry Grace > 30 days > unavailable reason = Registered DAC = , Y,
2. 60 days redemption grace > Domain:reason = 'May Drop' (can be renewed) DAC = , Y,
3. 5 days pending delete > Domin:reason = 'Drop' (cant be renewed) DAC = , Y,,
4. On precise drop date/time > DAC = , N,, on drop
5. On register ? DAC = , Y,,

Line 4/5 are as present, it seems this will not change, but who knows !

Theres is no real reason to use the DAC anymore for the catch mechanism, when everyone under the sun will be bombing the EPP server with $register requests just based on the Domin:reason, but, it does have significnt use in determining EPP stream release per socket / network timing.

 

[webber]

1. Registered and > Expiry Grace > 30 days > unavailable reason = Registered DAC = , Y,
2. 60 days redemption grace > Domain:reason = 'May Drop' (can be renewed) DAC = , Y,
3. 5 days pending delete > Domin:reason = 'Drop' (cant be renewed) DAC = , Y,,
4. On precise drop date/time > DAC = , N,, on drop
5. On register ? DAC = , Y,,

What is the source of this?
As I understood from April's post and Barbara's webinar, the DAC/Whois/Rdap could still show the domain as registered until it is purged (ie a <create> command is received), though April hasn't specifically mentioned the DAC, so I might be wrong

WHOIS, RDAP and EPP domain:info will still show a domain as registered until purge is complete; remembering that purge can be triggered by a CREATE.

 

[ukbackorder]

When everybody gets round to using the testport they might find the answers to their questions/suppositions - some are right.. some are wrong currently However I doubt that in reality the test port is going to bear any resemblance to the live port. It didn't with the UK launch.

 

[Transcom ISP]

mm, very interesting.. some of the information came from here , you will see close to the bottom it mentions the DAC's operation to remain as it is today, but, they reccommend using the EPP domain:check and lists instead, as the source of drop times.

Could all change of course...

Im wondering what will happen to the prop delay when their EPP server gets millions (literally) of EPP register requests at precisely the same millisecond,

will it fall over ?, or will it inhibit long delays ? we cant forget that we only get 1000 EPP fail requests per day per TAG

 

[Transcom ISP]

What is the source of this?
As I understood from April's post and Barbara's webinar, the DAC/Whois/Rdap could still show the domain as registered until it is purged (ie a <create> command is received), though April hasn't specifically mentioned the DAC, so I might be wrong

spot on... the testbed currently runs fine in reality, its sure not to do so on production....

 

[lazarus]

I guess the DAC will still be available as it has other uses other than just drop catching.