Pending Delete Nedir? Domain Düşme Süreci Nasıl İşler?

Redemption period'u geçiren bir domain, müsaite düşmeden önce son bir bekleme aşamasından geçer: pending delete. Bu 5 günlük süreçte ne kayıt sahibi ne registrar ne de başka biri domain üzerinde herhangi bir işlem yapabilir. Ama bu sürenin tam olarak ne zaman biteceği ve domain'in tam olarak ne zaman düşeceği dışarıdan görünmez — ve bu belirsizlik, drop-catching endüstrisinin temel dayanak noktasıdır.

Domain yaşam döngüsü içinde pending delete, grace period ve redemption period'dan sonra gelen üçüncü ve son aşamadır. Süresi dolan bir domain'in geçtiği aşamalar değerlendirildiğinde bu üç dönem arasındaki fark nettir: grace period'da kayıt sahibi normal koşullarda yenileme yapabilir, redemption period'da ek ücret ödeyerek domain'i geri alabilir, pending delete aşamasında ise artık hiçbir geri dönüş yoktur. Domain bu noktada teknik olarak silinmeyi bekliyor olsa da henüz serbest değildir; müsaite düşmesi için sürecin kendi temposunda ilerlemesi gerekir.

Peki bu süreç registry ve registrar katmanlarında tam olarak nasıl işler? Hangi EPP statü kodu bu aşamayı tanımlar, WHOIS'te nasıl görünür ve 5 günün sonunda domain gerçekten öngörülebilir bir anda mı düşer?

EPP statüsü olarak pendingDelete: teknik katmanda ne anlama gelir

Domain kayıt sistemleri, registrar ile registry arasındaki iletişimi EPP (Extensible Provisioning Protocol) adı verilen standart protokol üzerinden yürütür. Her domain, bu protokol üzerinden atanmış bir ya da birden fazla statü kodu taşır. Bu kodlar, domain'in hangi işlemlere açık, hangilerine kapalı olduğunu makine düzeyinde tanımlar ve WHOIS çıktısında açıkça görünür.

Pending delete aşamasına giren bir domain, pendingDelete EPP statüsünü alır. Bu statü, registrar tarafından değil, registry tarafından atanır. WHOIS sorguladığınızda şuna benzer bir çıktı görürsünüz:

Domain Name: EXAMPLE.COM
Domain Status: pendingDelete https://icann.org/epp#pendingDelete
Updated Date: 2026-04-18T08:14:32Z
Creation Date: 2019-06-11T10:00:00Z
Registry Expiry Date: 2025-06-11T10:00:00Z
Registrar: ExampleRegistrar, Inc.

pendingDelete statüsündeki bir domain için transfer, güncelleme, yenileme ve restore işlemlerinin tamamı bloke edilmiştir. Registrar, bu aşamada domain üzerinde herhangi bir EPP komutu çalıştırmaya kalktığında registry komutu işleme almadan reddeder. Bu bakımdan registrar lock ile oluşturulan transfer engelinden yapısal olarak farklıdır: lock, registrar ya da kayıt sahibi tarafından kaldırılabilir bir kısıtlamayken, pendingDelete registry tarafından atanmış ve hiçbir tarafın müdahale edemeyeceği bir son durumdur.

WHOIS kaydı bu süre içinde hâlâ mevcuttur; domain silinmiş değildir. Registry veritabanında kayıt durur, ama bağlantısız ve işlemsiz biçimde bekler. Statü değişikliğinin tarihi genellikle "Updated Date" alanında görünür ve bu tarih çoğunlukla registrar'ın silme komutunu gönderdiği günü işaret eder. Nameserver bilgileri WHOIS'te kayıtlı kalmaya devam edebilir, ancak bu veriler artık işlevsel değildir.

Redemption period'dan pending delete'e: geçişi başlatan mekanizma

Redemption period, 30 günlük geri alma penceresidir. Bu süre içinde kayıt sahibi ya da registrar, registry'e restore talebi göndererek domain'i kurtarabilir. Restore işlemi standart yenileme ücretinin çok üzerinde bir bedel gerektirir ve gTLD politikasında kayıt sahibinin açıklayıcı bir restore raporu sunması beklenir.

30 gün içinde hiçbir restore talebi iletilmediyse registrar, EPP delete komutunu registry'e gönderir. Bazı registrar'lar bu komutu redemption period'un ilk günlerinde otomatik olarak tetikler; bazıları 30. güne kadar bekler. Her iki durumda da registry silme komutunu aldığında domain'i doğrudan serbest bırakmaz. Önce pendingDelete statüsüne alır ve 5 günlük bekleyişi başlatır. Bu adım, ICANN'ın gTLD politikasıyla zorunlu kılınmıştır.

Bu geçişi tetikleyen kritik nokta şudur: registrar'ın silme komutunu göndermesi ile registry'nin bu komutu işlemesi arasında birkaç saatlik bir fark olabilir. Bazı registrar'lar silme komutunu toplu olarak gece işler; bu durumda WHOIS'in statüsünün güncellenmesi saatler alabilir. Süreci dışarıdan izleyenler için bu gecikme, redemption period'un tam olarak ne zaman bittiğini belirsizleştirir.

