CentralNic Drop Times for Secondary TLDs: When the Domain Deletes, How to Read the Schedule, and the Calmer Path to the Same Authority

· Last reviewed · 17 min read

A CentralNic drop time is the moment a registry running on the CentralNic platform, now part of Team Internet, purges an expired domain and makes it available to register again. For the secondary TLDs the platform is known for, the second-level names like uk.com, us.com, eu.com, and de.com, that moment follows a deletion lifecycle that differs from the .com schedule the headline guides describe.

The honest position is this. Done well, catching a CentralNic secondary-TLD drop means reading the registry’s real deletion schedule and being first in line at the instant of release. Done badly, it means guessing the time, racing a microsecond window you cannot win, and losing a name a faster operator already had queued. This guide explains the schedule both ways, and names the calmer alternative.

It also draws the line every generic drop-catching guide skips. The value you are chasing is an aged domain with inherited authority. You can race the drop for it, or you can buy the same kind of asset already screened. SEO Domains operates the curated marketplace where aged and secondary-TLD domains are vetted before they are priced, so the authority is sourced without the stopwatch.

What are CentralNic drop times, and why secondary TLDs differ

A CentralNic drop time is the scheduled instant when a registry on the CentralNic platform deletes an expired domain from its zone and reopens it for registration. For the platform’s secondary TLDs, the second-level .COM and .NET names, the lifecycle and timing follow registry-specific rules that sit outside the familiar Verisign .com schedule, so a drop-catching plan built for .com does not transfer cleanly.

The phrase carries two parts worth separating. A drop is the deletion event that returns a name to the available pool. The drop time is the schedule that deletion runs on, and that schedule is set by the registry operating the TLD, not by any single registrar.

The plain-English definition

Picture a domain whose owner stopped paying. It does not vanish at once. It moves through a fixed sequence of holding stages, and only at the end of that sequence does the registry delete it. The drop time is the appointment at the end of the queue when the deletion finally happens and the name is anyone’s to claim.

For CentralNic secondary TLDs, that appointment is governed by the registry behind those names. CentralNic, which became part of Team Internet in 2023, operates a registry platform that runs both its own second-level domains and a large book of new gTLDs and ccTLDs, each with its own deletion timing.

Why the secondary-TLD schedule is its own animal

The reason a separate guide exists is that the headline drop-catching literature describes the gTLD model and stops. DomCop’s drop-catching guide, a widely cited reference in the field, lays out the lifecycle in clear terms but states plainly that it gives no registry-level drop times and no CentralNic or secondary-TLD schedules. That is the gap this page fills.

CentralNic secondary TLDs answer to the registry’s own published lifecycle, which differs from the gTLD norm at specific stages. The CentralNic Reseller knowledge base lists uk.com with a 43-day autorenew grace period and a 43-day deletion timeframe, alongside a 30-day redemption period, a profile that does not match the Verisign .com cadence an operator assumes by default.

The domain deletion lifecycle behind every drop

Every drop sits at the end of a five-stage lifecycle: the domain is active, then enters an auto-renew grace period, then a redemption grace period, then pending delete, then it drops. ICANN policy fixes the redemption grace period at 30 days for gTLDs, the pending delete window runs five days with the drop almost always on the fifth day, and the EPP status codes signal each stage publicly. The drop time is the deletion event at the end of pending delete.

The five stages, in order

The sequence is the same across the gTLD world, and CentralNic secondary TLDs follow it with their own stage lengths:

  • Active. The owner holds the registration. Nothing is catchable.
  • Auto-renew grace period. After expiry, the registrar can still renew at the standard price. ICANN frames this window as up to 45 days; CentralNic’s uk.com profile sets it at 43 days.
  • Redemption grace period. The name is deleted from active use but recoverable by the prior owner for a high restore fee. ICANN requires gTLD registries to offer 30 days here, and CentralNic secondary TLDs publish a 30-day redemption window.
  • Pending delete. A locked five-day countdown. The name cannot be renewed, transferred, or restored. This is the stage drop-catchers watch.
  • The drop. The registry purges the name and reopens it. Availability returns in a fraction of a second, and the fastest queued request wins it.
DAY 0

Expiry. The registration lapses and the auto-renew grace period begins. The owner can still renew at the normal price. Source: ICANN expired registration lifecycle.

GRACE

Auto-renew grace period of up to 45 days for gTLDs, 43 days on CentralNic’s uk.com profile. Renewal here carries no penalty. Source: ICANN and CentralNic Reseller knowledge base.

