WHOIS Kimlik Gizleme Kurallarını Anlamak

İnternet tarihinin büyük bölümünde bir alan adını sorgulamak, sahibinin adını, posta adresini, telefon numarasını ve e-posta adresini açık metin olarak görmek anlamına geliyordu. Bu durum 2018’den sonra köklü biçimde değişti. Bugün bir .com alan adı için yapılan tipik bir sorgu; kayıt firmasını, tarihleri ve durum kodlarını gösterirken kayıt sahibi alanlarında “REDACTED FOR PRIVACY” ifadesi ya da bir iletişim formuna yönlendirme yer alıyor. Bunun neden böyle olduğunu ve hangi bilgilerin görünür kalacağına hangi kuralların karar verdiğini anlamak; hem gizlilik isteyen alan adı sahiplerine hem de meşru bir nedenle bir alan adı sahibine ulaşması gereken kişilere yardımcı olur.

Açık WHOIS’ten maskelenmiş kayıtlara

WHOIS, ağın küçük olduğu ve iletişim bilgilerini yayımlamanın teknik sorunları çözmek için pratik bir yol olduğu bir dönemde tasarlandı. Alan adları ticari varlıklara dönüştükçe aynı açık veriler spam, dolandırıcılık ve kimlik hırsızlığı için kullanılmaya başlandı. Kayıt firmaları buna ücretli gizlilik hizmetleri sunarak yanıt verdi; ancak kamuya açık kaydın kendisi, Avrupa veri koruma hukuku bir değişikliği zorunlu kılana kadar açık kaldı.

Genel Veri Koruma Tüzüğü (GDPR) 25 Mayıs 2018’de uygulanmaya başladığında ICANN, kayıt firmalarının ve kayıt otoritelerinin kayıt sahiplerine ait kişisel verileri yayımlamayı bırakmasına izin veren, pek çok durumda da bunu zorunlu kılan bir Geçici Şartname (Temporary Specification) kabul etti. Bu geçici düzen daha sonra ICANN’in Hızlandırılmış Politika Geliştirme Süreci (EPDP) ile hazırlanan bir uzlaşı politikasıyla değiştirildi.

GDPR kaynaklı maskeleme neyi gizler, neyi bırakır?

Maskeleme kişisel verilere uygulanır. Bu nedenle herkese açık gTLD sorgularında genellikle şunları görürsünüz:

• Görünür kalanlar: alan adı, kayıt firması ve IANA kimlik numarası, kayıt firmasının kötüye kullanım (abuse) iletişim bilgisi, oluşturulma, güncellenme ve bitiş tarihleri, ad sunucuları, DNSSEC durumu ve EPP durum kodları.
• Çoğu zaman görünenler: kayıt sahibinin ülkesi ile eyalet veya il bilgisi; kayıt sahibi yayımlanmasına onay verdiyse bazen kuruluş adı.
• Genellikle gizlenenler: kayıt sahibinin adı, açık adresi, telefon numarası ve e-posta adresi ile idari ve teknik iletişim kişilerine ait aynı alanlar.

Kayıtta e-posta adresi yerine genellikle kayıt firmasının işlettiği bir web formu veya anonimleştirilmiş bir yönlendirme adresi yer alır. Böylece insanlar sahibin kimliğini öğrenmeden ona yine de ulaşabilir. Pek çok kayıt firması, AB’deki kişileri diğerlerinden güvenilir biçimde ayırmak zor olduğu için maskelemeyi yalnızca AB’dekilere değil, dünya genelindeki tüm kayıt sahiplerine uygular.

Gizlilik ve vekil hizmetleri ile maskeleme karşılaştırması

Maskeleme ile gizlilik hizmetleri sıklıkla birbirine karıştırılır; oysa işleyişleri farklıdır.

Vekil hizmetinde hukuken kayıt sahibi sağlayıcının kendisidir; siz onun müşterisi konumundasınız. Vekil hizmetinin kullanım şartlarının bu kadar önemli olmasının nedeni budur: kötüye kullanım bildirimleri veya hukuki talepler karşısında sağlayıcının kimliğinizi ne zaman açıklayacağına ya da hizmeti ne zaman askıya alacağına bu şartlar karar verir.

RDAP: modern sorguların arkasındaki protokol

