Alan Adı Sorumlulukları

1. Arka Plan ve Amaç

Bu sayfa, ICANN’in 2009 tarihli Tescil Eden Akreditasyon Sözleşmesi (Registrar Accreditation Agreement — “RAA”) kapsamında tescil sahiplerinin (registrant / “Tescil Sahibi”) hak ve yükümlülüklerinin sade dilde Türkçe özetini sunar. Metin, GNSO Konseyi ile At-Large Danışma Komitesi’nin ortak çalışma grubunun katkıları ve tescil eden kuruluşlarla yapılan istişareler sonucu hazırlanan ICANN belgesine dayanır.

Bir alan adı tescil ettirebilmek için Tescil Sahibi’nin, ICANN tarafından akredite edilmiş bir Tescil Eden Kuruluş’un (Registrar) hizmetlerini kullanması gerekir. Bir kuruluşun ICANN akreditasyonu alabilmesi için ICANN ile RAA adı verilen bir sözleşme imzalaması zorunludur. RAA ve buna bağlı ICANN politikaları, Tescil Sahibi için çeşitli hak ve yükümlülükler belirler.

Buradaki özetler bilgilendirme amaçlıdır; RAA’nın, ilgili spesifikasyonların veya politikaların asıl metinlerinin yerine geçmez ve onları değiştirmez. Bağlayıcı olan, ilgili sözleşme ve politikaların orijinal metinleridir.

2. İlgili RAA Hükümleri

RAA, ICANN ile Tescil Eden Kuruluş arasında yapılan bir sözleşme olduğundan; Tescil Sahibi dahil hiç kimse, RAA’nın ihlal edildiği iddiasıyla ICANN’i veya Tescil Eden Kuruluş’u dava edemez.

Tescil Eden Kuruluşlar, herhangi bir TLD’ye diğer kuruluşlardan daha ayrıcalıklı/üstün erişim sağlayabileceklerine dair iddialarda bulunamaz.

Tescil Eden Kuruluş’un bazı yükümlülükleri, Tescil Sahibi’nin sorumluluklarını yerine getirmesine bağlıdır; özellikle tescil ücretlerinin ödenmesi, gerekli verilerin sunulması ve bu verilerin doğru ve zamanında güncellenmesi. Tescil Eden Kuruluş da Tescil Sahibi’ne; tescil süresinin bitişi, kişisel verilerin kullanımı, gizlilik/vekil hizmetiyle tescil edilen adların verilerinin emaneti ve adların geri kazanımına ilişkin ücretler gibi konularda bildirim yapmakla yükümlüdür.

3. Kayıt Operatörüne Veri Sunumu

Tescil Eden Kuruluş, her TLD içindeki her kayıtlı ad için Kayıt Operatörü’ne (Registry) belirli veri noktalarını iletmek zorundadır:

• Tescil edilen adın kendisi (m.3.2.1.1),
• Birincil ve ikincil ad sunucularının IP adresleri (m.3.2.1.2),
• Bu ad sunucularının karşılık gelen adları (m.3.2.1.3),
• Kayıt sistemi otomatik üretmiyorsa Tescil Eden Kuruluş’un kimliği (m.3.2.1.4),
• Kayıt sistemi otomatik üretmiyorsa tescilin bitiş tarihi (m.3.2.1.5),
• Kayıt Operatörü’nün talep ettiği diğer veriler (m.3.2.1.6).

Ad sunucularına ilişkin bilgileri (m.3.2.1.2–3) genellikle Tescil Sahibi sağlar. Tescil Sahibi bu verilerde güncelleme yaparsa, Tescil Eden Kuruluş güncellemeyi Kayıt Operatörü’ne beş (5) gün içinde iletmek zorundadır.

4. WHOIS Verileri

Tescil Eden Kuruluşlar, kamuya açık ve ücretsiz sorgulanabilen etkileşimli bir web sayfası ile port 43 WHOIS hizmeti sunmakla yükümlüdür. RAA, sorguya yanıt olarak verilmesi gereken veri noktalarını belirler:

• Tescilli ad (m.3.3.1.1),
• Birincil ve ikincil ad sunucularının adları (m.3.3.1.2),
• Tescil Eden Kuruluş’un kimliği (m.3.3.1.3),
• Tescilin ilk oluşturulma tarihi (m.3.3.1.4),
• Tescilin bitiş tarihi (m.3.3.1.5),
• Tescil Sahibi’nin adı ve posta adresi (m.3.3.1.6),
• Teknik irtibat kişisinin adı, posta/e-posta adresi, telefon ve (varsa) faks numarası (m.3.3.1.7),
• İdari irtibat kişisinin adı, posta/e-posta adresi, telefon ve (varsa) faks numarası (m.3.3.1.8).

Bu veriler “WHOIS verileri” olarak anılır. Tescil Sahibi WHOIS verilerini zamanında güncellemekle yükümlüdür; güncelleme alındığında Tescil Eden Kuruluş WHOIS kaydını “derhal” günceller. Tescil Eden Kuruluş, kamuya açık sorgu işlevinin bakımını dışarıya verebilir.

RAA, WHOIS verilerine üçüncü kişiler için toplu erişim sağlanmasına izin verebilir. Toplu erişimde veya kamuya açık sorgu işlevinde Tescil Eden Kuruluş; yüksek hacimli sorguları ve pazarlama, toplu tanıtım gibi kullanımları RAA’da belirtildiği şekilde kısıtlamak zorundadır. Sorgu işlevi dışarıya verilirse, aynı kısıtlamaların yükleniciye de uygulatılması gerekir.

5. İletişim ve Kayıt Tutma

Tescil Eden Kuruluşlar, Tescil Sahipleriyle yapılan tüm yazışmaların ve Kayıt Operatörlerine sunulan bilgilerin kayıtlarını tutmak zorundadır.

6. Verilerin Emaneti (Escrow), Gizlilik ve Vekil Hizmetleri

Tescil Eden Kuruluş; akreditasyonu üzerinden tescil edilen tüm adların WHOIS verileri ile Kayıt Operatörü’ne sunduğu tüm verileri içeren bir veri tabanı tutmak zorundadır. Bu veri tabanına ayrıca her ad için fatura irtibat kişisinin adı ve (varsa) posta/e-posta adresi, telefon ve faks numarası da dahil edilir.

Tescil Sahibi, WHOIS sorgusunda görünen kişisel bilgilerini sınırlamak isteyebilir. Bunun için ad, bir gizlilik (privacy) hizmeti üzerinden tescil edilebilir (kişisel bilgiler gizlenir, çoğu zaman hizmetin bilgileriyle değiştirilir) veya bir vekil (proxy) hizmeti kullanılabilir (bu durumda Tescil Sahibi vekil hizmettir ve kullanım hakkını müşteriye lisanslar).

Bir ad gizlilik/vekil hizmetiyle tescil edildiğinde Tescil Eden Kuruluş iki şeyden birini yapmalıdır: (1) gizlilik/vekil kullanılsa dahi müşterinin sağladığı ad, posta/e-posta adresi ve telefon bilgisini veri tabanına dahil etmek; ya da (2) müşteri gizlilik/vekil hizmetini seçtiğinde, verilerinin emanete alınmadığına dair bir bildirim göstermek. Müşteri verileri emanete alınmadığında yalnızca gizlilik/vekil hizmetinin iletişim bilgileri emanete alınır; bu durumda Tescil Eden Kuruluş veya Kayıt Operatörü’nün iflası/başarısızlığı halinde ileriki bildirimler yalnızca veri tabanındaki iletişim bilgisine gönderilebilir.

7. Tescil Eden Kuruluşun Tescil Sahibiyle İş İlişkileri

RAA, Tescil Eden Kuruluş’un iş ilişkilerine birçok yükümlülük getirir.