RGP 30d

Redemption grace period. The name is gone from active use but recoverable by the prior owner for a steep restore fee, typically 100 US dollars or more. Source: ICANN redemption grace period policy.

PENDING 5d

Pending delete. A locked five-day window, no renewal or restore possible. The EPP status reads pendingDelete, the public signal drop-catchers queue on. Source: ICANN EPP status codes.

THE DROP

The registry deletes the name in a daily batch, almost always on the fifth pending-delete day, and the domain reopens for free registration. Source: registry practice and ICANN lifecycle.

Figure 1. The deletion lifecycle every drop sits at the end of, cited to ICANN policy and CentralNic’s published TLD profile rather than asserted. CentralNic secondary TLDs run this sequence with their own stage lengths.

The EPP status codes that signal each stage

The lifecycle is not hidden. Each stage publishes a standard Extensible Provisioning Protocol status code in the registry record, readable through WHOIS or its successor RDAP. The relevant codes are autoRenewPeriod during grace, redemptionPeriod during redemption, and pendingDelete during the final countdown. ICANN documents each code and what it means for the registrant and the watcher.

What “secondary TLDs” means on the CentralNic platform

Secondary TLDs, in the CentralNic context, are the second-level domains the registry sells as if they were top-level extensions: names like uk.com, us.com, eu.com, de.com, cn.com, and gb.net. They are registered under a parent .COM or .NET zone CentralNic controls, which is why their lifecycle answers to CentralNic, not to Verisign. The platform also runs a wide book of true gTLDs and ccTLDs with their own schedules.

The second-level .COM and .NET book

CentralNic’s distinctive product is a set of second-level domains that read like country or regional extensions. The current active book, per the CentralNic Reseller knowledge base and registrar identification guides, includes these under .COM and .NET:

  • Under .COM: uk.com, us.com, eu.com, de.com, cn.com, sa.com, gr.com, ru.com, za.com, br.com, mex.com, com.de, and jpn.com.
  • Under .NET: gb.net, uk.net, hu.net, and se.net.

A registrant of uk.com owns the second-level label under the uk.com zone, and CentralNic operates that zone. The registry, not Verisign, decides the deletion timing, so the drop schedule for these names is a CentralNic schedule.

CentralNic secondary TLD (e.g. uk.com)

A second-level name sold like an extension, registered under a parent .COM or .NET zone the CentralNic platform controls. Its deletion lifecycle and drop timing are set by CentralNic, with stage lengths such as the 43-day grace and 30-day redemption published in the registry’s TLD profile.

Standard gTLD (e.g. a .com)

A registration in the top-level .com zone, operated by Verisign. Its drop runs on Verisign’s batch schedule, the model the generic drop-catching guides describe. Knowing this schedule does not tell you a CentralNic secondary-TLD drop time.

Figure 2. The structural difference that creates a separate drop schedule. The registry behind the zone owns the timing, and for secondary TLDs that registry is CentralNic, not Verisign.

The sunset risk worth knowing

Secondary TLDs carry one risk a standard gTLD does not: the registry can retire the whole extension. CentralNic did exactly that on 30 April 2017, shutting down eight second-level .COM TLDs, ar.com, gb.com, hu.com, kr.com, qc.com, no.com, se.com, and uy.com, as reported by DNSimple. Existing names lost the right to renew past expiry, and no new registrations were allowed. A name in a sunsetted extension is not a drop opportunity; it is a dead zone.

This is the practical reason to verify a secondary TLD is still actively sold before building a catching plan around it. The lifecycle only matters if the zone still exists to drop into.

CentralNic drop-time mechanics and why the exact time varies

The exact clock time of a CentralNic drop is not a single published number. The registry deletes pending-delete names in a daily batch, and the precise second varies by registry, time zone, and batch cadence. The reliable signal is the pendingDelete status read through RDAP, not a fixed wall-clock time. A registry that publishes its schedule, like Registro .it, shows the concrete model CentralNic operators reverse-engineer.

Why there is no single CentralNic drop o’clock

Drop times vary, and they vary for documented reasons. NameSilo’s explainer on why drop times differ points to the core cause: each registry runs its own deletion batch on its own schedule and time zone, so the same lifecycle stage ends at a different wall-clock moment depending on who operates the zone. CentralNic publishes the stage lengths in its TLD profiles, but not a guaranteed deletion second, which is why operators monitor the status instead of setting an alarm.

The published-schedule model: what a transparent registry looks like

