- Katılım
- 21 May 2023
- Mesajlar
- 509
- Tepki
- 17
- Puan
- 18
Aynı alan adını art arda iki farklı WHOIS sorgu sitesinde arattığınızda "Expiration Date" alanının birkaç gün, bazen birkaç hafta farklı çıktığı görülebilir. Bu genelde bir hata değil; çoğu aracı sorgu sitesi sonucu kendi önbelleğinden sunuyor ve o önbelleğin ne zaman tazelendiği sizin kontrolünüzde değil.
Gerçek tarihi öğrenmek için aracı siteye değil kaydın kaynağına bakmak gerekiyor: ya doğrudan registrar hesabınızdaki kayıt ya da protokol seviyesinde bir RDAP sorgusu. İkisi arasında fark varsa, alan adının üzerindeki durum kodları hangi sürecin — yenileme, transfer, grace dönemi — devam ettiğini gösterir.
RFC 9082, RDAP'ın neden geliştirildiğini WHOIS'in eksiklikleriyle açıklıyor: standart bir komut yapısı yok, standart bir çıktı ve hata yapısı yok, uluslararasılaştırma ile yerelleştirme desteği yok, kullanıcı kimlik doğrulama ve erişim kontrolü de yok. Standart bir çıktı yapısının olmaması, klasik WHOIS sorgusunun sunucudan sunucuya biçimi değişebilen serbest metin döndürmesi anlamına geliyor; bu da tarih alanlarını otomatik veya güvenilir biçimde ayrıştırmayı zorlaştırıyor.
RDAP bunun yerine HTTP üzerinde tek tip URL desenleri kullanıyor; yanıtlar da ayrı bir belgede, RFC 9083'te tanımlı standart bir JSON formatında geliyor. Aracı bir sitenin serbest metin çıktısı yerine bu yapılandırılmış yanıtı doğrudan sorgulayabilmek, "hangi alan neyi anlatıyor" belirsizliğini büyük ölçüde ortadan kaldırıyor.
RFC 9083'e göre bir RDAP domain yanıtı "events" adlı bir dizi taşıyor; her olay bir "eventAction" (registration, last changed, expiration, deletion gibi) ve bir "eventDate" alanından oluşuyor. Ayrı bir "status" dizisi de kaydın o anki durumunu (active, inactive, locked, pending delete gibi değerlerle) listeliyor. RFC, bunu WHOIS'teki "Expiration Date" veya "Updated Date" ile birebir eşleştirmiyor; ama eventAction değeri "expiration" olan olayın eventDate'i, aradığınız bitiş tarihine karşılık geliyor ve bu değer doğrudan kaydın kaynağından geliyor.
Durum kodları iki ayrı aileden geliyor. clientTransferProhibited gibi taraflarca konan kilitleri ve bunların transfer sürecindeki işleyişini daha önce EPP kodu ve 60 gün kilidi rehberinde ayrıntılı ele almıştık. Diğer aile ise grace dönemlerini tanımlayan EPP eklentisinde yer alıyor ve şu yedi durumdan oluşuyor:
Bu kodların ortak noktası, bir işlemin (yenileme, transfer, silme) hemen ardından açılan ve belirli koşullarda geri alınabilir bir pencereye işaret etmeleri.
Aynı belge, her grace döneminin süresinin "tipik olarak gün cinsinden ölçülen, tamamen registry'nin operasyonel politikasına bırakılmış" bir değer olduğunu açıkça yazıyor; yani belgenin kendisi kesin bir gün sayısı vermiyor. Bir alan adı autoRenewPeriod veya transferPeriod içindeyken registry kaydı az önce güncellenmiş olabilir; aracı bir sorgu sitesi ise hâlâ bir önceki anlık görüntüyü gösteriyor olabilir. Gördüğünüz "tutarsızlık" çoğunlukla tam da bu an, iki farklı zaman noktasının karşılaştırılmasından doğuyor.
En kısa yol registrar hesabınızdaki alan adı yönetim panelidir; kayıt orada tutuluyor ve genelde en güncel halini gösteriyor. Protokol seviyesinde bağımsız bir doğrulama istiyorsanız aracı sorgu sitesi yerine ilgili uzantının RDAP servisini doğrudan sorgulamak daha güvenilir bir yol; RDAP'ın RESTful yapısı sayesinde bu sorgu tarayıcıdan bile yapılabiliyor, ayrı bir istemci programa ihtiyaç duymuyor.
Burada dikkat edilecek nokta, sorguladığınız RDAP servisinin uzantının resmi kayıt otoritesine (registry) mi yoksa alan adını sizin adınıza tescil eden şirkete (registrar) mi ait olduğunu bilmek; ikisi aynı anda güncel olsa da farklı sistemlerdir ve bazen biri diğerinden önce güncellenir. Alan adı tescil sürecinin bu adımların hangi noktasında geçtiğini baştan görmek isteyenler için domain tescil rehberi genel akışı özetliyor; registrar seçimi ve yönetim paneli farklarına dair genel bir bakış da domain kaydı ve yönetimi başlığında var.
Aracı WHOIS sitelerindeki tarih farkı çoğunlukla önbellek meselesi; gerçek kayıt registrar panelinizde veya RDAP'ın yapılandırılmış yanıtında duruyor. Durum kodları ise hangi sürecin (yenileme, transfer, grace dönemi) devam ettiğini gösteriyor, kesin gün sayısını değil — o, registry'nin kendi politikasına bağlı. Bir alan adında WHOIS ile registrar panelindeki tarihin farklı olduğunu hiç gördünüz mü, hangisi doğru çıktı?
Güncelleme: 21 Ağustos 2026. RFC 9082, RFC 9083 ve grace dönemlerini tanımlayan EPP eklenti belgesi kontrol edildi; ICANN'in ilgili sayfalarına bu oturumda erişilemedi.
Gerçek tarihi öğrenmek için aracı siteye değil kaydın kaynağına bakmak gerekiyor: ya doğrudan registrar hesabınızdaki kayıt ya da protokol seviyesinde bir RDAP sorgusu. İkisi arasında fark varsa, alan adının üzerindeki durum kodları hangi sürecin — yenileme, transfer, grace dönemi — devam ettiğini gösterir.
WHOIS'in yapısal sorunu ve RDAP'ın getirdiği çözüm
RFC 9082, RDAP'ın neden geliştirildiğini WHOIS'in eksiklikleriyle açıklıyor: standart bir komut yapısı yok, standart bir çıktı ve hata yapısı yok, uluslararasılaştırma ile yerelleştirme desteği yok, kullanıcı kimlik doğrulama ve erişim kontrolü de yok. Standart bir çıktı yapısının olmaması, klasik WHOIS sorgusunun sunucudan sunucuya biçimi değişebilen serbest metin döndürmesi anlamına geliyor; bu da tarih alanlarını otomatik veya güvenilir biçimde ayrıştırmayı zorlaştırıyor.
RDAP bunun yerine HTTP üzerinde tek tip URL desenleri kullanıyor; yanıtlar da ayrı bir belgede, RFC 9083'te tanımlı standart bir JSON formatında geliyor. Aracı bir sitenin serbest metin çıktısı yerine bu yapılandırılmış yanıtı doğrudan sorgulayabilmek, "hangi alan neyi anlatıyor" belirsizliğini büyük ölçüde ortadan kaldırıyor.
RDAP yanıtında "events" ve "status" alanları neyi gösteriyor
RFC 9083'e göre bir RDAP domain yanıtı "events" adlı bir dizi taşıyor; her olay bir "eventAction" (registration, last changed, expiration, deletion gibi) ve bir "eventDate" alanından oluşuyor. Ayrı bir "status" dizisi de kaydın o anki durumunu (active, inactive, locked, pending delete gibi değerlerle) listeliyor. RFC, bunu WHOIS'teki "Expiration Date" veya "Updated Date" ile birebir eşleştirmiyor; ama eventAction değeri "expiration" olan olayın eventDate'i, aradığınız bitiş tarihine karşılık geliyor ve bu değer doğrudan kaydın kaynağından geliyor.
EPP durum kodları hangi süreci işaret ediyor
Durum kodları iki ayrı aileden geliyor. clientTransferProhibited gibi taraflarca konan kilitleri ve bunların transfer sürecindeki işleyişini daha önce EPP kodu ve 60 gün kilidi rehberinde ayrıntılı ele almıştık. Diğer aile ise grace dönemlerini tanımlayan EPP eklentisinde yer alıyor ve şu yedi durumdan oluşuyor:
- addPeriod: Alan adının ilk kaydından hemen sonra tanınan dönem.
- autoRenewPeriod: Otomatik yenileme işleminin ardından açılan dönem.
- renewPeriod: Kayıt sahibinin kendi isteğiyle yaptığı yenilemenin ardından açılan dönem.
- transferPeriod: Bir transfer işleminin tamamlanmasının ardından açılan dönem.
- redemptionPeriod: Silme talebinden sonra kaydı geri kazanma fırsatı tanıyan dönem.
- pendingRestore: Geri kazanma (restore) işleminin sürdüğü ara dönem.
- pendingDelete: Silme işleminden hemen önceki, artık geri dönüşü olmayan son dönem.
Bu kodların ortak noktası, bir işlemin (yenileme, transfer, silme) hemen ardından açılan ve belirli koşullarda geri alınabilir bir pencereye işaret etmeleri.
Grace dönemlerinde tarih neden "kaymış" görünür
Aynı belge, her grace döneminin süresinin "tipik olarak gün cinsinden ölçülen, tamamen registry'nin operasyonel politikasına bırakılmış" bir değer olduğunu açıkça yazıyor; yani belgenin kendisi kesin bir gün sayısı vermiyor. Bir alan adı autoRenewPeriod veya transferPeriod içindeyken registry kaydı az önce güncellenmiş olabilir; aracı bir sorgu sitesi ise hâlâ bir önceki anlık görüntüyü gösteriyor olabilir. Gördüğünüz "tutarsızlık" çoğunlukla tam da bu an, iki farklı zaman noktasının karşılaştırılmasından doğuyor.
Nihai doğrulama nerede yapılır
En kısa yol registrar hesabınızdaki alan adı yönetim panelidir; kayıt orada tutuluyor ve genelde en güncel halini gösteriyor. Protokol seviyesinde bağımsız bir doğrulama istiyorsanız aracı sorgu sitesi yerine ilgili uzantının RDAP servisini doğrudan sorgulamak daha güvenilir bir yol; RDAP'ın RESTful yapısı sayesinde bu sorgu tarayıcıdan bile yapılabiliyor, ayrı bir istemci programa ihtiyaç duymuyor.
Burada dikkat edilecek nokta, sorguladığınız RDAP servisinin uzantının resmi kayıt otoritesine (registry) mi yoksa alan adını sizin adınıza tescil eden şirkete (registrar) mi ait olduğunu bilmek; ikisi aynı anda güncel olsa da farklı sistemlerdir ve bazen biri diğerinden önce güncellenir. Alan adı tescil sürecinin bu adımların hangi noktasında geçtiğini baştan görmek isteyenler için domain tescil rehberi genel akışı özetliyor; registrar seçimi ve yönetim paneli farklarına dair genel bir bakış da domain kaydı ve yönetimi başlığında var.
Özetle
Aracı WHOIS sitelerindeki tarih farkı çoğunlukla önbellek meselesi; gerçek kayıt registrar panelinizde veya RDAP'ın yapılandırılmış yanıtında duruyor. Durum kodları ise hangi sürecin (yenileme, transfer, grace dönemi) devam ettiğini gösteriyor, kesin gün sayısını değil — o, registry'nin kendi politikasına bağlı. Bir alan adında WHOIS ile registrar panelindeki tarihin farklı olduğunu hiç gördünüz mü, hangisi doğru çıktı?
Güncelleme: 21 Ağustos 2026. RFC 9082, RFC 9083 ve grace dönemlerini tanımlayan EPP eklenti belgesi kontrol edildi; ICANN'in ilgili sayfalarına bu oturumda erişilemedi.
Dijital Dünyanıza Yön Veren Pusula