Tescil Eden Kuruluş, tescil ücretinin ödeneceğine dair Tescil Sahibi’nden makul güvence almadan adı etkinleştiremez.

Tescil Sahibi yenilemeye onay vermezse, Tescil Eden Kuruluş tescili mevcut sürenin sonunda iptal edebilir. Tescil Sahibi yenilemeye onay vermediyse, ad Kayıt Operatörü veri tabanından tescil süresinin bitiminden itibaren 45 gün içinde silinmelidir.

Bu iptal/silme hakkı mutlak değildir. RAA m.3.7.5.1, “istisnai durumlar” listesi belirler; bunlar varsa Tescil Eden Kuruluş, Tescil Sahibi’nin onayı olmadan da adı yenileyebilir (örn. ad bir UDRP işlemine, mahkeme kararına, iflas sürecine veya fatura uyuşmazlığına konu olduğunda). Bu durumda yenileme gerekçesinin kaydı tutulmalıdır.

Tescil Eden Kuruluş, her yeni Tescil Sahibi’ne silme ve otomatik yenileme politikalarını bildirmek; bu politikalar değişirse Tescil Sahiplerini bilgilendirmeye çalışmak zorundadır. Bu politikalar ile, “Kurtarma Ek Süresi” (Redemption Grace Period — adın Kayıt Operatörü nezdinde “Pending Delete / Silinmeyi Bekliyor” statüsünde olduğu 30 günlük dönem) içinde adın geri kazanımı için alınacak ücretler, tescil/yenileme yapılan web sitelerinde gösterilmelidir.

Silme veya bitiş anında ad bir UDRP uyuşmazlığına konuysa, UDRP şikâyetçisinin adı yenileme (silinmişse geri yükletme) hakkı vardır. Şikâyetçi adı yeniler/geri yüklerse, Tescil Eden Kuruluş adı HOLD veya LOCK statüsüne almalı ve WHOIS bilgisini adın uyuşmazlığa konu olduğunu gösterecek şekilde güncellemelidir. RAA m.3.7.5.7, UDRP şikâyeti karara bağlanmadan sona ererse veya asıl tescil sahibi lehine sonuçlanırsa, asıl Tescil Sahibi’ne adı geri kazanma/yenileme hakkı tanır.

8. Tescil Eden Kuruluş / Tescil Sahibi Sözleşmesi

Tescil Eden Kuruluşlar, tüm Tescil Sahipleriyle elektronik veya yazılı tescil sözleşmesi yapmak zorundadır. RAA’ya göre (m.3.7.7.1–12) bu sözleşme en azından şunları içermelidir:

• Tescil Sahibi “doğru ve güvenilir iletişim bilgileri” vermeli ve bunları tescil süresince “derhal düzeltip güncellemelidir”. Gerekli bilgiler: tam ad, posta/e-posta adresi, telefon, varsa faks; kurum/dernek/şirket ise irtibat için yetkili kişinin adı ve m.3.3.1.2, 3.3.1.7, 3.3.1.8’deki veriler (m.3.7.7.1).
• Tescil Sahibi bilerek yanlış/güvenilmez bilgi verir, bilgiyi derhal güncellemekte bilerek başarısız olur ya da Tescil Eden Kuruluş’un doğruluk sorgusuna on beş (15) günden fazla yanıt vermezse, sözleşmeyi esaslı şekilde ihlal etmiş sayılır ve tescil iptal edilebilir.
• Tescil Sahibi olarak kayıtlı kişi, tam iletişim bilgilerini sağlamakla yükümlü ve resmî kayıt sahibidir. Bir kişi adı tescil edip başkasının kullanımına bırakırsa (örn. bir web tasarımcısının müşterisi adına tescil etmesi) ve bu “üçüncü kişi” sözleşmeye taraf değilse; üçüncü kişinin hatalı kullanımından doğan zararlardan, kendisine “dava edilebilir zarara dair makul delil” sunulduğu hâlde, kullanıcının kimlik ve güncel iletişim bilgilerini açıklamadıkça Tescil Sahibi sorumlu olur.
• Tescil Eden Kuruluş; Tescil Sahibi’nin verilerini nasıl kullanacağını, kimlerle paylaşacağını, verilere nasıl erişilip güncellenebileceğini bildirmek ve hangi verilerin zorunlu hangilerinin gönüllü olduğunu belirtmek zorundadır. Tescil Sahibi bu veri işleme şartlarına onay vermelidir.
• Tescil Sahibi, sözleşmeye taraf olmayan bir “üçüncü kişiye” ait kişisel veriyi Tescil Eden Kuruluş’a sağlıyorsa; bu kişilere aynı bildirimleri yaptığını ve aynı onayları aldığını teyit etmelidir.
• Tescil Eden Kuruluş verileri yalnızca bildirilen amaçlarla işleyebilir ve verileri “kayıp, kötüye kullanım, yetkisiz erişim/ifşa, değiştirme veya yok etmeye” karşı korumak için makul önlemler almayı kabul eder.
• Tescil Sahibi, bilgisi dahilinde adın tescilinin veya kullanımının üçüncü kişilerin yasal haklarını (örn. marka veya telif hakkı) ihlal etmediğini taahhüt eder.
• Adın kullanımıyla ilgili bir uyuşmazlıkta Tescil Sahibi; Tescil Eden Kuruluş’un bulunduğu yer veya kendi “ikametgâhı” mahkemelerinden en az birinin yargı yetkisini kabul eder.
• Tescil Sahibi, tescilin m.3.7.7.11’de belirtilen sebeplerle “askıya alınabileceğini, iptal edilebileceğini veya devredilebileceğini” kabul eder (örn. bir ICANN politikası/spesifikasyonu gerektirdiğinde ya da kayıt hatalarının düzeltilmesi/uyuşmazlıkların çözümü için). Örneğin UDRP kapsamında bir idari panel, adın askıya alınmasına, devrine veya iptaline karar verebilir.
• Tescil Sahibi; Kayıt Operatörü’nü ve yöneticilerini/çalışanlarını/temsilcilerini, tescilden kaynaklanan her türlü talep, zarar, yükümlülük ve masrafa (makul avukatlık ücretleri dahil) karşı “tazmin etmeyi ve zarar görmemelerini sağlamayı” kabul eder.

9. İletişim Bilgilerinin Doğrulanması

İlgili spesifikasyon/politikalar, Tescil Eden Kuruluş’a ilk tescilde iletişim bilgilerini doğrulama ve belirli aralıklarla yeniden doğrulama yükümlülüğü getirebilir.

Tescil Eden Kuruluş, bir adın iletişim bilgisinin yanlış olduğu kendisine bildirildiğinde bilgileri doğrulamak için “makul adımlar” atmak; fark ettiği yanlışlıkları (kimse bildirmese dahi) düzeltmek için harekete geçmek zorundadır. Ayrıca kendisine ait geçerli bir e-posta ve posta adresi bulundurmalı ve bunu web sitesinde yayımlamalıdır.

10. Bayi (Reseller) Düzenlemeleri

RAA, Tescil Eden Kuruluş’un üçüncü taraf Bayilerle (Reseller) çalışmasına yükümlülükler getirir. Tescil Eden Kuruluş, Bayi sözleşmelerine şunları dahil etmek zorundadır: Bayinin ICANN tarafından akredite olduğu iddiasında bulunmasının yasaklanması; Bayi tescil sözleşmelerinin, Tescil Eden Kuruluş’un kendi sözleşmesinde bulundurmak zorunda olduğu tüm hükümleri içermesi; zorunlu ICANN bağlantılarının yayımlanması; ve sorumlu tescil eden kuruluşun belirtilmesi.