Kayıt Verisi Erişim Protokolü (RDAP), klasik WHOIS’in yapılandırılmış ve JSON tabanlı halefidir. Standart yanıtları, uluslararasılaştırılmış verileri ve güvenli HTTPS iletimini destekler; daha da önemlisi, farklılaştırılmış erişime olanak tanır. Yani kimliği doğrulanmış kullanıcılar, ilke olarak anonim kullanıcılardan daha fazla alan görebilir. ICANN akreditasyonlu kayıt firmaları ve gTLD kayıt otoriteleri RDAP hizmeti sunmakla yükümlü tutuldu; gTLD’ler için port 43 WHOIS hizmeti işletme zorunluluğu ise 28 Ocak 2025’te sona erdi. Pek çok hizmet hâlâ WHOIS sorgularına yanıt veriyor, ancak yetkili kaynak artık RDAP’tir. Teknik farkları WHOIS ve RDAP protokolleri yazımızda ayrıntılı olarak ele alıyoruz.

ICANN Kayıt Verisi Politikası

Kayıt Verisi Politikası (Registration Data Policy), EPDP çalışmalarının sonucunda ortaya çıkan uzlaşı politikasıdır. 2024’te yayımlandı ve Geçici Şartname ile ara politikanın yerini alarak 21 Ağustos 2025’te uygulanabilir hâle geldi. Başlıca hükümleri şunlardır:

1. Veri minimizasyonu: Kayıt firmaları yalnızca gerekli olanı toplar; ayrı bir idari iletişim kişisi gibi bazı alanların toplanması artık zorunlu değildir.
2. Yayımlama kuralları: Kayıt sahibi açıkça onay vermedikçe kişisel veriler herkese açık yanıtlardan çıkarılır.
3. Ulaşılabilirlik: Bir form veya anonim e-posta adresi, kayıt sahibinin adresi açıklanmadan ona ulaşılmasını sağlamalıdır.
4. İfşa talepleri: Kayıt firmaları, gizli verilere ilişkin talepleri almak ve belirlenen süreler içinde yanıtlamak için bir süreç işletmelidir.
5. Tüzel ve gerçek kişiler: Kayıt firmaları şirketler ile bireyler arasında ayrım yapabilir, ancak bunu yapmak zorunda değildir.

Meşru menfaatle gizli verilere erişim talebi

Maskeleme, kayıt verilerini tamamen ulaşılmaz hâle getirmez. Kolluk kuvvetleri, fikri mülkiyet hakkı sahipleri, siber güvenlik araştırmacıları ve dolandırıcılık mağdurları, alan adının bağlı olduğu kayıt firmasından veri ifşası talep edebilir. GDPR kapsamında kayıt firması, talep edenin meşru menfaatini kayıt sahibinin haklarıyla tartmak zorundadır. Bu nedenle iyi hazırlanmış bir talep:

• talep edeni ve onun yetkisini ya da rolünü belirtmeli;
• alan adını ve ihtiyaç duyulan belirli veri alanlarını açıkça yazmalı;
• amacı ve hukuki dayanağı, ekran görüntüleri veya marka tescil belgeleri gibi kanıtlarla açıklamalı;
• verinin neden gerekli olduğunu ve daha az müdahaleci seçeneklerin neden yeterli olmadığını göstermelidir.

Kayıt Verisi Talep Hizmeti (RDRS)

ICANN, Kasım 2023’te bu talepleri katılımcı kayıt firmalarına iletmek için ücretsiz ve merkezi bir sistem olan Registration Data Request Service’i (RDRS) başlattı. Sistem talepleri yönlendirir ama karara bağlamaz: son kararı yine kayıt firması verir ve sisteme katılım gönüllülük esasına dayanır.

Avrupa Birliği’nde NIS2

AB’nin NIS2 Direktifi, AB’ye hizmet veren kayıt otoriteleri ve kayıt firmaları için ek yükümlülükler getirir. Bunlar arasında doğru kayıt verisi tutmak ve meşru erişim talep edenlerin hukuka uygun taleplerine gecikmeksizin yanıt vermek yer alır; referans süre olarak 72 saat esas alınır. Ulusal uygulamalar üye devletlere göre farklılık gösterir.