The clearest picture of how a drop schedule runs in practice comes from a registry that publishes it in full. Registro .it, the .it registry, documents its process in detail: at 01:00 CET each day it generates the lists of names that were in pendingDelete the previous day, publishes those lists immediately with each name’s exact cancellation time, and runs the actual drops twice daily at 09:00 and 16:00 CET. Once cancelled, the registry states, the names are immediately available for free allocation.

CentralNic does not publish a public drop list in that same consumer-facing form, but the .it model is the template operators use to reason about any registry drop: a daily batch builds from yesterday’s pendingDelete names, and deletion runs at a registry-set time. Read CentralNic’s pendingDelete signal through RDAP, and you are reading the same input the .it list is built from.

Where to read the signal

The CentralNic support knowledge base answers the practical question directly, pointing registrars to where a list of names about to expire can be found, and the registry exposes registration status through RDAP and WHOIS. For the timing of any individual name, the workflow is to read its EPP status, confirm pendingDelete, count to the fifth day, and have a registration request queued. The deeper build of that monitoring loop is its own subject, covered in Building your own drop-monitoring system and framed by policy in ICANN drop schedule policy explained.

A drop-time reference table for CentralNic secondary TLDs

The reference no generic guide provides: the published lifecycle stage lengths for CentralNic secondary TLDs, the pendingDelete signal that times the drop, and how those stages compare to the Verisign .com model. The figures come from CentralNic’s own TLD profiles and ICANN policy, and they are the inputs a catching plan runs on.

The table consolidates the cited lifecycle stages into one place. Read it as the operating profile of a CentralNic secondary-TLD drop: how long each holding stage lasts, and what the watcher does at each one.

Lifecycle stageCentralNic secondary TLD (uk.com profile)EPP status / signalWhat the watcher does
Auto-renew graceUp to 43 days after expiryautoRenewPeriodNothing yet. The prior owner can still reclaim at standard price.
Redemption grace30 daysredemptionPeriodNote the name. Recovery by the prior owner is still possible for a high fee.
Pending delete5 days, lockedpendingDeleteQueue the registration. This is the countdown to the drop.
The dropDaily registry batch, drop on the fifth dayName returns to availableFire the queued request at the registry-set time.
Re-registrationImmediate on deletionAvailable statusFastest queued request wins. Have a fallback name ready.
Figure 3. The CentralNic secondary-TLD drop lifecycle, with stage lengths from CentralNic’s published uk.com TLD profile and EPP codes from ICANN. Other secondary TLDs follow the same shape; confirm each name’s profile before relying on the days.

How this differs from the .com model

The contrast is the whole reason to read a registry-specific schedule. The familiar gTLD model that drop-catching guides describe runs on Verisign’s batch for .com and .net, which the wider drop-schedule mechanics are covered in Domain drop schedules by TLD: .com, .net, .org and Verisign mechanics. The country-code variations, where a registry can run a multi-month deletion path, are set out in Domain drop schedules for major ccTLDs: .uk, .de, .au, .eu and country-code mechanics. A CentralNic secondary TLD sits between the two: a second-level name with a gTLD-shaped lifecycle, but a registry-set deletion timing that is CentralNic’s, not Verisign’s.

How to catch a CentralNic secondary-TLD drop, step by step

Catching a CentralNic drop is a five-step sequence: source and confirm the target name is genuinely dropping, read its pendingDelete status through RDAP, queue a registration request at a registrar with registry access, fire at the registry-set drop time, and have a fallback ready. At each step the done-right move and the mistake that loses the name sit side by side. The honest reality is that the calmer path beats the race on contested names.