Bir müşteri Bayinin gizlilik/vekil hizmetini kullanıyorsa Bayi şu üç şeyden birini yapmalıdır: (1) müşterinin kimlik ve iletişim bilgisini Tescil Eden Kuruluş’a iletmek; (2) bu bilgiyi emanete (escrow) bırakmak; veya (3) müşteriye bilgilerinin emanete alınmadığına dair bildirim göstermek. Tescil Eden Kuruluş ayrıca, zorunlu hükümleri ihlal eden Bayiye karşı uyum ve yaptırım işlemi yapmakla yükümlüdür.

11. Diğer Politikalar ve Spesifikasyonlar

Geri Yüklenen Adların Doğruluğu Politikası: Bir Tescil Eden Kuruluş, yanlış iletişim verisi sunulması veya sorgulara yanıt verilmemesi nedeniyle silinmiş bir adı (kurtarma ek süresinden) geri yüklediğinde, Tescil Sahibi güncel ve doğru WHOIS bilgisini sağlayana kadar ad “Registrar Hold” statüsünde tutulmalıdır.

UDRP (Tek Tip Alan Adı Uyuşmazlık Çözüm Politikası): RAA’daki taahhüde ek olarak UDRP; adın hukuka aykırı bir amaçla tescil edilmediği ve yürürlükteki yasalara aykırı kullanılmayacağı taahhüdünü de gerektirir. UDRP ayrıca Tescil Sahibi’ni, ICANN onaylı bir uyuşmazlık çözüm sağlayıcısı önünde yürütülen zorunlu idari sürece tabi kılar. Bu zorunlu idari süreç, aynı/benzer eylem için ayrıca yargı yoluna gidilmesini engellemez.

Tescil Eden Kuruluşlar Arası Transfer Politikası: Tescil Sahibi, alan adı tescilini tescil eden kuruluşlar arasında transfer etme hakkına sahiptir ve politika, transfer talebine yanıt süreleri belirler. Transfer hakkı mutlak değildir; oluşturulma/önceki transfer tarihinden itibaren süre sınırları ve gerekli yetkilendirme/belgelerin sunulması gibi koşullar olabilir. Mevcut Tescil Eden Kuruluş transferi yalnızca şu hallerde reddedebilir:

• Dolandırıcılık (fraud) delili,
• UDRP işlemi,
• Yetkili bir mahkemenin kararı,
• Tescil Sahibi veya idari irtibat kişisinin kimliği konusunda makul uyuşmazlık,
• Önceki dönem ücretinin ödenmemesi (kredi kartı ters ibrazları dahil) — bu hallerde ad, ret öncesinde “Registrar Hold” statüsüne alınmalıdır,
• Transfer İrtibat Kişisi’nin transfere açık yazılı itirazı (e-posta, faks, belge vb. gönüllü opt-in yöntemleriyle),
• Adın zaten “kilit (lock)” statüsünde olması (kilit kaldırma için makul ve erişilebilir yöntem sunulması koşuluyla),
• Transferin, kayıttaki oluşturulma tarihinden itibaren 60 gün içinde talep edilmesi,
• Adın transfer edilmesinin üzerinden 60 günden (veya belirlenecek daha kısa süreden) az zaman geçmiş olması.

12. Notlar

1. Tipik bir gTLD adının yaşam döngüsü ve bitiş sonrası statüleri hakkında ek bilgi ICANN’in ilgili kaynaklarında bulunabilir.
2. Alan adı statülerinin teknik adları, topluluk temelli RFC taslaklarından gelir. Ad bu statülerden birindeyken silinemez ve değiştirilemez; değişiklik için Tescil Eden Kuruluş statüyü değiştirmelidir.
3. Başkalarının “yasal haklarını ihlal etmenin” birçok yolu vardır; tescil veya kullanımın başkasının haklarını ihlal edebileceğinden endişe eden adaylar bağımsız hukuki danışmanlık almaya teşvik edilir.
4. Bir adın kullanımına ilişkin uyuşmazlığı karara bağlayabilecek başka yargı yerleri de olabilir; ancak bunlar RAA’da belirtilmemiştir.

Son güncelleme: Haziran 2026