RDAP Nedir ve API ile Nasıl Sorgulama Yapılır?

Sesli Dinle — Makale

RDAP, alan adlarının, IP adresi bloklarının ve otonom sistem numaralarının kayıt verilerine HTTP üzerinden erişmek için tanımlanmış standart bir protokoldür. Bir istemci, alan adı, IP ağı, ASN, nameserver veya entity (kayıt varlığı) için uygun sorgu yolunu oluşturur ve yanıtı yapılandırılmış bir veri biçimi olan JSON biçiminde alır ve işler. Kayıt varlığı burada kişi, kuruluş veya grup gibi kayıtla ilişkili bir tarafı temsil eder.

API, uygulama programlama arayüzüdür. “RDAP API” tek bir merkezi ürün veya her sorguyu yanıtlayan ortak bir uç nokta değildir. İstemci önce sorgulanan kaynak için yetkili RDAP hizmetini bulur, ardından bu hizmetin taban adresine standart yolu ekleyerek GET veya HEAD isteği gönderir. Hazır bir sorgulama aracı bu adımları arka planda yapabilir; doğrudan API entegrasyonunda aynı işleri uygulamanın RDAP istemcisi yürütür.

RDAP ile Hangi Kayıt Türleri Sorgulanabilir?

Standart, kesin eşleşmeli kayıt sorgularını nesne türüne göre farklı yol parçalarıyla ayırır. Taban adres hizmete göre değişir; aşağıdaki yollar bu adresin sonuna eklenir.

ip yoluna tek adres eklendiğinde sunucu, o adresi tamamen kapsayan en küçük kayıtlı ağı hedefler. Ağın ortak başlangıç bitlerini belirten prefix ile prefix uzunluğu, CIDR sorgusunda ayrı yol parçalarıdır; örneğin ip/192.0.2.0/24 biçiminde gönderilir. ASN ise “AS” harfleri eklenmeden, asplain adı verilen ondalık sayı biçiminde yazılır; örneğin autnum/64496 kullanılır.

RDAP ayrıca bazı alan adı, isim sunucusu ve kayıt varlığı aramalarını destekler. Örneğin alan adı için domains?name=, nameserver için nameservers?name= veya nameservers?ip=, entity için entities?fn= veya entities?handle= biçimleri kullanılabilir. Arama desteği sunucuya ve yerel politikaya bağlıdır; kesin eşleşmeli sorgunun çalışması, tüm arama türlerinin de desteklendiği anlamına gelmez.

Yetkili RDAP Hizmeti IANA Başlangıç Verileriyle Nasıl Bulunur?

İnternet tanımlayıcılarının merkezi kayıtlarını yöneten IANA, sorgunun hangi RDAP sunucusuna gönderileceğini bulmak için bootstrap (başlangıç) verileri yayımlar. Alan adı, IPv4, IPv6 ve ASN kaynakları için ayrı JSON kayıtları vardır. Her kayıtta kapsam değerleri ile bu kapsamı yanıtlayan bir veya daha fazla taban RDAP adresi eşleştirilir.

1. Sorgu türüne karşılık gelen başlangıç kaydını seçin: alan adı, IPv4, IPv6 veya ASN.
2. Başlangıç JSON dosyasındaki services dizisini okuyun ve istemci önbelleğinde saklayın.
3. Alan adında etiketleri sağdan sola karşılaştırarak en uzun eşleşmeyi bulun.
4. IP adresinde en uzun prefix eşleşmesini, ASN’de sayıyı içeren kayıt aralığını seçin.
5. Birden fazla taban adres varsa HTTPS kullanan adresi tercih edin ve seçilen adresin sonundaki eğik çizgiyi koruyun.
6. Standart sorgu yolunu taban adrese ekleyip isteği gönderin.

Başlangıç verisini her kullanıcı sorgusunda yeniden indirmek gereksiz yük ve gecikme oluşturur. İstemci, HTTP önbellek başlıklarına uyarak veriyi saklamalı ve süresi dolduğunda yenilemelidir. Yeni tahsislerin başlangıç verisine anında eklenmesi garanti edilmediği için eşleşme bulunamadığında istemci bunu ayrı bir keşif hatası olarak bildirmelidir.

Alan adı, IP adresi ve ASN için kullanılan başlangıç kayıtları, isim sunucularını ve kayıt varlıklarını doğrudan eşlemez. Entity handle (kayıt varlığı tanıtıcısı), onu veren RDAP hizmetine özgü olabilir; bu durumda aynı hizmet veya yanıttaki ilgili bağlantı kullanılır. Ancak RFC 8521 nesne etiketlemesini destekleyen bir hizmetin verdiği tanıtıcıda, RDAP hizmetini belirten bir son ek bulunabilir. İstemci bu etiketi IANA kaydında arayarak yetkili taban adresi bulabilir; her tireli tanıtıcının bu biçime uyduğu varsayılmaz. İsim sunucusu sorgusunda ilişkili alan adı hizmeti ya da önceden bilinen yetkili bir taban adres gerekir.

