Bir WHOIS kaydını nasıl okumalısınız?

WHOIS mü, RDAP mi? İkisi arasındaki fark

WHOIS, 1980'lerden kalma, düz metin tabanlı ve TCP 43 portu üzerinden çalışan eski bir protokoldür (RFC 3912); çıktısı registrar'dan registrar'a biçim olarak değişir, makine tarafından güvenilir biçimde ayrıştırılması zordur. RDAP (Registration Data Access Protocol, RFC 7480-7484) ise WHOIS'in HTTP/JSON tabanlı modern yerine geçenidir: yapılandırılmış, standart alan adları taşıyan bir JSON nesnesi döner ve IANA'nın bootstrap kayıt listesi üzerinden hangi registry'nin sorumlu olduğu otomatik bulunur.

Günümüzde çoğu registry RDAP'ı destekler; klasik WHOIS ise özellikle .tr gibi bazı ülke kodu uzantılarında veya RDAP'ın henüz tam devreye alınmadığı durumlarda yedek olarak kullanılır. WHOIS Sorgulama aracı önce RDAP'ı dener, kullanılamıyorsa klasik WHOIS'e (IANA referral üzerinden) düşer; hangi kaynaktan geldiğini "ham çıktı" seçeneğiyle de görebilirsiniz.

Terminalden hızlı bir kontrol için klasik WHOIS'e "whois example.com" komutuyla, RDAP'a ise doğrudan bir HTTP isteğiyle (örneğin "curl https://rdap.org/domain/example.com") ulaşabilirsiniz; rdap.org, IANA'nın bootstrap listesini kullanarak isteği doğru registry'ye otomatik yönlendiren pratik bir aracı hizmettir. RDAP cevabı standart bir JSON şeması izlediği için, çıktıyı bir betikte işlemeniz gerekiyorsa RDAP klasik WHOIS'in düz metnine göre çok daha güvenilir bir kaynaktır.

Tarih alanları: kayıt, güncelleme, bitiş

Bir WHOIS/RDAP kaydında üç temel tarih bulunur: "Creation Date" (alan adının ilk kayıt tarihi), "Updated Date" (kayıtta herhangi bir alanın -nameserver, sahiplik, durum kodu- son değiştiği tarih) ve "Registry Expiry Date" (mevcut kayıt döneminin biteceği tarih). Tarihler genelde ISO 8601 biçiminde ve UTC olarak verilir, örneğin 2027-03-14T10:00:00Z gibi.

"Updated Date"in yakın bir tarih göstermesi domain'in el değiştirdiği anlamına gelmez; nameserver değişimi, durum kodu güncellemesi veya sadece registrar'ın teknik senkronizasyonu da bu alanı günceller. Bitiş tarihine kalan gün sayısını takip etmek pratik açıdan en kritik olanıdır çünkü süresi dolan bir alan adı önce "redemptionPeriod" durumuna düşer, kurtarılmazsa serbest bırakılır; WHOIS Sorgulama bu süreyi "X gün kaldı" olarak doğrudan hesaplar.

Bazı registry'ler ayrıca "Registrar Registration Expiration Date" gibi neredeyse aynı anlama gelen ama farklı adlandırılmış tekrar alanlar da döner; bu genelde registrar seviyesindeki bir kopya veya farklı bir zaman dilimiyle ifade edilmiş aynı bilgidir, karıştırmamak için hangi tarihin resmi bitiş tarihi olduğuna (genelde "Registry Expiry Date") bakmak yeterlidir. Otomatik yenileme (auto-renew) açık bir domainde bu tarih genelde her yıl sorunsuz ilerler; kapalıysa bitiş tarihine birkaç hafta kala bir hatırlatma kurmak, alan adını kaybetmemenin en basit yoludur.

EPP durum kodları neyi anlatır?

EPP (Extensible Provisioning Protocol) durum kodları, bir alan adında hangi işlemlerin kilitli olduğunu gösteren standart etiketlerdir ve ICANN tarafından tanımlanır. En sık görülenler "client" önekiyle registrar'ın, "server" önekiyle registry'nin uyguladığı kilitleri ayırt eder: clientTransferProhibited (registrar değişikliği kilitli, genelde istenerek eklenen bir koruma), clientDeleteProhibited (yanlışlıkla silinmeyi önler), clientUpdateProhibited (kayıt bilgisi değişikliği kilitli), ok (herhangi bir kısıtlama yok, normal durum).

Daha ciddi kodlar da vardır: clientHold/serverHold alan adının DNS'ten çıkarıldığını (genelde ödeme veya kötüye kullanım anlaşmazlığında) gösterir; pendingDelete ve redemptionPeriod, alan adının silinme sürecinde olduğunu, kısa bir kurtarma penceresinin kaldığını belirtir. Bir alan adı satın alırken veya transfer ederken bu kodları kontrol etmek, sürprizle karşılaşmamak için ilk bakılması gereken yerdir.

Birden fazla kod aynı anda görünmesi normaldir; örneğin çoğu registrar, müşterisini yanlışlıkla domain kaybından korumak için varsayılan olarak hem clientTransferProhibited hem clientDeleteProhibited ekler. Bir domain'i başka bir registrar'a taşımak istediğinizde önce bu kilitleri kaldırmanız (genelde registrar panelinden tek tıkla) ve ICANN'ın zorunlu tuttuğu bir transfer kilidi kodunu (auth code / EPP code) talep etmeniz gerekir.

• clientTransferProhibited / serverTransferProhibited — transfer kilitli
• clientDeleteProhibited / serverDeleteProhibited — silme kilitli
• clientUpdateProhibited / serverUpdateProhibited — bilgi güncelleme kilitli
• clientHold / serverHold — alan adı DNS'te yayınlanmıyor
• pendingDelete / redemptionPeriod — silinme sürecinde, kısa kurtarma penceresi