The steps below state the disciplined version and the specific failure at each stage. The pattern is the same one that runs through all drop catching: information first, speed second, and a realistic read of whether the race is worth running at all.

  1. Source and confirm the target is genuinely dropping

    Before chasing anything, confirm the secondary TLD is still actively sold, not sunsetted, and that the specific name is in or near the deletion lifecycle. This is also the step where the calmer alternative belongs: if the goal is an aged domain with inherited authority, browse screened inventory on the SEO Domains marketplace instead of racing a microsecond window, since the asset you want is in cases already vetted and available. The mechanics of how a name reaches the available pool are set out in Domain drop catching: how dropped domains become available.

    The mistake: building a plan around a name in a retired extension, or one routed to a registrar auction instead of a clean drop. A sunsetted secondary TLD never reopens, and an auction-routed name never reaches the public drop.

  2. Read the pendingDelete signal through RDAP

    The done-right move is to confirm the name’s real status at the registry, not a third-party guess. Read the EPP status through RDAP, the structured successor to WHOIS that ICANN made the standard lookup on 28 January 2025. When the status reads pendingDelete, the five-day countdown to the drop has started.

    The mistake: trusting a cached availability tool or a stale WHOIS scrape. A name that looks droppable in a stale record is, in practice, already renewed, redeemed, or auction-routed, and the wasted prep is the whole loss.

  3. Queue the registration at a registrar with registry access

    The done-right move is to have the request staged at a registrar that connects to the CentralNic registry for that secondary TLD, with payment and contact details pre-loaded so nothing blocks the send. Speed at the drop is decided here, before the clock runs.

    The mistake: discovering at the drop second that your registrar does not sell that secondary TLD, or that a manual checkout step stands between you and the registry. Either gap hands the name to a faster queue.

  4. Fire at the registry-set drop time, not a guessed time

    The done-right move is to target the registry’s actual deletion batch, reasoned from the pendingDelete countdown and, where available, a published schedule like the .it model. The drop returns the name in a fraction of a second, so the request must be ready to fire on the deletion event itself.

    The mistake: firing on a clock time copied from a .com drop guide. CentralNic secondary TLDs run a registry-set schedule, and a Verisign-shaped guess misses the window entirely.

  5. Have a fallback, and know when the race is not worth it

    The done-right move is to accept that even a perfect plan loses to professional drop-catch infrastructure on contested names, and to keep a fallback name or a sourcing alternative ready. The honest reality is that on a contested target, buying the equivalent screened domain costs less than the time and tooling a race consumes.

    The mistake: sinking repeated effort into a single contested name with no fallback. A name a hundred operators want will go to specialist infrastructure, and the chaser is left with nothing and no plan B.

Figure 4. The five steps to catch a CentralNic secondary-TLD drop, each pairing the done-right move with the mistake that loses the name. Step 1 holds the honest alternative: the asset you are chasing can often be sourced screened, without the race.

Common mistakes when chasing CentralNic drops: the checklist

The mistakes that lose a CentralNic secondary-TLD drop are a short, repeatable list. Each one is an information or execution failure, and each has a documented fix. The fixes converge on one move: read the registry’s real signal, confirm the zone is live, and accept when sourcing the screened equivalent beats the race. Use this as the scannable reference.

The table below consolidates the failure modes scattered through the steps and mechanics into one place. The left column is the mistake, the centre column is why it loses the name, and the right column is the done-right fix.

The mistakeWhy it loses the nameThe fix (done-right move)
Using a .com drop time for a secondary TLDCentralNic runs a registry-set schedule, not the Verisign batchReason the drop from the pendingDelete countdown and registry profile, not a .com guide
Chasing a sunsetted extensionA retired secondary TLD, like the eight shut in 2017, never reopensConfirm the secondary TLD is still actively sold before planning
Trusting a stale WHOIS or cached toolThe name may be renewed, redeemed, or auction-routed alreadyRead the live status through RDAP and confirm pendingDelete at the source
No registrar with registry access stagedA manual checkout step at the drop second hands the name to a faster queuePre-stage the request at a registrar that connects to the CentralNic registry
Assuming a public CentralNic drop list existsCentralNic does not publish a consumer drop list like Registro .it doesBuild the timing from the RDAP pendingDelete signal and the five-day window
Mistaking an auction route for a dropMany expiring names go to a registrar auction and never reach the public dropVerify the name is on a clean deletion path, not routed to an auction partner
Racing a contested name with no fallbackSpecialist drop-catch infrastructure wins high-demand namesKeep a fallback name, or source the screened equivalent instead of racing
Ignoring the asset behind the raceThe point was always the inherited authority, not the catch itselfWhere a screened aged domain delivers the same authority, buy it and skip the window
Figure 5. The CentralNic drop mistake checklist. Eight failures, why each loses the name, and the fix. The right column converges on one move: read the real registry signal, and recognise when the calmer sourcing path is the better trade.

One pattern runs down the fix column. The reliable input is always the registry’s own pendingDelete signal, read at the source, and the honest read is that the race is worth running only when no screened equivalent of the asset exists. A contested name will go to specialist infrastructure; an aged domain with the authority you set out to win can be sourced without the stopwatch, which is the foundation the closing section returns to.

CentralNic drop times frequently asked questions

The five questions investors and SEOs raise when they search for CentralNic drop times, answered against the registry’s published lifecycle and ICANN policy.