ccTLD’ler kayıt sahibi gizliliğini nasıl ele alıyor?

ccTLD kayıt otoriteleri ICANN politikasıyla bağlı değildir ve çoğunlukla ulusal mevzuata dayanan kendi kurallarını belirler:

• .de: DENIC, herkese açık sorgusunda kayıt sahibinin kişisel verilerini yayımlamaz ve erişim taleplerini kendi prosedürüyle değerlendirir.
• .uk: Nominet, bireysel kayıt sahiplerinin kişisel verilerini gizler; kuruluşlara ait bazı bilgiler görünür kalabilir.
• .eu: EURid, kamuya açık olarak sınırlı veri, esas olarak bir e-posta iletişim bilgisi ve dil tercihini gösterir; gerekçeli taleplerde daha fazlası paylaşılabilir.
• .tr: TRABIS üzerinden yönetilen .tr alan adlarının kayıt sahibi verileri Kişisel Verilerin Korunması Kanunu (KVKK) çerçevesinde işlenir ve kişisel bilgiler açıkça gösterilmez.

Kurallar bu kadar farklı olduğu için bir uzantı için son derece normal olan bir sorgu sonucu, başka bir uzantıda eksikmiş gibi görünebilir. Bir ccTLD için veri talebinde bulunacaksanız, ICANN süreçleri yerine doğrudan ilgili ulusal kayıt otoritesinin web sitesindeki başvuru prosedürünü ve istenen belgeleri incelemeniz gerekir.

Maskeleme transferleri, yenilemeleri ve doğrulamayı nasıl etkiler?

Gizlilik kurallarının, alan adı sahiplerinin çoğunlukla bir şeyler ters gittiğinde fark ettiği yan etkileri vardır. 2018’den önce alan kayıt firması, kayıt sahibinin e-posta adresini WHOIS’ten okuyup transfer onayını oraya gönderebiliyordu. Bu adres artık gizli olduğundan gTLD transferlerindeki eski yetkilendirme formu (Form of Authorization) adımı aynı şekilde uygulanmıyor ve yetki kodu, kontrolün temel kanıtı hâline geldi. Bu da kodu korumayı daha da önemli kılıyor; ayrıntıları alan adı transfer kilidi rehberimizde anlatıyoruz.

Maskeleme, süresi dolan veya ikinci el piyasadan alınan alan adlarını satın alanları da etkiler. Eskiden sahibin adını okuyarak yapılan ön inceleme, artık kayıt tarihlerine, durum kodlarına, geçmiş DNS verilerine ve satıcının iş birliğine dayanıyor. Ayrıca hatırlatma e-postaları kayıt firmasından kimsenin göremediği bir adrese gittiği için güncelliğini yitirmiş bir e-posta adresi, kaçırılan yenileme bildirimlerine ve doğrulama taleplerine sessizce yol açabilir.

• E-posta sağlayıcınızı veya şirket alan adınızı değiştirdiğinizde, kullandığınız her kayıt firmasında kayıt sahibi iletişim bilgisini güncelleyin.
• İletişim doğrulama e-postalarına hızla yanıt verin; bunları görmezden gelmek alan adının askıya alınmasına yol açabilir.
• Bitiş tarihleri için yalnızca kayıt firmasının hatırlatmalarına güvenmeyin; bu mesajlar kolayca tanıtım e-postası olarak filtrelenebilir.

Alan adı sahipleri için pratik öneriler

Gizlilik, kayıt verilerini doğru tutma sorumluluğunuzu ortadan kaldırmaz. Kayıt firmaları iletişim bilgilerini düzenli aralıklarla doğrular ve yanıtsız kalan bir doğrulama e-postası askıya almayla sonuçlanabilir. E-posta adresinizi güncel tutun, herkese açık kaydınızda neyin göründüğünü TLDix WHOIS/RDAP sorgusu ile kontrol edin ve maskelemenin yalnızca kayda uygulandığını unutmayın: adınız SSL sertifikası ayrıntılarında, künye sayfalarında veya DNS TXT kayıtlarında yine görünebilir. Birden fazla alan adı yönetiyorsanız bitiş tarihlerini alan adı panelinde takip etmek, unutulmuş bir gelen kutusuna düşebilecek kayıt firması e-postalarına bağımlı kalmamanızı sağlar.