Kişisel veriler neden gizli (KVKK/GDPR)

2018'de GDPR yürürlüğe girdikten sonra çoğu registry, alan adı sahibinin ad, e-posta, telefon ve adres bilgilerini herkese açık WHOIS çıktısında göstermeyi bıraktı; bunun yerine "Redacted for Privacy" gibi bir ifade veya registrar'ın sağladığı bir vekil e-posta görürsünüz. Türkiye'de de KVKK (Kişisel Verilerin Korunması Kanunu) benzer bir gerekçeyle .tr kayıtlarında bireysel sahiplik bilgilerinin doğrudan gösterilmesini sınırlar.

Bu, kayıt sahibinin bilgisinin tamamen kaybolduğu anlamına gelmez: registrar, yasal bir talep (marka ihlali, mahkeme kararı gibi) karşısında bilgiyi paylaşabilir; bazı registry'ler ayrıca web tabanlı bir iletişim formu sunar. Kurumsal alan adlarında (şirket adına kayıtlı) bilgiler genelde daha az kısıtlanır çünkü GDPR/KVKK öncelikle gerçek kişileri korur.

Bu maskeleme kural olarak sahiplik bilgisi (registrant), teknik ve idari iletişim alanlarını kapsar; registrar adı, kayıt/bitiş tarihleri, nameserver'lar ve durum kodları gibi işlevsel alanlar genelde açık kalır çünkü bunlar kişisel veri sayılmaz. Dolayısıyla bir domain'in kim tarafından yönetildiğini bilemeseniz bile, ne zaman kaydedildiğini, hangi registrar üzerinden yönetildiğini ve hangi sunuculara işaret ettiğini WHOIS'ten öğrenmeye devam edebilirsiniz.

.tr uzantısı ve TRABİS

tr alan adları, Türkiye'nin ülke kodu üst düzey alan adı (ccTLD) olarak diğer birçok uzantıdan farklı bir sistemle yönetilir: TRABİS (Türkiye Alan Adı Yönetim Sistemi), merkezi bir platform üzerinden yürütülür ve WHOIS sorguları klasik olarak whois.trabis.gov.tr üzerinden cevaplanır. Bu geçiş, .tr kayıtlarının eskiden nic.tr'nin doğrudan yürüttüğü yapıdan, akredite edilmiş registrar'ların (kayıt kuruluşlarının) işlem yaptığı bir modele geçmesini sağladı.

Pratikte bu, .tr için sorgu yaptığınızda RDAP desteğinin diğer büyük uzantılara (.com, .net) göre daha sınırlı olabileceği, bazı alanların (örneğin bazı tarih biçimleri veya durum kodu adlandırmaları) TRABİS'e özgü küçük farklar taşıyabileceği anlamına gelir. WHOIS Sorgulama aracı .tr domainlerini de klasik WHOIS üzerinden otomatik sorgulayıp aynı okunabilir biçimde sunar.

Bir diğer fark, .tr'de bazı ikinci seviye uzantıların (com.tr, org.tr, edu.tr gibi) farklı kayıt şartlarına tabi olmasıdır; örneğin edu.tr yalnızca eğitim kurumlarına açıktır ve kayıt sırasında belge talep edilir. Bu tür kurallar WHOIS çıktısında doğrudan görünmez ama bir .tr alan adının com.tr yerine neden doğrudan .tr olarak kayıtlı olduğunu ya da tersini anlamak isteyenler için TRABİS'in kendi kayıt politikasına bakmak gerekir.

Ham çıktıyı okumak ve tamamlayıcı araçlar

Bazen registrar'ın eklediği özel notlar veya standart alanlara girmeyen ek bilgiler yalnızca ham WHOIS görünümünde bulunur; bu yüzden yorumlanmış özet yeterli gelmediğinde ham çıktıya bakmak faydalıdır. WHOIS kaydı bir alan adının kimin/hangi kuruluşun elinde olduğunu gösterirken, o alan adının şu an nereye çözümlendiğini göstermez — bunun için ayrı bir DNS sorgusu gerekir.

Bir domain'i değerlendirirken WHOIS'i tek başına değil, tamamlayıcı araçlarla birlikte okumak daha güvenilirdir: DNS Sorgulama ile kaydın hangi sunuculara işaret ettiğini, Domain IP Bulma ile IP'nin hangi barındırma sağlayıcısına ait olduğunu, NS Sorgulama ile yetkili ad sunucularının kim tarafından işletildiğini görebilirsiniz. Bu üçü birlikte, WHOIS'in vermediği "domain şu an gerçekte nerede çalışıyor" sorusunu cevaplar.

Bir domain satın alma sürecindeyseniz sıra genelde şöyle işler: önce WHOIS ile kayıt/bitiş tarihlerini ve EPP kodlarını kontrol edin, transferi engelleyen bir kilit varsa satıcıdan kaldırmasını isteyin; ardından DNS ve NS kayıtlarına bakarak domain'in şu an gerçekten kullanılıp kullanılmadığını (aktif bir site/e-posta trafiği var mı) doğrulayın. Bu iki adımı atlayıp doğrudan transfer koduna geçmek, kilitli veya süresi yakın dolan bir domain'de sürpriz gecikmelere yol açabilir. Transfer işlemi genelde 5-7 gün sürer ve bu süre boyunca domain eski sahibinin kontrolünde kalmaya devam eder; bu yüzden kritik bir taşıma öncesi WHOIS'ten mevcut durumu teyit etmek, sürecin ne kadar süreceğini baştan öngörmenizi sağlar.