Whois ve RDAP: Alan Adı Kayıt Bilgileri Bugün Ne Gösteriyor?

En son on yıl önce whois sorgulama yaptıysanız, karşınıza çıkan uzun metni hatırlarsınız: ad soyad, açık adres, telefon, e-posta. Bugün aynı sorguyu yaptığınızda bunların çoğu yok. Kayıt daha kısa, yarısında "REDACTED" yazıyor ve kullandığınız araç büyük ihtimalle artık Whois protokolüyle konuşmuyor bile.

Bu rehberde neyin değiştiğini, kayıt verisinin hâlâ neler söylediğini ve asıl işe yarayan kısımların, yani durum kodlarının ve tarihlerin nasıl okunacağını anlatıyoruz.

Whois kaydı hâlâ neleri gösterir?

.com, .net, .org, .app gibi genel uzantılı bir alan adının herkese açık kayıt verisinde şunları güvenle bulursunuz:

alan adını yöneten kayıt firması (registrar) ve IANA numarası
kayıt, son güncellenme ve bitiş tarihleri
bir ya da birkaç durum kodu
alan adının yönlendirildiği nameserver'lar
alan adının DNSSEC ile imzalı olup olmadığı
kayıt firmasının kötüye kullanım (abuse) iletişim adresi

Bu kadarı, işletme tarafındaki soruların çoğunu yanıtlamaya yeter. Bu alan adı bitmek üzere mi? Sorunu çözmek için hangi firmayı aramalıyım? Nameserver'lar geçen hafta mı değişti? Transfer kilidi açık mı?

Kayıtta genellikle bulunmayan şey ise alan adı sahibinin kimliğidir.

Domain kimin üzerine? Sahip bilgileri neden gizli?

Mayıs 2018'e kadar ICANN sözleşmeleri, kayıt firmalarını genel uzantılı her alan adının sahibine ait iletişim bilgilerini eksiksiz yayınlamakla yükümlü tutuyordu. AB'nin Genel Veri Koruma Tüzüğü (GDPR) yürürlüğe girince, bu tür kişisel verileri soran herkese açmanın savunulabilir bir hukuki dayanağı kalmadı. ICANN buna, kayıt otoriteleri ile kayıt firmalarının kişisel alanları herkese açık çıktıdan çıkarmasına izin veren geçici bir düzenlemeyle (Temporary Specification) karşılık verdi. Onun yerini alan kalıcı Kayıt Verisi Politikası da aynı ilkeyi koruyor.

Bunun pratikteki sonuçları:

Gizleme çoğu zaman küreseldir. Müşterileri hangi gizlilik yasasına tabi olduklarına göre ayırmak hataya açık olduğundan, birçok kayıt firması gizlemeyi herkese uygular.
Kurum adları yine de görünebilir. Tüzel kişiler kurum adının yayınlanmasını tercih edebilir; bir kısmı öyle yapıyor.
Gizlilik ve proxy hizmetleri ayrı bir katmandır. Bu hizmetler sahibin bilgileri yerine kendi bilgilerini yazar. 2018'den çok önce de vardı, hâlâ yaygın.
Meşru talepler için bir yol var. Kayıt firmaları, adresi açıklamadan alan adı sahibine ulaşmanın bir yolunu (genellikle bir web formu ya da aracı e-posta adresi) sunmak ve kolluk kuvvetleri ya da marka sahipleri gibi tarafların bilgi taleplerini değerlendirmek zorundadır.

Hiçbir sorgulama aracı gizlemeyi aşamaz, çünkü veri kaynağında çıkarılıyor. Gizlenmiş bir alan adının "gerçek sahibini" gösterdiğini öne süren bir site ya yıllar önce toplanmış eski veriyi gösteriyordur ya da tahmin yürütüyordur.

Bir not da .tr için: .com.tr gibi uzantıların kayıt otoritesi TRABİS'tir ve kendi kurallarını uygular. Genel uzantılar için anlattıklarımız .tr alan adlarına birebir uymayabilir; yetkili kaynak TRABİS'in kendi sorgulama sayfasıdır.