HTTP İsteği ve Hata Yönetimi

RDAP, HTTP davranışlarını kullandığı için istemci yalnız JSON ayrıştırmamalı; yöntem, başlık, yönlendirme ve durum kodlarını da ayrı ayrı işlemelidir.

GET ve HEAD İstekleri

GET isteği yanıt gövdesini almak için kullanılır. İstemci, RDAP JSON istediğini belirtmek üzere Accept başlığında application/rdap+json veya genel JSON türünü gönderebilir; başarılı bir yanıtta Content-Type değerinin beklenen türle uyumlu olduğunu da kontrol etmelidir.

HEAD, kaydın sunucuda bulunup bulunmadığını yanıt gövdesini indirmeden sınamak içindir. HEAD sonucunda JSON gövdesi beklenmemeli; durum kodu ve HTTP başlıkları değerlendirilmelidir. Standart RDAP sorguları GET ve HEAD yöntemlerini kullanır; sunucunun diğer HTTP yöntemlerini desteklemesi gerekmez.

Yönlendirmeler ve Durum Kodları

Yetkili kayıt verisi başka bir hizmetteyse sunucu 301, 302, 303 veya 307 gibi bir yönlendirme yanıtı ve tam bir Location adresi döndürebilir. İstemci, döngüleri ve aşırı yönlendirmeyi önlemek için yönlendirme sayısını sınırlamalıdır. Ayrıca hedefin HTTP veya HTTPS kullandığını kontrol etmeli ve HTTPS bağlantısından şifresiz HTTP bağlantısına geçişi reddetmelidir. Bu kontrollerden geçen Location adresi değiştirilmeden yeni istekte kullanılır.

• 200: İstek başarıyla işlendi; GET yanıtı veri gövdesini içerir, HEAD yanıtında gövde bulunmaz.
• 400: Yol, karakter kodlaması veya sorgu biçimi yorumlanamadı.
• 401 veya 403: Hizmetin kimlik doğrulama ya da erişim politikası yanıtı sınırlandırdı.
• 404: Sunucuda sorguyu karşılayan kayıt bulunamadı; bu durum tek başına kaynağın küresel olarak kayıtsız olduğunu kanıtlamaz.
• 422: Sunucu aramayı desteklese de gönderilen kısmi eşleşme biçimini işleyemedi.
• 429: İstek sıklığı sınırı aşıldı; Retry-After başlığı varsa istemci belirtilen süre boyunca beklemelidir.
• 501: İstenen sorgu türü bu sunucuda uygulanmamıştır.
• 5xx: Hizmet tarafında geçici veya kalıcı bir işleme sorunu oluşmuştur.

Üretim istemcisi bağlantı ve okuma zaman aşımı, en büyük yanıt boyutu, yönlendirme sayısı ve yeniden deneme sayısı için sınır belirlemelidir. İstemci, farklı bir sunucuya yönlendirilirken kimlik doğrulama bilgilerini otomatik taşımamalı; 429 ve geçici 5xx yanıtlarında yeniden deneme sayısını sınırlayıp bekleme süresini giderek uzatmalıdır.

İstek sıklığı sınırı hizmete göre değişir. İstemci eş zamanlı sorgu sayısını sınırlamalı, aynı kaydı gereksiz yere yeniden istememeli ve uygun yanıtları önbelleğe almalıdır. Önbellek süresi, HTTP başlıkları ve uygulamanın güncellik ihtiyacıyla birlikte belirlenir.

RDAP JSON Yanıtı Nasıl Ayrıştırılır?

Başarılı bir kayıt sorgusu genellikle tek bir RDAP nesnesi, arama sorgusu ise sonuç dizileri içeren bir üst JSON nesnesi döndürür. Ayrıştırıcı, yalnız beklenen birkaç alana bağlı kırılgan bir model yerine standart ortak üyeleri, nesneye özgü alanları ve uzantıları katmanlı biçimde işlemelidir.

Ortak Üyeler ve Nesne Türü

Üst düzey rdapConformance dizisi, yanıtın hangi RDAP özelliklerine ve uzantılarına göre üretildiğini gösterir. Her kayıt nesnesindeki objectClassName alanı nesnenin domain, nameserver, entity, ip network veya autnum olarak nasıl yorumlanacağını belirtir.

links dizisi self, related veya up gibi ilişkilerle başka kaynakları gösterebilir. events dizisinde kayıt, son değişiklik veya sona erme gibi olayların türü ve zamanı bulunabilir. notices tüm yanıtı ya da hizmeti ilgilendiren açıklamaları, remarks ise içinde bulunduğu nesneye özgü uyarı ve notları taşır.

Kayıt Varlığı ve İlişkili Veriler

entities dizisi, ana nesneyle ilişkili kayıt kuruluşlarını, kişileri veya diğer varlıkları içerebilir. Her entity içinde handle, roles, publicIds, links ve iletişim verisini temsil eden vcardArray gibi üyeler bulunabilir. roles alanı registrant, registrar, administrative veya technical gibi ilişkinin niteliğini açıklar; istemci, dizideki sıraya göre rol varsaymamalıdır.

