RDAP Nedir, Alan Adı Sorgusunda WHOIS'in Yerini Ne Alıyor?

---

Bir alan adının kime ait olduğunu öğrenmek istediğinizde karşınıza iki farklı arayüz çıkabiliyor. Biri düz metin, hizalanmamış satırlardan oluşan eski tanıdık; diğeri düzenli alanlara bölünmüş, makine tarafından okunabilir bir yanıt.

İkincisinin adı RDAP ve tesadüfen ortaya çıkmadı. Aşağıda bu protokolün neden geliştirildiğini, eski sorgu yönteminin hangi eksikliklerini kapattığını, sorguların nasıl kurulduğunu ve hangi sunucuya gideceğinin nasıl bulunduğunu standart belgelerden çıkarıyoruz.

Neden yeni bir protokol?​

Standart, RDAP'ı doğrudan tanımlıyor: çok eski alan adı sorgu protokolünün halefi (RFC 7480).

Değiştirme kararının gerekçeleri de yazılı. Sorgu söz dizimini tanımlayan belge, eski protokolde zaman içinde saptanan eksiklikleri madde madde sayıyor (RFC 9082):

• Standart komut yapısı yok: Her sunucu sorguyu kendi biçiminde bekliyordu.
• Standart çıktı ve hata yapısı yok: Yanıtın biçimi sunucudan sunucuya değişiyordu.
• Uluslararasılaştırma desteği yok: Farklı dil ve yazı sistemleri için karşılık bulunmuyordu.

Eski yöntemin ne döndürdüğünü ve nasıl okunduğunu alan adı sorgusunun nasıl çalıştığını anlattığımız yazıda ele almıştık.

Sorgu nasıl kuruluyor?​

Yeni protokolün en görünür farkı, tanıdık web teknolojilerinin üstüne kurulması. Belge, kayıt bilgisini kayıt otoritelerinden almak için kullanılabilecek tekdüze adres kalıpları tanımlıyor ve bu kalıpları RESTful web erişim biçimiyle tarif ediyor.

Kapsam yalnız alan adlarıyla sınırlı değil: aynı kalıplar hem bölgesel internet kayıt kuruluşlarını hem alan adı kayıt otoritelerini içeriyor.

Sorgu türleri yol bölümleriyle ayrılıyor. Belge alan adı, ad sunucusu ve varlık sorguları için ayrı yol bölümleri tanımlıyor; bunların yanında bir yardım yolu ve arama yolları da bulunuyor.

Taşıma tarafında sürpriz yok. Protokol, standart web aktarım mekanizmalarıyla taşınıyor ve yanıtlar ayrı bir ortam türüyle etiketleniyor. Bu, yanıtın düz metin değil, ayrıştırılabilir bir veri yapısı olarak gelmesi demek.

Fark' Alıntı:

Eski yöntemde yanıtı ayrıştırmak için her sunucuya özel kural yazmanız gerekiyordu; yeni yöntemde alan adları standart.

Genişletmek için tıkla ...

Arama tarafında da tanımlı bir davranış var. Belge, kısmi arama için yıldız işaretinin sondaki sıfır ya da daha fazla karakteri eşleştirdiğini söylüyor; verilen örnekte "exam" ile başlayan bir arama kalıbı hem example.com hem example.net adreslerini eşleştiriyor, kalıbın sonuna uzantı eklendiğinde ise arama yalnız o uzantıyla sınırlanıyor.

Kural tek: bir kısmi aramada birden fazla yıldız işareti bulunamıyor. Sunucu, desteklemediği bir arama biçimiyle karşılaşırsa arama işlevinin var olduğunu ama bu sorgunun işlenemediğini bildiren bir hata kodu döndürüyor.

Bu yaklaşımın arka planını merak ediyorsanız REST mimarisini ve istek yöntemlerini anlattığımız yazı temel kavramları veriyor.

Hangi sunucuya sorulacağı nasıl biliniyor?​

Burada pratik bir sorun var: her uzantının kayıt otoritesi kendi sunucusunu işletiyor. İstemci hangi adrese soracağını nereden bilecek?

Çözüm merkezî bir yönlendirme kaydı. Alan adı alanı için tutulan önyükleme hizmeti kayıt defteri, hangi uzantının hangi sunucuya yönlendirileceğini listeliyor (IANA'nın alan adı önyükleme kayıt defteri).

Kayıt defteri 2015'te oluşturulmuş ve makine tarafından okunabilir biçimlerde yayımlanıyor. Bir uzantının listeye eklenmesi için o uzantının yöneticisinin başvurması gerekiyor; yöneticilerin iletişim bilgisi ise kök bölge veri tabanında duruyor.

Yönlendirme yalnız kayıt defteri düzeyinde kalmıyor. Protokol belgesi, sunucunun isteği başka bir adrese yönlendirebildiği bir örnek akış veriyor: istemci sorguyu gönderiyor, sunucu kalıcı yönlendirme yanıtı ve yeni konumu döndürüyor, istemci sorguyu yeni adrese tekrarlıyor.

Sizin için ne değişiyor?​

Tek bir alan adını elle sorguluyorsanız fark sınırlı; iki yöntem de size sahiplik ve tarih bilgisi veriyor.

Fark otomasyonda ortaya çıkıyor. Yanıt yapılandırılmış geldiği için bitiş tarihini, durum kodlarını ya da ad sunucularını bir betikle güvenilir biçimde okuyabiliyorsunuz. Eski yöntemde aynı işi yapmak, her kayıt otoritesinin çıktı biçimine ayrı kural yazmak demekti.

Bitiş tarihi gibi alanların neden bazen güncel görünmediğini sorgu ekranındaki bitiş tarihini doğrulamayı anlattığımız yazıda ayrıca inceledik.

Sık Sorulan Sorular​

RDAP eski sorgu yöntemini tamamen kaldırdı mı?
Standart onu halef olarak tanımlıyor. Uygulamada iki yöntem bir süre yan yana kullanıldı; hangi kayıt otoritesinin hangisini sunduğu değişebiliyor.

Yanıt neden JSON biçiminde geliyor?
Protokol yanıtları ayrı bir ortam türüyle etiketleniyor; amaç çıktının makine tarafından ayrıştırılabilir olması.

Her uzantının RDAP sunucusu var mı?
Önyükleme kayıt defterinde listelenenlerin var. Bir uzantının eklenmesi için yöneticisinin başvurması gerekiyor.

Sorgu yaptığımda yönlendirme alıyorum, normal mi?
Evet. Protokol belgesindeki örnek akışta sunucu kalıcı yönlendirme döndürüyor ve istemci sorguyu yeni adrese tekrarlıyor.

Özetle​

RDAP, alan adı kayıt bilgisini sormanın standartlaştırılmış hâli. Eski protokolün üç temel eksiğini kapatmak için geliştirildi: komut yapısının, çıktı ve hata biçiminin standart olmaması ve uluslararasılaştırma desteğinin bulunmaması. Sorgular tekdüze adres kalıplarıyla kuruluyor, yanıtlar ayrıştırılabilir bir veri yapısı olarak dönüyor ve hangi sunucuya gidileceği merkezî bir önyükleme kayıt defterinden bulunuyor. Tek bir alan adına elle bakıyorsanız fark küçük; alan adı portföyünü izleyen bir betik yazacaksanız fark her şey demek.

Alan adlarınızın bitiş tarihlerini elle mi takip ediyorsunuz, yoksa bir betikle mi?

Güncelleme: 20 Eylül 2026. RFC 7480, RFC 9082 ve IANA'nın alan adı önyükleme kayıt defteri kontrol edildi.

---