Whois protokolünün sorunu ne?

Whois 1980'lerin başından kalma bir protokoldür. İstemci 43 numaralı TCP portuna bağlanır, alan adını ve bir satır sonu gönderir, karşılığında serbest metin alır. Protokolün tamamı bundan ibarettir. Sonuçları:

Standart biçim yok. Her kayıt otoritesi kendi alan adlarını ve düzenini uydurur. Çıktıyı ayrıştıran yazılımlar sürekli bozulur.
Standart hata yok. "Bulunamadı", "hız sınırına takıldınız" ve "sunucu bozuk" durumlarının hepsi düz metindir.
Uluslararası karakter desteği yok. Tanımlı bir karakter kodlaması bulunmaz.
Şifreleme ve kimlik doğrulama yok. Her şey açık metin olarak gider; farklı kullanıcılara farklı erişim düzeyi vermenin yolu yoktur.
Keşif mekanizması yok. Hangi uzantıya hangi sunucunun yanıt verdiğini gösteren, elle güncellenen listeler gerekir.

RDAP: Whois'in halefi

Registration Data Access Protocol (RDAP), tam da bu sorunları çözmek için 2015'te IETF tarafından standartlaştırıldı. HTTPS üzerinden çalışan ve JSON döndüren bir API'dir:

Tanımlı yapı. Tarihler, registration ya da expiration gibi bir eylem taşıyan events öğeleridir. İletişim kayıtları, registrar ya da abuse gibi rolleri olan entities öğeleridir. Durum değerleri sabit bir listeden gelir.
Gerçek hata yönetimi. Var olmayan alan adı HTTP 404, hız sınırı 429 döndürür.
Otomatik keşif. IANA, her uzantıyı RDAP adresine eşleyen, makinelerin okuyabildiği bir dosya yayınlar; istemci nereye soracağını her zaman bilir.
Yönlendirme. Kayıt otoritesinin yanıtı, daha fazla ayrıntı tutabilen kayıt firmasının RDAP sunucusuna bağlantı verebilir.
Kademeli erişime uygunluk. HTTPS üzerinde çalıştığı için sunucu, talep edenin kimliğini doğrulayıp yetkisi olanlara daha fazla alan döndürebilir.

Denemek için curl yeterlidir. Kısaltılmış bir yanıt şuna benzer:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

ICANN, Ağustos 2019'dan beri genel uzantılardaki kayıt otoriteleri ile kayıt firmalarını RDAP sunmakla yükümlü tutuyor. Ocak 2025'te ise bu uzantılar için port 43 Whois hizmetini sürdürme zorunluluğu sona erdi; böylece RDAP yetkili kaynak haline geldi. İnsanlar hâlâ "whois sorgulama" diyor ve işin adı olarak bunda bir sakınca yok, ama veri giderek daha çok RDAP üzerinden geliyor.

Ülke kodlu uzantılarda durum farklıdır; kendi politikalarını kendileri belirler. Birçoğu RDAP sunar, bazıları yalnızca Whois ya da bir web formu işletir, birkaçı ise neredeyse hiçbir şey yayınlamaz.

Durum kodları nasıl okunur?

Durum kodları, kayıt firmalarıyla kayıt otoriteleri arasındaki protokol olan EPP'den gelir. RDAP bunları boşluklu yazar ("client transfer prohibited"), Whois çıktısında ise bitişik yazılır (clientTransferProhibited). Ön ek, kodu kimin koyduğunu söyler: client kayıt firması, server kayıt otoritesi demektir.

Gündelik kodlar

ok / active: Kısıtlama yok, hiçbir şey kilitli değil.
clientTransferProhibited: Kayıt firmasının transfer kilidi. Kendi alan adınızda olması normal ve istenen bir şeydir.
clientUpdateProhibited, clientDeleteProhibited: Değişikliğe ya da silmeye karşı kayıt firması kilitleri. Değerli alan adlarında yaygındır.
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited: Kayıt otoritesi düzeyinde kilitler. Registry lock hizmetlerinde ve ihtilaflarda görülür.

Alan adının çalışmadığını gösteren kodlar

