WHOIS vs. RDAP: Alan Adı Sorgulama Servislerinin Geleceği
Eski ve düzensiz WHOIS protokolünün yerini neden modern, güvenli ve yapılandırılmış RDAP API'sine bıraktığını öğrenin.
Alan adı sorgulama servisleri neden önemli?
Kayıtlı her alan adının arkasında bir kayıt bulunur: hangi kayıt şirketinde (registrar) olduğu, ne zaman oluşturulduğu, ne zaman sona ereceği, hangi ad sunucularına yönlendirildiği ve hangi durum kodlarıyla kilitlendiği. Güvenlik ekipleri bu verilerle oltalama saldırılarını araştırır, marka sahipleri taklit alan adlarını tespit eder, sistem yöneticileri ise kendi alan adlarının fark edilmeden düşmediğinden emin olur. Otuz yılı aşkın süre boyunca bu kaydı okumanın yolu WHOIS idi. Bugün yerini RDAP (Registration Data Access Protocol) alıyor.
Bu rehberde iki protokolün nasıl çalıştığını, teknik olarak neyin değiştiğini, ICANN kararlarının pratikte ne anlama geldiğini ve her iki protokolü kendiniz nasıl sorgulayabileceğinizi ele alıyoruz.
Alan Adınızı ve Web Sitenizi Anında İnceleyin
TLDix'in WHOIS Domain, Hosting Tespiti ve Domain Oracle (AI) servisleri ile herhangi bir web sitesinin arka plan altyapısını saniyeler içinde analiz edin.
WHOIS protokolü nasıl çalışır?
WHOIS, ticari internetten bile eskidir. Güncel tanımı 2004 tarihli RFC 3912 yalnızca birkaç sayfadır, çünkü protokolün kendisi son derece yalındır: istemci 43 numaralı TCP portuna bağlanır, tek satırlık bir metin (genellikle alan adı) gönderir, sunucu serbest biçimli bir metinle yanıt verip bağlantıyı kapatır.
whois ornek.com
whois -h whois.verisign-grs.com example.com
Bu sadelik WHOIS'i uygulamayı kolaylaştırdı; ancak alan adı sektörü büyüdükçe ciddi eksiklikler de ortaya çıktı.
WHOIS'in zayıf yönleri
- Standart bir çıktı biçimi yok. Her kayıt operatörü ve kayıt şirketi kendi alan adlarını, tarih formatlarını ve düzenini seçer. Biri
Registry Expiry Dateyazar, diğeriexpires, bir başkasıpaid-till. Yazılımlar yüzlerce farklı biçim için kırılgan ayrıştırıcılar tutmak zorunda kalır. - Sunucu keşfi yok. Protokol, bir uzantı için hangi sunucunun yetkili olduğunu söylemez. İstemciler sabit listelere ya da yanıt metnindeki yönlendirmelere güvenir.
- Uluslararasılaştırma desteği yok. RFC 3912 karakter kodlaması tanımlamaz; Türkçe karakterler içeren adlar ve iletişim bilgileri sık sık bozuk görünür.
- Kimlik doğrulama ve şifreleme yok. Trafik düz metindir ve farklı kullanıcılara farklı erişim seviyeleri vermek mümkün değildir.
- İnce (thin) ve kalın (thick) model karmaşası. .com gibi ince kayıt modelinde kayıt operatörü yalnızca temel bilgileri tutar; geri kalanı için istemcinin kayıt şirketinin WHOIS sunucusuna yönlenmesi gerekir.
RDAP nedir ve nasıl çalışır?
RDAP, IETF bünyesindeki WEIRDS çalışma grubunda doğrudan WHOIS'in halefi olarak geliştirildi. Özel bir metin protokolü yerine sıradan HTTPS istekleri kullanır ve JSON döndürür. Sorgular REST tarzı URL'lerdir; bu sayede herhangi bir HTTP istemcisi, tarayıcı veya betik dili özel bir kütüphaneye ihtiyaç duymadan RDAP kullanabilir.
RDAP'ı tanımlayan RFC'ler
| RFC | Konu | Durum |
|---|---|---|
| RFC 7480 | RDAP'ta HTTP kullanımı | İnternet Standardı |
| RFC 7481 | Güvenlik servisleri (kimlik doğrulama, TLS, erişim kontrolü) | İnternet Standardı |
| RFC 7482 → RFC 9082 | Sorgu biçimi (URL yolları) | 9082, 7482'nin yerini aldı |
| RFC 7483 → RFC 9083 | JSON yanıt biçimi | 9083, 7483'ün yerini aldı |
| RFC 7484 → RFC 9224 | Yetkili sunucunun bulunması (bootstrap) | 9224, 7484'ün yerini aldı |
| RFC 7485 | Mevcut WHOIS verilerinin envanteri | Bilgilendirici |
Sorgu türleri
RDAP az sayıda nesne yolu tanımlar. Alan adı sahipleri için en kullanışlı olanlar şunlardır:
/domain/ornek.com– bir alan adının kayıt verileri/nameserver/ns1.ornek.com– bir ad sunucusu hakkında bilgi/entity/TANIMLAYICI– kayıt şirketi, kayıt sahibi veya başka bir iletişim nesnesi/ip/192.0.2.0ve/autnum/64496– bölgesel internet kayıt kuruluşlarının sunduğu IP blokları ve AS numaraları
Bootstrap: doğru sunucuyu bulmak
IANA, her uzantıyı, IP aralığını ve AS numarası aralığını ilgili RDAP servisinin temel URL'sine eşleyen JSON bootstrap dosyaları yayımlar. Alan adları için dosya https://data.iana.org/rdap/dns.json adresindedir. İstemci sorgudaki uzantıyı okur, dosyada arar ve isteği listelenen adrese gönderir. Böylece WHOIS istemcilerinin ihtiyaç duyduğu tahmin yürütme ve sabit sunucu listeleri ortadan kalkar.
WHOIS ile RDAP karşılaştırması
| Özellik | WHOIS | RDAP |
|---|---|---|
| Taşıma | TCP 43. port, düz metin | HTTPS (TLS ile şifreli) |
| Yanıt biçimi | Sunucuya göre değişen serbest metin | Standart JSON (RFC 9083) |
| Sunucu keşfi | Yok; sabit listeler veya yönlendirmeler | IANA bootstrap kayıtları (RFC 9224) |
| Karakter seti | Tanımsız | UTF-8, uluslararası alan adı desteği |
| Erişim kontrolü | Mümkün değil | Destekleniyor; kademeli erişim sağlanabilir |
| Hata bildirimi | Düzensiz metin mesajları | 404, 429 gibi HTTP durum kodları |
| Genişletilebilirlik | Yok | Kayıtlı uzantılar ve rdapConformance bildirimi |
Hangi durumda hangisi?
Komut satırında hızlıca bir alan adına bakmak istiyorsanız klasik whois komutu hâlâ pratik olabilir, ancak gTLD'lerde artık eksik ya da boş yanıt alma ihtimaliniz var. Otomasyon, izleme veya raporlama söz konusu olduğunda tercih her zaman RDAP olmalıdır: yanıt yapısı tüm operatörlerde aynıdır, tarih alanları tek bir biçimdedir ve hata durumları HTTP kodlarıyla açıkça bildirilir. WHOIS'i yalnızca RDAP sunmayan uzantılar için yedek yöntem olarak düşünün.
Uygulamada RDAP sorgulamak
RDAP sadece HTTPS olduğu için curl yeterlidir. Kayıt operatörünü doğrudan sorgulayabilir ya da IANA bootstrap verisini okuyup sizi yetkili sunucuya yönlendiren rdap.org gibi bir servis kullanabilirsiniz.
curl -s https://rdap.verisign.com/com/v1/domain/example.com
curl -sL https://rdap.org/domain/example.com
Kısaltılmış bir yanıt şöyle görünür:
{
"objectClassName": "domain",
"ldhName": "EXAMPLE.COM",
"status": ["client delete prohibited", "client transfer prohibited"],
"events": [
{"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
{"eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z"}
],
"nameservers": [{"ldhName": "A.IANA-SERVERS.NET"}]
}
Yenileme takibi açısından en önemli kısım events dizisidir: expiration olayı ISO 8601 biçiminde, makinenin okuyabileceği bir zaman damgasıdır; 03/04/2027 ifadesinin mart mı nisan mı olduğunu tahmin etmeniz gerekmez. Durum değerleri RFC 5731'de tanımlanan EPP durum kodlarını küçük harf ve boşluklarla yansıtır. İletişim bilgileri entities içinde, geleneksel olarak jCard (RFC 7095) biçiminde yer alır; yeni uygulamalar alternatif olarak JSContact eklemeye başladı.
Hatalar ve sorgu limitleri
RDAP sunucuları standart HTTP anlamlarını kullanır. 404, nesnenin o sunucuda bulunmadığı anlamına gelir; bir alan adı için bu genellikle kayıtlı olmadığını gösterir. 429 ise hız sınırına takıldığınızı belirtir; düzgün bir istemci beklemeli ve daha sonra yeniden denemelidir. Sunucular arası yönlendirmeler için 301, 302 ve 307 kodları kullanılır, bu yüzden yönlendirmeleri her zaman takip edin.
ICANN politikası ve 2025 WHOIS kapanışı
ICANN, gTLD kayıt operatörleri ve kayıt şirketlerinden 26 Ağustos 2019'dan itibaren RDAP hizmeti sunmalarını zorunlu tuttu. Birkaç yıl boyunca iki protokol paralel çalıştı. Kayıt operatörü ve kayıt şirketi sözleşmelerinde yapılan değişikliklerin ardından ICANN, 28 Ocak 2025 tarihini jenerik uzantılar için 43. port WHOIS yükümlülüğünün sona erdiği gün olarak belirledi. Bu tarihten itibaren .com, .net, .org ve yeni gTLD'ler için kayıt verilerinin kesin kaynağı RDAP oldu.
Bazı operatörler 43. port sorgularını gönüllü olarak yanıtlamayı sürdürüyor, ancak buna güvenmemelisiniz. gTLD alan adları için WHOIS metnini ayrıştıran tüm betik ve izleme sistemleri RDAP'a taşınmalıdır.
Ülke kodlu uzantılar ne durumda?
.tr, .de veya .es gibi ccTLD'ler ICANN sözleşmelerine bağlı değildir ve kendi politikalarını belirler. Giderek artan sayıda ccTLD, IANA bootstrap dosyasında RDAP adresi yayımlıyor; ancak pek çoğu hâlâ yalnızca WHOIS sunuyor, bazıları ise herkese açık hiçbir servis sunmuyor. Bu yüzden pratik bir istemci önce bootstrap dosyasını kontrol eder, RDAP adresi listelenmemişse ilgili ccTLD'nin WHOIS sunucusuna geri döner.
Gizlilik, maskeleme ve KVKK/GDPR
Mayıs 2018'de GDPR yürürlüğe girdiğinden beri gTLD kayıtlarındaki kişisel verilerin çoğu maskeleniyor. RDAP tek başına WHOIS'ten daha fazla bilgi açığa çıkarmaz; aynı politikalar geçerlidir. RDAP'ın getirdiği yenilik, maskelemeyi standart bir şekilde ifade edebilmesi ve ilke olarak kolluk kuvvetleri gibi kimliği doğrulanmış kullanıcılara daha kapsamlı kayıtlara erişim tanıyabilmesidir. Sözleşmeli tarafların 21 Ağustos 2025'e kadar uygulamak zorunda olduğu ICANN Kayıt Verileri Politikası, hangi alanların toplanacağını, yayımlanacağını veya maskeleneceğini belirler.
Alan adı sahiplerinin çoğu için bu şu anlama gelir: herkese açık bir sorguda kayıt şirketi, tarihler, ad sunucuları ve durum kodları görünür, ancak kayıt sahibinin adı ya da e-posta adresi görünmez. Kayıt sahibine ulaşmanız gerekiyorsa kayıt şirketinin kaydı genellikle bir iletişim formuna veya kötüye kullanım (abuse) adresine bağlantı verir.
RDAP ile yenileme ve süre sonu takibi
Bir avuçtan fazla alan adı yöneten herkes için RDAP'a geçiş iyi bir haber. Bitiş tarihleri tutarlı ve ayrıştırılabilir biçimde gelir, durum kodları standarttır ve kayıt şirketi IANA kimlik numarasıyla tanımlanır. Bu, otomatik izlemeyi WHOIS metnini kazımaktan çok daha güvenilir kılar.
- Yetkili RDAP sunucusunu IANA bootstrap dosyasından bulun.
- Alan adı nesnesini çekin ve
expirationolayını okuyun. client hold,redemption periodveyapending deletegibi sorun işaret eden durum kodlarını kontrol edin.- RDAP sunmayan uzantılarda WHOIS'e geri dönün ve hız sınırlarına uymak için sonuçları önbelleğe alın.
TLDix tam olarak bu yaklaşımı izler. Alan adı WHOIS ve RDAP sorgulama aracı önce RDAP'ı dener, gerektiğinde WHOIS'e geçer; hosting sorgulama aracı ise RDAP'ın IP ve ASN tarafını kullanarak bir alan adının arkasındaki sunucuyu kimin işlettiğini gösterir. Takip edilen alan adlarının bitiş tarihlerinin nasıl kontrol edildiğini dokümantasyonda bulabilirsiniz.
Akılda tutulması gerekenler
WHOIS internete uzun yıllar iyi hizmet etti, ancak hiçbir zaman yapılandırılmış veri, uluslararasılaştırma veya erişim kontrolü için tasarlanmadı. RDAP bu sorunları HTTPS ve JSON üzerine inşa ederek, net bir RFC seti ve IANA tarafından yönetilen bir keşif mekanizmasıyla çözüyor. Jenerik uzantılarda geçiş fiilen tamamlandı; ccTLD'ler ise kendi hızlarında ilerliyor. Araç geliştiriyorsanız yeni kodunuzu RDAP üzerine yazın ve WHOIS'i yalnızca yedek olarak tutun. Sadece alan adı sahibiyseniz bu değişim, daha doğru bitiş tarihleri ve daha az sürpriz demek.