Q1What time exactly do CentralNic secondary TLDs drop?

There is no single published wall-clock time. CentralNic deletes pending-delete names in a daily registry batch, and the exact second varies by registry and time zone. The reliable signal is the name’s pendingDelete EPP status read through RDAP, which starts a five-day countdown to the drop. Operators time the request from that countdown, not from a fixed clock time.

Q2How long is the CentralNic deletion lifecycle?

For the uk.com secondary-TLD profile, CentralNic publishes a 43-day autorenew grace period and deletion timeframe, a 30-day redemption period, and then a locked pending-delete window of five days before the drop, consistent with the gTLD lifecycle ICANN documents. Other secondary TLDs follow the same shape, so confirm each name’s profile before relying on the exact days.

Q3Which TLDs count as CentralNic secondary TLDs?

The active second-level book includes uk.com, us.com, eu.com, de.com, cn.com, sa.com, gr.com, ru.com, za.com, br.com, mex.com, com.de, and jpn.com under .COM, plus gb.net, uk.net, hu.net, and se.net under .NET. Eight others, including ar.com and gb.com, were sunsetted on 30 April 2017 and no longer accept registrations, so verify a TLD is still sold before planning a catch.

Q4Does CentralNic publish a public drop list like Registro .it?

Not in the same consumer-facing form. Registro .it publishes daily drop lists with exact cancellation times, generated at 01:00 CET and dropped at 09:00 and 16:00 CET. CentralNic exposes registration status through RDAP and WHOIS and points registrars to where expiring-name lists can be found, but the timing is read from the pendingDelete signal, not a published consumer schedule.

Q5Is it worth racing a CentralNic drop, or is buying the domain the better trade?

It depends on demand and on the real goal. A contested name goes to specialist drop-catch infrastructure, and the race rarely rewards a manual chaser. When the goal is an aged domain with inherited authority, not one specific string, sourcing a screened equivalent from a curated catalogue costs less than the tooling and time a contested race consumes, and it removes the stopwatch entirely.

The calmer path to the same authority: screened secondary-TLD domains

The asset behind every CentralNic drop chase is a domain with inherited authority. That asset can be acquired by racing a microsecond window, or by sourcing a screened aged or secondary-TLD domain from a curated catalogue. For the typical buyer the second path costs less than the race and removes the timing risk. SEO Domains operates that curated marketplace.

Why the asset, not the race, is the point

Every step of a drop-catching plan exists to win one thing: a domain whose history and backlinks make it worth registering. The race is a means, not the goal. When a screened domain with the same kind of inherited authority is already available, the microsecond window is effort spent on a problem you did not need to have.

What screening removes from the equation

A screened domain has already passed the checks a drop chaser performs after the catch, too late to undo a bad one. The backlink profile is read, the history is verified, and a clean spam screen is run before the name is listed. A raced drop hands you a name and leaves the diligence for afterward, when a toxic profile can no longer be undone by speed.

How to source a secondary-TLD domain that holds up

A domain worth owning survives a profile check before money changes hands. The signals that matter are the same whether the name is a raced drop or a catalogue listing:

  • The referring-domain profile, weighted by the quality of the links, not just the count.
  • The registration and use history, with topical continuity and no prior spam.
  • Authority metrics read together rather than singly, so an inflated number cannot hide a thin profile.
  • A clean spam screen, confirming the inherited authority is real and not toxic.

A raced drop gives you the name and none of these confirmations until afterward. A screened listing gives you the confirmations first, which is the difference between an asset and a gamble.

The demand behind every CentralNic drop-time search is access to real domain authority you can own. That is the product, not a drop-catch subscription and not a registrar race. SEO Domains operates the curated marketplace where aged and secondary-TLD domains are screened across their backlink profiles and authority metrics before they are listed and priced, so the asset you would chase a CentralNic drop for can be sourced without the window.

Zhivko Stoyanov, Head of AI & Business Efficiency at SEO Domains

Zhivko Stoyanov

Head of AI & Business Efficiency @ SEO Domains

With close to 20 years in theoretical and mathematical physics, Zhivko brings deep analytical rigour to SEO Domains. For more than four years he has driven the speed, efficiency, and data discipline behind the company’s internal processes.

He leads SEO at the SEO Domains marketplace, which operates a 220,000+ curated catalogue from $100 entry-level domains through premium acquisitions, screened across the catalogue, with Managed Account expert support for premium-tier clients.

· Last reviewed