Beş günlük pencerede registry ne yapar, siz ne yapamazsınız

Registry, domain'i pendingDelete statüsüne aldıktan sonra zone dosyasındaki kaydı kaldırır. Bu adımın zamanlaması registry'den registry'e değişir. VeriSign (.com ve .net yöneticisi) bu işlemi genellikle statü değişikliğinin ilk birkaç saati içinde gerçekleştirir. Bu noktadan itibaren domain'e yönelik DNS sorguları yanıtsız kalır; web sitesi ve e-posta servisleri artık domain adı üzerinden erişilemez hale gelir.

$ dig example.com NS +short
(yanıt yok)

$ dig example.com A +short
(yanıt yok)

$ whois example.com | grep "Domain Status"
Domain Status: pendingDelete https://icann.org/epp#pendingDelete

Zone'dan kaldırılmış olmasına karşın WHOIS kaydı bu süre boyunca sorgulanabilir durumda kalır. WHOIS ve RDAP sorgularında gördüğünüz statü kodu domain'in yaşam döngüsü durumunu yansıtır, ancak zone davranışını her zaman doğru göstermez. Bu iki katman — kayıt veritabanı ve zone dosyası — birbirinden bağımsız güncellenir ve aralarında senkronizasyon gecikmesi olabilir. Bu nedenle WHOIS'in "aktif" görünmesi, domain'in DNS üzerinden çalışır durumda olduğu anlamına gelmez.

Bu 5 günlük pencerede tarafların yapabileceği herhangi bir işlem yoktur. Eski kayıt sahibi restore talebinde bulunamaz. Registrar güncelleme ya da yenileme komutu çalıştıramaz. Üçüncü taraflar yeni kayıt başlatamaz. Domain, teknik olarak var olmakla birlikte erişilemez ve değiştirilemez bir askı halindedir. Registry, bu süreyi kendi iç süreçlerini tamamlamak için kullanır; olası teknik doğrulama adımları ve kayıt kuyruklama işlemleri bu pencerede yürütülür.

Drop zamanlaması neden tahmin edilemez

Teorik olarak pending delete süresi 5 gündür ve bu sürenin sonunda domain serbest kalır. Pratikte ise "5. günün sonunda" ifadesi ciddi ölçüde yanıltıcıdır. Registry, domain'i saate, dakikaya ya da saniyeye göre öngörülebilir bir anda bırakmaz.

VeriSign örneğini ele alalım. .com silme işlemleri, registry tarafından gün içinde belirli batch pencereleri sırasında toplu olarak işlenir. Bu pencerelerin tam saati kamuya açık değildir ve her gün değişkenlik gösterebilir. Bazı domain'ler Türkiye saatiyle gece 03:00–05:00 arasında düşerken bazıları öğlen saatlerine denk gelir. 5 günlük sürenin başlangıç saatine göre teorik bitiş anı hesaplanabilir olsa da bu hesap gerçekle çoğunlukla örtüşmez.

Zamanlamayı daha da öngörülemez kılan başka etkenler de vardır. Registry sistemlerinde oluşan yoğunluk, bakım pencereleri ya da kuyruklama sorunları drop anını birkaç saat, bazen bir gün daha öteleyebilir. Kimi zaman bir domain'in "düşmesi" beklenen tarihte gerçekleşmeyip ertesi güne sarkması da görülür. Aynı batch içinde yüz binlerce domain işlenebilir; işlem sırası da dışarıdan görünmez.

Bu belirsizlik, yalnızca teorik bir sorun değildir. Drop-catching servislerinin iş modeli tam bu noktadan beslenir: kimse kesin zamanı önceden bilemeyeceğinden, sistem sürekli aktif sorgu göndermek zorunda kalır. Bu da aşağıda ele alacağımız yarışın temel dinamiğini oluşturur.

Drop-catching ve backorder: erişim yarışının anatomisi

Drop-catching, bir domain'in serbest kaldığı anda — milisaniye düzeyinde — kayıt komutunu registry'e ilk ulaştıran tarafın domain'i aldığı bir süreçtir. Bu amaçla faaliyet gösteren servisler, büyük registrar'larla doğrudan EPP bağlantısı kurar ve domain'in drop olacağı tahmin edilen süre boyunca saniyede birden fazla sorgulama göndererek anı yakalamaya çalışır. Kullandıkları EPP bağlantısının kalitesi ve registry sunucularına olan fiziksel yakınlıkları başarı oranını doğrudan etkiler.

Backorder ise bu yarışa katılmak isteyen kullanıcıların önceden talep kaydı bırakmasını sağlayan bir hizmettir. Kullanıcı servise "bu domain düştüğünde benim adıma kaydet" der; servis domain'i izler ve drop anında otomatik olarak yarışa girer. Backorder, kullanıcının manuel olarak takip etme zorunluluğunu ortadan kaldırır. Ancak servisin başarı garantisi vermediğini bilmek gerekir; popüler domain'lerde birden fazla drop-catching servisi aynı anda yarışıyor olabilir.