vcardArray içindeki bazı değerlerin anlamı dizideki konumlarına bağlıdır; bu yapı sıradan bir anahtar-değer nesnesi gibi ayrıştırılamaz. İletişim alanları boş, kısmi veya tamamen çıkarılmış olabilir. Sunucunun döndürmediği isteğe bağlı üyeler hata sayılmamalı ve tanınmayan uzantı üyeleri güvenli biçimde yok sayılmalıdır. Ayrıştırıcı, standart JSON üye adlarındaki büyük ve küçük harf ayrımını da korumalıdır.

Nesne Türüne Göre Alan Doğrulaması

Domain yanıtında ldhName, unicodeName, status, nameservers, secureDNS, events ve entities gibi alanlar görülebilir. IP ağı nesnesinde başlangıç ve bitiş adresleri, IP sürümü, ağ adı, ülke kodu ve üst kayıt ilişkisi; autnum nesnesinde başlangıç ve bitiş ASN değerleri bulunabilir. Ayrıştırıcı, her alanı zorunlu kabul etmemeli; doğrulamayı objectClassName ve rdapConformance değerlerine göre yapmalıdır.

Bir alanın bulunmaması, ilgili verinin gerçekte mevcut olmadığı anlamına gelmeyebilir. Alan isteğe bağlı olabilir, sunucu politikasınca çıkarılmış olabilir veya istemcinin erişim düzeyi nedeniyle gizlenmiş olabilir.

Arama yanıtları, sonuç sayısı sınırı veya yetkilendirme nedeniyle kısaltılabilir. notices ve remarks içindeki kesilme açıklamalarını okuyun; dönen ilk sonuç kümesini eksiksiz veri kümesi olarak kabul etmeyin. RDAP temel standardı her hizmet için ortak bir sayfalama davranışı garanti etmez.

RDAP Verisinde Gizlilik ve Erişim Yetkisi

RDAP, kimliği doğrulanmış ve anonim istemcilere farklı veri düzeyleri sunulmasına izin verir. Bu özellik daha fazla veriye otomatik erişim hakkı oluşturmaz; hangi alanların gösterileceğini RDAP hizmeti sağlayan kuruluşun politikası, uygulanabilir kurallar ve istemcinin yetkisi belirler.

Alan adı kayıtlarında kişisel bilgiler hiç gösterilmeyebilir, kısmen gizlenebilir veya yalnız yetkili istemcilere açılabilir. İstemci, boş değer ile verinin gizlenmesini birbirine eşitlememeli; status, notices, remarks, rdapConformance ve varsa gizlenmiş alanları belirten uzantıları birlikte değerlendirmelidir. Gizlenen veriye veya erişim izni verilmeyen alanlara ulaşmak için tekrar, kimlik değiştirme ya da sorgu dağıtma yöntemleri kullanılmamalıdır.

Günlüklerde tam sorgu hedefini, kimlik bilgilerini ve yanıt içindeki kişisel alanları gereksiz yere saklamayın. Hata kaydı için durum kodu, süre, hizmet kimliği ve sınırlı tanılama verisi çoğu durumda yeterlidir; saklama süresi ve erişim yetkisi ayrıca tanımlanmalıdır.

RDAP İstemcisinde Sorgu Hazırlama ve Yanıt İşleme

1. Girdiyi nesne türüne göre doğrulayın; alan adını, IP adresini, CIDR değerini ve ASN’yi birbirine karıştırmayın.
2. Uluslararasılaştırılmış alan adlarını (IDN) ve özel karakterleri uygun Unicode normalizasyonu ve URL yüzde kodlamasıyla hazırlayın.
3. Alan adı, IP adresi ve ASN için yetkili taban adresi IANA başlangıç verisinden bulun; kayıt varlığı ve isim sunucusu için yukarıda açıklanan hizmet seçimini kullanın. Başlangıç verisini HTTP önbellek başlıklarına göre saklayın.
4. HTTPS kullanın, sertifika doğrulamasını kapatmayın ve Accept başlığını açıkça gönderin.
5. Zaman aşımı, yanıt boyutu ve yönlendirme sınırıyla GET veya HEAD isteğini yürütün.
6. Önce HTTP durumunu ve başlıkları kontrol edin. HEAD kullandıysanız gövde beklemeyin; sonraki JSON işleme adımları GET yanıtı içindir. GET yanıtında Content-Type değerini ve JSON sözdizimini doğrulayın.
7. rdapConformance ve objectClassName değerlerinden başlayarak ortak ve nesneye özgü alanları ayrıştırın.
8. Eksik, gizlenmiş, kısaltılmış veya erişime kapalı veriyi kullanıcıya ayrı durumlar olarak gösterin.
9. 429 ve geçici hizmet hatalarında sınırlı yeniden deneme uygulayın; erişim kontrollerini aşmaya çalışmayın.
10. Yanıttan yalnız gerekli alanları kullanın ve kişisel verileri varsayılan olarak kalıcı kayda dönüştürmeyin.