clientHold: Kayıt firması alan adını zone'dan çıkarmış. Tipik nedenler: ödenmemiş yenileme, doğrulanmamış iletişim e-postası, kötüye kullanım incelemesi.
serverHold: Aynısını kayıt otoritesi yapmış. Genellikle hukuki ya da politika kaynaklıdır.
inactive: Nameserver tanımlı değil, dolayısıyla yayınlanacak bir şey yok.

Yaşam döngüsü kodları

addPeriod: Yeni kayıt edilmiş. Kayıt firması genellikle beş gün içinde silip ücretini geri alabilir.
autoRenewPeriod: Kayıt otoritesi, süre dolduğunda alan adını otomatik olarak yenilemiş. Kayıt firması bunu tipik olarak 45 güne kadar geri alabilir.
transferPeriod, renewPeriod: Transferden ya da açık bir yenilemeden sonraki kısa süreler.
pendingTransfer: Başka bir kayıt firmasına transfer sürüyor.
redemptionPeriod: Alan adı silinmiş. Eski sahibi genellikle 30 gün içinde, hatırı sayılır bir ücret karşılığında geri alabilir.
pendingDelete: Geri alma artık mümkün değil. Yaklaşık beş gün sonra ad yeniden tescile açılır.

Süreler uzantıya ve kayıt firmasına göre değişir; ülke kodlu uzantıların yaşam döngüsü çoğu zaman bambaşkadır. Yukarıdaki rakamları kesin bir söz olarak değil, genel uzantılardaki yaygın düzen olarak okuyun.

Bitiş tarihi: kayıt otoritesi mi, kayıt firması mı?

İnsanları en çok yanıltan kısım burasıdır.

Genel uzantılı bir alan adının süresi dolduğunda çoğu kayıt otoritesi onu silmez. Otomatik olarak bir yıl uzatır, ücretini kayıt firmasından tahsil eder ve alan adını autoRenewPeriod durumuna alır. Müşteri ödeme yapmazsa kayıt firması bu süre içinde alan adını siler ve ücretini geri alır.

Bu aralıkta açık kayıt, sahibi ödeme yapmamış ve sitesinin yerinde çoktan bir park sayfası duran bir alan adı için bir yıl sonrasını gösteren bir bitiş tarihi sunabilir. Tarih, kayıt otoritesi açısından doğrudur. Yalnızca, sizinle kayıt firmanız arasındaki ilişkiyi belirleyen tarih değildir.

Bazı kayıtlarda iki değer birlikte görünür:

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

İkisi farklıysa hizmetinizin ayakta kalıp kalmayacağını belirleyen, kayıt firmasının tarihidir. Pratik kurallar:

Önemli alan adlarını ek sürelere güvenerek değil, bitiş tarihinden epey önce yenileyin.
Tarihleri durum kodlarıyla birlikte okuyun. Uzak bir bitiş tarihi ile autoRenewPeriod yan yana duruyorsa bu "güvende" değil, "henüz ödenmemiş" demektir.
Süresi dolan bir adı almayı umuyorsanız, mevcut sahibin onu normalde redemptionPeriod sonuna kadar kurtarabileceğini bilin.

Domain yaşı

Kayıt tarihi, bir alan adının ne kadar köklü olduğuna dair kaba bir gösterge olarak sık kullanılır. Bir noktaya dikkat edin: ad silinip yeniden tescil edildiyse kayıt tarihi sıfırlanır. Bu tarih adın ilk ne zaman kullanıldığını değil, mevcut tescilin ne zaman başladığını gösterir.

OrbitProbe ile kontrol edin

OrbitProbe whois sorgulama aracı doğrudan RDAP'ı sorgular; kayıt firmasını, tarihleri, durum kodlarını, nameserver'ları ve DNSSEC durumunu kaynak sunucu ve sorgu zamanıyla birlikte gösterir. Gizlenmiş alanlar gizlenmiş olarak görünür. Birden fazla alan adı yönetiyorsanız, çalışma alanındaki portföy bitiş tarihlerini tek listede tutar ve yenileme hatırlatmaları gönderir.