Birden fazla kullanıcı aynı domain üzerinde backorder verdiyse, servisler genellikle bu durumu açık artırmaya dönüştürür. Domain'i yakalayan servis, talep sahipleri arasında en yüksek teklifi veren kullanıcıya devir işlemi yapar. Bu mekanizma, değerli domain'lerin backorder fiyatını kayıt ücretinin çok üzerine çıkarabilir.

Drop-catching servislerinin kullandığı registrar'ın registry ile olan EPP bağlantı önceliği belirleyici bir faktördür. VeriSign gibi büyük registry'ler belirli sayıda akredite registrar'a daha doğrudan erişim sunar; bu registrar'ları kullanan servisler yapısal bir avantaj elde eder. Küçük ya da dolaylı registrar'lar üzerinden yapılan girişimlerde başarı oranı düşer. WHOIS sorgularıyla domain'in statüsünü düzenli olarak kontrol edebilirsiniz, ama drop anını önceden kestirmenin güvenilir bir yöntemi yoktur.

Küçük bir ayrıntı olarak şunu eklemek gerekir: çok sayıda drop-catching servisi eş zamanlı çalışıyor olsa da sonucu büyük ölçüde registry'nin o anki işlem sırası belirler. Aynı milisaniyede birden fazla kayıt komutunu alan registry, bunlardan birini işler, diğerlerini reddeder. Hangi komutun önce işleneceği, bağlantı gecikmesi ve sunucu yük dağılımı gibi değişkenlere bağlıdır.

Domain düştükten sonra: zone, WHOIS ve yeniden kayıt

Pending delete süresi tamamlandığında ve registry silme işlemini gerçekleştirdiğinde, domain birkaç katmanda eş zamanlı olarak temizlenir. Zone dosyasından kalıcı olarak çıkarılır, WHOIS kaydı silinir ve EPP veritabanındaki kayıt kaldırılır. Bu noktadan sonra domain müsait durumdadır. Herhangi bir registrar üzerinden standart kayıt süreciyle alınabilir.

# Domain hâlâ pendingDelete aşamasındayken:
$ curl -s "https://rdap.verisign.com/com/v1/domain/example.com" \
  | python3 -m json.tool | grep -A2 '"status"'
  "status": [
    "pending delete"
  ]

# Domain düştükten sonra:
# HTTP 404 — kayıt bulunamadı

Bazı durumlarda bu geçiş o kadar temiz gerçekleşmeyebilir. Registry, kısa, değerli ya da marka potansiyeli taşıdığını değerlendirdiği domain'leri silme sonrasında kendi portföyüne alabilir. Bu domain'ler serbest piyasaya açılmak yerine premium fiyatla satışa sunulur ya da belirli bir süre tutulur. Hangi domain'lerin bu kategoriye girdiği önceden bilinmez ve açık bir politika olarak yayımlanmaz.

Drop-catching başarıyla sonuçlandıysa domain, zaten bir registrar üzerinde yeni sahibine atanmış olarak WHOIS'te görünmeye başlar. Bu güncellemenin WHOIS'e yansıması birkaç saat ile birkaç gün arasında değişebilir. DNS propagasyonu ise yeni sahibin nameserver ayarlarını yapmasının ardından devreye girer; global çözümleyicilere yayılması için birkaç saat gerekebilir.

Pending delete sürecini dışarıdan izlemenin en pratik yolu, domain'i belirli aralıklarla WHOIS veya RDAP üzerinden sorgulamaktır. Statü pendingDelete'ten "No match for domain" yanıtına döndüğünde, domain düşmüş demektir — ya hâlâ müsait durumdadır ya da drop-catching aracılığıyla zaten birileri tarafından alınmıştır. İkinci durumu teyit etmek için birkaç dakika içinde tekrar sorgulama yapmak yeterlidir.

Pending delete, domain yaşam döngüsünün en sessiz ama en kesin kapanışıdır. Bir önceki aşama olan redemption period yüksek maliyetli de olsa bir çıkış kapısını açık bırakırken, pending delete o kapıyı kalıcı olarak kapatır. Bu aşamaya gelmiş bir domain için yapılabilecek tek şey beklemek ve eğer domain'i almak istiyorsanız bir backorder servisi aracılığıyla hazırlanmış olmaktır.

Pek çok domain kaybı, bu sürecin farkında olmadan yaşanır. Yenileme hatırlatmalarının gözden kaçması, ödeme sorunları ya da registrar iletişiminin kesilmesi sonucunda bir domain grace period'u, redemption period'u ve nihayetinde pending delete'i sessizce geçebilir. Sürecin başından itibaren registrar ve registry arasındaki görev dağılımını anlamak ve yenileme takibini sistematik tutmak, bu kaybı önlemenin en güvenilir yöntemidir.