Alan adı sorgulama, yalnızca bir ismin boşta olup olmadığını görmekten ibaret değildir. Yeni bir marka satın alırken, devralma görüşmesine hazırlanırken, bir tedarikçiyi incelerken veya süresi yaklaşan bir alan adını korumaya alırken aynı anda birkaç soruya cevap gerekir: Kayıt hangi tarihte yapılmış, ne zaman yenilenmeli, hangi kayıt kuruluşu üzerinden yönetiliyor, hangi durum kodları uygulanıyor ve DNS tarafında hangi hizmetler yayınlanıyor? Bu soruların her biri farklı bir veri kaynağına dayanabilir. Sağlam bir inceleme, tek satırlık sonuç yerine kayıt verisini, DNS gözlemini ve işletme bağlamını birlikte okur.
Türkçe aramalarda "domain kime ait", "alan adı sorgulama", "domain bitiş tarihi öğrenme" ve ".com.tr uygun mu" gibi ifadeler aynı ihtiyacın farklı aşamalarını gösterir. Kullanıcı önce pratik bir cevap ister, fakat satın alma veya güvenlik kararı için daha sonra kanıtın kaynağını, zamanını ve eksik olabilecek alanları sorgular. WHOIS ve RDAP burada yardımcı olur, ancak ikisi de bir web sitesinin güvenilirliğini tek başına kanıtlamaz. Kayıt verisi alan adının idari durumunu gösterir; sitenin içeriği, işletmenin gerçekliği ve gönderilen e-postanın meşruiyeti için ayrıca teknik kontroller gerekir.
WHOIS ve RDAP arasındaki temel fark
WHOIS, alan adı kayıt bilgilerine erişmek için yıllarca kullanılan bir hizmet ailesinin genel adıdır. Yanıt biçimleri kayıt kuruluşuna göre değişebilir, metin satırları eksik veya farklı etiketlerle gelebilir ve kişisel bilgiler çoğu durumda gizlenebilir. RDAP ise HTTP tabanlı, JSON yanıtlar kullanan, nesneleri ve olay tarihlerini daha tutarlı biçimde ifade eden modern protokoldür. ICANN, RDAP'ı kayıt verisine erişimin standartlaştırılmış yolu ve WHOIS'in teknik halefi olarak açıklar. Pratikte bir araştırma sistemi, desteklenen uzantıya göre RDAP verisini tercih etmeli, eski veya farklı davranan kayıt sistemlerinde sonucu bilinmiyor olarak işaretlemeli ve metin eşleştirmesiyle kesin hüküm vermemelidir.
- RDAP yanıtında alan adı, kayıt kuruluşu, nameserver, durum ve olay tarihlerini ayrı nesneler olarak arayın.
- WHOIS çıktısındaki etiketleri farklı kayıt kuruluşları arasında doğrudan aynı kabul etmeyin.
- Kişisel iletişim bilgilerinin maskelenmesini kayıt sahibinin kimliği hakkında olumlu veya olumsuz kanıt saymayın.
- Yanıtın alındığı zamanı ve ilgili kayıt kuruluşu ya da registry bilgisini araştırma notuna ekleyin.
Bir alan adı sorgusunda hangi alanlar okunmalı?
İlk olarak alan adının normalleştirilmiş biçimini kontrol edin. Büyük harf, sondaki nokta, IDN karakterleri ve punycode gösterimi aynı adı farklı biçimde gösterebilir. Ardından creation date, updated date ve expiration date alanlarını birbirinden ayırın. Güncelleme tarihi, alan adının yeni tescil edildiğini göstermez; nameserver veya kayıt kuruluşu değişikliği gibi bir işlem de bu tarihi değiştirebilir. Bitiş tarihi ise sahibinin o gün kesin olarak alan adını kaybedeceği anlamına gelmez, çünkü kayıt kuruluşu politikaları, otomatik yenileme ve kurtarma dönemleri sonucu etkiler. Yine de operasyonel takvim için en önemli sinyallerden biridir.
Durum kodları da aynı dikkatle okunmalıdır. clientTransferProhibited, clientUpdateProhibited veya serverHold gibi ifadeler farklı işlemlere ilişkin kısıtları anlatır. Bir alan adının kayıtlı olması, transfer edilebilir olduğu anlamına gelmez; bir kaydın görünmemesi de kayıt için tamamen serbest olduğu anlamına gelmez. Premium tahsis, rezerve ad, mevzuat kısıtı, bekleyen silme veya registry politikası gibi durumlar normal bir kayıt sorgusunda sınırlı görünebilir. Bu nedenle sonuç ekranında "kayıt bulunamadı" ile "satın alınabilir" ifadelerini ayırmak, kullanıcıya dürüst bir karar alanı bırakır.
.tr ve .com.tr alan adlarında yerel bağlam
Türkiye hedefleyen bir işletme için .tr, .com.tr, .net.tr veya .org.tr seçimi yalnızca marka tercihi değildir. TRABİS, .tr alan adı sisteminin merkezi bileşenlerini, başvuru ve tahsis süreçlerini ve bazı kısıtlı isim kategorilerini açıklar. Özellikle devlet, finans ve kamu kurumlarını taklit edebilecek adlar için tahsis kısıtları bulunabilir. Bu nedenle bir ismin kayıt sorgusunda boş görünmesi, aynı ismin her uzantıda veya her koşulda tahsis edileceği anlamına gelmez. Kayıt kuruluşunun güncel şartlarını, TRABİS duyurularını ve adın işletme markasıyla ilişkisini ayrıca değerlendirin.
Alan adı kayıt verisi, bir adın kayıt sistemindeki durumunu açıklar; sahibinin ticari itibarı veya web sitesinin güvenliği hakkında tek başına hüküm vermez.
Pratik inceleme ilkesi
Satın alma öncesi kontrol listesi
Bir alan adını satın almadan veya devralmadan önce araştırmayı üç aşamada yürütün. İlk aşama kayıt ve uygunluk kontrolüdür: adın doğru yazımı, uzantısı, kayıt durumu, bitiş tarihi ve durum kodları kaydedilir. İkinci aşama teknik bağlamdır: nameserver, A veya AAAA, MX, TXT ve varsa DNSSEC sinyalleri incelenir. Üçüncü aşama geçmiş ve risk kontrolüdür: alan adı daha önce hangi amaçla kullanılmış olabilir, mevcut DNS kayıtları beklenen işletmeyle uyumlu mu, sertifika ve yönlendirme davranışı tutarlı mı? Bu üç aşamadan biri atlanırsa, satın alma kararı eksik kanıta dayanır.
- Alan adını Unicode ve ASCII/punycode biçimleriyle doğrulayın.
- RDAP veya WHOIS yanıtının alındığı zamanı, kaynak registry'yi ve kayıt kuruluşunu not edin.
- Kayıt, güncelleme ve bitiş tarihlerini operasyon takvimine aktarın.
- Durum kodlarını transfer, güncelleme ve silinme süreçleri açısından açıklayın.
- DNS kayıtlarını ve SSL sertifikasını ayrı bir teknik kanıt olarak kontrol edin.
- Marka, ticaret unvanı ve olası taklit isimleri için hukuk veya marka ekibiyle inceleme yapın.
Süresi yaklaşan alan adlarını yönetme
Kurumsal portföylerde en pahalı hatalardan biri alan adı bitiş tarihini yalnızca tek bir kişinin takviminde tutmaktır. Kayıt kuruluşu hesabına erişim, otomatik yenileme kartı, transfer kilidi ve sorumlu ekip değiştiğinde bu bilgi kolayca kaybolur. RDAP tarihi iyi bir başlangıç noktasıdır, fakat her uzantının yenileme, kurtarma ve silinme zaman çizelgesi farklı olabilir. Kritik alan adları için iki kişilik sahiplik, yenileme öncesi uyarı, kayıt kuruluşu hesabı erişim testi ve DNS değişikliklerinin izlenmesi birlikte uygulanmalıdır. Sonucu WHOIS sorgulama aracı veya alan adı denetleyici ile periyodik olarak yeniden kontrol etmek, tek seferlik araştırmayı işletilebilir bir sürece dönüştürür.
Otomasyon ve API ile araştırmayı ölçekleme
Bir ajans, kayıt kuruluşu, marka koruma ekibi veya SaaS ürünü çok sayıda alan adı inceliyorsa tarayıcıda tek tek sorgulama hızla darboğaza dönüşür. Uygulama akışı önce alan adını doğrulamalı, sonra WHOIS API veya RDAP API ile kayıt verisini almalı ve cevabı alınma zamanı ile birlikte saklamalıdır. Başarılı bir akış, eksik kişisel veri alanlarını hata gibi yorumlamaz; rate limit, geçici erişim sorunu ve gerçekten kaydı olmayan ad arasında ayrım yapar. Yeniden deneme sınırları, günlük bütçe ve kullanıcıya gösterilen belirsizlik durumu da tasarlanmalıdır. Bu yaklaşım hem müşteriye daha doğru bilgi verir hem de ekiplerin yanlış uygunluk sözü vermesini önler.
Sonuçları güvenlik bağlamına yerleştirme
Alan adı sorgulama, güvenlik incelemesinin giriş kapısıdır. Kayıt tarihi veya gizlilik koruması, alan adının iyi ya da kötü olduğu anlamına gelmez. Şüpheli bir alan adı için RDAP kaydını DNS çözümlemesi, sertifika bilgisi, yönlendirme davranışı ve marka benzerliği ile karşılaştırın. Kendi portföyünüz için ise kayıt kuruluşu verisini, DNS değişikliklerini ve bitiş tarihlerini aynı olay akışında izleyin. Sonuçları kanıt türüne göre etiketlemek önemlidir: kayıt verisi, DNS gözlemi, sertifika gözlemi ve yorum aynı kategori değildir. Böylece inceleme yapan kişi hangi cümlenin doğrudan gözleme, hangisinin risk değerlendirmesine dayandığını anlayabilir.
Bir kayıt sonucu için araştırma notunda üç zamanı ayırmak yararlıdır: sorgunun yapıldığı an, registry veya kayıt kuruluşunun son güncelleme olayı ve işletme içindeki son doğrulama zamanı. Bu ayrım, eski bir bitiş tarihinin neden yeni göründüğünü veya bir nameserver değişikliğinin hangi pencere içinde yapıldığını açıklamaya yardım eder. Kayıt kuruluşu hesabındaki bilgilerle açık RDAP sonucunu eşleştirin, ancak görünmeyen kişisel alanları tahmin etmeyin. Veri yoksa bilinmiyor yazmak, doğrulanmamış bir isim üretmekten daha güvenlidir.
Araştırma notunu ekipler arasında paylaşma
Kayıt sorgusunu başkasının yeniden anlayabileceği biçimde saklayın. Alan adının tam biçimi, sorgu zamanı, kullanılan protokol, kayıt kuruluşu, olay tarihleri, durum kodları ve eksik alanlar kısa bir özetle yazılmalıdır. Satın alma ekibi bu notu teklif için, güvenlik ekibi DNS ve sertifika karşılaştırması için, hukuk ekibi ise marka araştırması için kullanabilir. Her ekip farklı bir kanıtı öne çıkarırken aynı temel kayda bağlanır. Bu, tarayıcı ekran görüntüsüne dayalı ve tekrar edilemeyen kararların yerine tarihli bir inceleme kaydı koyar.
Bir sorgu raporu oluştururken alan adının sahiplik verisini, teknik hedefini ve ticari yorumunu üç ayrı bölümde tutun. Böylece kayıt sahibi görünmediğinde DNS gözlemi kaybolmaz, DNS değiştiğinde de bunu doğrudan sahiplik devri sanmazsınız. İncelemeyi yapan kişi her bölümün hangi kaynaktan geldiğini, ne zaman gözlendiğini ve hangi karar için yeterli olduğunu görebilmelidir. Bu küçük düzen, satın alma, yenileme ve olay müdahalesinde farklı ekiplerin aynı kanıt üzerinde uzlaşmasını sağlar.
Kayıt sonucu bir satın alma kararına bağlanıyorsa teklif dosyasına sorgu zamanını, uzantı politikasını ve son gerçek zamanlı doğrulama adımını ekleyin. Birden fazla ekip aynı adı inceliyorsa her biri farklı ekran görüntüsü yerine ortak rapora bağlansın. Böylece kayıt değiştiğinde hangi kararın hangi kanıta dayandığı görülebilir ve araştırma yeniden yapılırken önceki belirsizlikler kaybolmaz.
Doğru yorumlanan bir WHOIS veya RDAP sonucu, alan adı kararlarını hızlandırır, fakat kararın sınırlarını da görünür kılar. Türkiye'deki işletmeler için .tr ekosisteminin tahsis kuralları, uluslararası uzantılarda ICANN politikaları ve kayıt kuruluşunun kendi sözleşmesi birlikte düşünülmelidir. Sorgu ekranında sonucu, kaynağı ve zamanı açıkça gösteren bir araç seçin. Ardından gerektiğinde DNS, SSL ve marka kontrolleriyle araştırmayı tamamlayın. Bu disiplin, "kime ait" sorusunu tek başına cevaplamaktan daha değerlidir; çünkü satın alma, devir, yenileme ve olay müdahalesi süreçlerinde kullanılabilecek denetlenebilir bir kayıt oluşturur.
Sonuçları paylaşırken kişisel verilerin görünürlüğünü ve kullanım amacını da sınırlayın. Kayıt verisi araştırma için gerekli olabilir, fakat gizlenmiş alanları başka kaynaklardan tahmin ederek kişisel profil oluşturmaya çalışmayın. İşletme için gereken kayıt kuruluşu, durum, tarih ve teknik bağlamı tutun; gereksiz iletişim ayrıntılarını rapora eklemeyin. Bu yaklaşım hem araştırma kalitesini hem de kullanıcı güvenini korur.
Her raporun sonunda belirsizlikleri ayrıca listeleyin: yanıt vermeyen registry, maskelenen alan, doğrulanmayan uygunluk veya gecikmeli DNS. Bu bölüm, okuyucunun sonucu olduğundan daha kesin yorumlamasını önler. Ardından araştırmanın yenilenmesi gereken tarihi ve sorumlu ekibi ekleyin. Böylece kayıt denetlenebilir, güncel ve yeniden kullanılabilir kalır.