ICANN Alan Adı Politikalarındaki Değişiklikler: Domain Sahipleri İçin Yol Haritası

ICANN alan adı politikalarındaki değişiklikler neden önemli?

Alan adları artık sadece bir web adresi değil; markanın kimliği, SEO stratejisinin omurgası ve tüm dijital altyapının giriş kapısı. Bu kapının kurallarını belirleyen kurum ise küresel düzeyde ICANN. Son yıllarda gizlilik, güvenlik, DNS kötüye kullanımı ve veri koruma başlıkları etrafında ICANN alan adı politikalarında ciddi değişiklikler yapılıyor. Bu değişiklikler; domain kayıt süreçlerinden transfer akışına, WHOIS verilerinin görünürlüğünden DNSSEC ve güvenlik gereksinimlerine kadar pek çok noktayı etkiliyor.

Biz DCHost olarak, günlük operasyonlarımızda bu politikaların pratik etkilerini çok net görüyoruz: Müşterilerin alan adları onay e-postalarına yanıt verilmediği için askıya alınabiliyor, Whois/RDAP veri formatları değiştikçe entegrasyonlar güncellenmek zorunda kalıyor, transfer akışları yeni güvenlik adımlarıyla yeniden tasarlanıyor. Bu yazıda, ICANN alan adı politikalarındaki başlıca değişiklikleri sade bir dille özetleyip, domain sahipleri, ajanslar ve teknik ekipler için somut bir yol haritası çıkarmaya odaklanacağız.

ICANN nasıl çalışır? Politika değişiklikleri nereden geliyor?

Önce resmin bütününü görmekte fayda var. ICANN, küresel alan adı sisteminin (DNS) koordinasyonundan sorumlu, çok paydaşlı yapıda çalışan bir organizasyon. Özellikle genel üst seviye alan adları (gTLD) – örneğin .com, .net, .org ve yeni nesil yüzlerce uzantı – için çerçeve kuralları ICANN belirliyor.

ICANN dünyasında politika değişiklikleri kabaca üç kanaldan geliyor:

• Kayıt sözleşmeleri: Kayıt operatörleri (registry) ile ICANN arasındaki Registry Agreement (RA)
• Registrar sözleşmesi: Domain satan firmalarla yapılan Registrar Accreditation Agreement (RAA)
• Konsensüs politikaları: GNSO gibi yapıların uzun süren çalışma gruplarıyla ürettiği, tüm akredite registrar ve kayıt operatörlerini bağlayan kurallar

Bu nedenle, ICANN alan adı politikalarındaki her değişiklik, bir anda değil; genellikle yıllar süren tartışma, taslak, kamuoyu görüşü ve oylama süreçlerinin sonunda hayatımıza giriyor. Ancak uygulama aşamasında bu değişiklikler, domain panelinizde gördüğünüz alan adının:

• Nasıl kaydedildiğini,
• Hangi iletişim bilgilerinin tutulduğunu,
• Nasıl transfer edilebildiğini,
• Ne zaman askıya alınabileceğini,
• DNSSEC, RDAP gibi teknik özelliklerinin nasıl desteklendiğini

doğrudan etkiliyor.

Son dönemde öne çıkan ICANN politika başlıkları

Alan adı tarafında son yıllarda özellikle şu başlıklar öne çıkıyor:

• WHOIS'ten RDAP'e geçiş ve veri koruma uyumu
• Alan adı transfer politikalarının güncellenmesi
• DNS kötüye kullanımına (DNS abuse) karşı daha sıkı kurallar
• DNSSEC ve güvenlik odaklı teknik gereksinimler
• Yeni gTLD programı ve uzantı ekosisteminin genişlemesi

Şimdi her birini, domain ve hosting pratiği açısından ne anlama geldiğiyle birlikte ele alalım.

WHOIS → RDAP dönüşümü ve kayıt verisi politikası

Eskiden bir alan adının sahiplik bilgilerini görmek için WHOIS sorgusu yapardık. Ancak GDPR ve benzeri gizlilik düzenlemeleriyle birlikte, yıllardır kullanılan klasik WHOIS modeli hem veri formatı hem de gizlilik açısından sürdürülemez hale geldi. Bunun üzerine ICANN tarafında Registration Data Access Protocol (RDAP) merkezli yeni bir yaklaşım benimsendi.

Öne çıkan noktalar:

• Standart JSON tabanlı çıktı: RDAP, makine tarafından okunabilir, standart bir veri yapısı sunuyor.
• Gizlilik filtreleri: Son kullanıcıya gösterilen veri ile yetkili otoritelere gösterilen veri farklılaşabiliyor.
• Politika olarak çatı düzenleme: ICANN, dağınık WHOIS politikalarını tek bir kayıt verisi politikası altında yeniden topluyor.

Domain sahibi açısından ne değişiyor? En net etkisi, alan adınız için hangi iletişim bilgilerinin, kime, ne kadar süreyle ve hangi formatta gösterileceği. WHOIS gizliliği (privacy/proxy) çözümlerinin işleyişi ve kapsamı da bu değişikliklerle yeniden tanımlanıyor. Biz DCHost tarafında, RDAP uyumluluğunu ve saklanan verilerin minimum ilke ile yönetilmesini iç süreçlerimizin bir parçası haline getiriyoruz.

Alan adı transfer politikasındaki değişiklikler

ICANN'in alan adı transfer politikası (Transfer Policy) özellikle son yıllarda kapsamlı bir revizyondan geçiyor. Amaç, hem güvenliği artırmak hem de gereksiz karmaşıklığı azaltmak. Domain sahiplerinin gündelik hayatında en çok hissedeceği değişiklikler genellikle burada oluyor.

Klasik modelde:

• Alan adı transferi için EPP/Auth code alırdınız,
• Giden ve gelen registrar tarafında FOA (Form of Authorization) e-postaları gönderilirdi,
• Transfer kilidi, whois e-posta doğrulaması ve benzeri adımlar devreye girerdi.

Yeni politika setiyle birlikte:

• TAC (Transfer Authorization Code) kavramı daha net tanımlanıyor, kodun nasıl üretileceği ve ne kadar süre geçerli olacağı standartlaşıyor.
• FOA süreci sadeleşiyor, tekrar eden onay adımlarının bir kısmı kaldırılıyor ya da birleştiriliyor.
• Güvenlik odaklı kilit ve bekleme süreleri daha açık hale geliyor (örneğin, yeni kayıt veya whois bilgisinde kritik değişiklik sonrası kısa süreli transfer kısıtları).

Bu noktada, alan adı taşımayı planlarken güncel politika çerçevesine uygun bir rotayı takip etmek çok önemli. Bu konuyu daha operasyonel gözle görmek isterseniz, alan adı transferinin adım adım nasıl yapıldığını anlattığımız rehbere mutlaka göz atın.

DNS kötüye kullanımı (DNS abuse) ile mücadele

ICANN tarafında son dönemin en sıcak başlıklarından biri de DNS abuse: phishing, malware, botnet komuta kontrol alan adları, spam için açılan tek kullanımlık domainler vb. Bu alanda büyük e-posta sağlayıcıları, tarayıcı üreticileri ve güvenlik topluluğu yoğun baskı uyguladıkça, ICANN de registrar ve registry sözleşmelerine daha net yükümlülükler ekliyor.

Domain sahipleri için pratik etkileri:

• Alan adınız kötüye kullanım şüphesiyle raporlanırsa, registrarınız (örneğin DCHost) hızlı aksiyon almak zorunda kalabiliyor.
• İlgili politikalara göre, ağır ihlallerde kayıt durdurulabilir, DNS çözümlemesi askıya alınabilir.
• Kayıt sırasında sağlanan iletişim bilgileri ve loglar, belirli sürelerle saklanmak zorunda olduğu için, yanlış beyan vermek ciddi risk oluşturuyor.

Burada en güçlü savunma, altyapı ve uygulama seviyesinde iyi güvenlik hijyeni: güncel yazılım, sağlam parolalar, iki faktörlü kimlik doğrulama, WAF ve DDoS korumaları, temiz e-posta pratikleri. DCHost olarak sunucu ve hosting tarafında yükselen siber tehditlere karşı alınması gereken önlemleri detaylıca anlattığımız rehberleri bu yüzden özellikle tavsiye ediyoruz.

DNSSEC ve teknik güvenlik gereksinimleri

DNS güvenliği konusu da ICANN gündeminde giderek daha merkezi bir yer tutuyor. Birçok gTLD, DNSSEC desteğini zorunlu ya da fiili standart haline getiriyor. ICANN sözleşmelerinde DNSSEC, DANE gibi mekanizmalar için teknik gereksinimler giderek detaylanıyor.

DNSSEC, kısaca, alan adınızın DNS kayıtlarının kriptografik olarak imzalanması. Böylece kullanıcılarınız yanlış DNS cevabına yönlendirilme riskine karşı daha iyi korunuyor. Bu aynı zamanda, MTA seviyesinde DANE/TLSA gibi güvenlik başlıklarıyla da birleşebiliyor.

DNSSEC kullanımı ve anahtar döngüsü (key rollover) pratikte iyi planlanmadığında, site tamamen açılmaz hale gelebilir. Bu konuda sıfır kesintiyle anahtar yenilemenin nasıl yapılacağını merak ediyorsanız, DNSSEC key rollover rehberimize göz atmanızı öneririz. Biz DCHost tarafında, DNSSEC desteğini ve doğru yapılandırmayı domain yönetim sürecinin doğal bir parçası olarak ele alıyoruz.

Yeni gTLD programı ve uzantı ekosisteminin genişlemesi

ICANN'in yeni gTLD programı, alan adı uzantıları dünyasını kökten değiştirdi. Artık klasik .com, .net, .org üçlüsünün çok ötesinde, sektöre, markaya, şehre veya dikeye özel yüzlerce uzantı var. Ayrıca ICANN'in yeni bir gTLD başvuru turu daha planlaması, marka ve büyük platformlar için kendi uzantılarını alma fikrini yeniden masaya getiriyor.

Bu konunun stratejik boyutunu ayrıntılı konuştuğumuz ICANN yeni gTLD turu yazımız, özellikle büyük proje sahipleri ve ajanslar için iyi bir başlangıç noktası. Küçük ve orta ölçekli işletmeler tarafında ise asıl soru, bu kadar çok uzantı arasında hangi TLD'nin seçileceği. Burada da SEO ve marka için TLD seçimi rehberimizde pratik örneklerle anlattığımız gibi, hem ICANN ekosistemini hem de hedef kitle davranışlarını birlikte düşünmek gerekiyor.

Domain sahipleri için pratik etkiler: Neler değişiyor?

Politika metinleri çoğu zaman son derece teknik ve hukuki dille yazıldığı için, asıl soruya gelelim: Bu değişiklikler sizin günlük işlerinizi nasıl etkiliyor?

1. Kayıt olurken verdiğiniz bilgiler daha kritik hale geliyor

ICANN alan adı politikaları çerçevesinde, registrarlar alan adı kaydı sırasında belirli minimum bilgileri almak ve doğrulamak zorunda. E-posta ve telefon doğrulaması, şüpheli kayıtların işaretlenmesi, yanlış veya geçersiz bilgilerde alan adının askıya alınması gibi mekanizmalar devreye girebiliyor.

Özellikle şu noktalara dikkat etmek gerekiyor:

• Kayıt sırasında verdiğiniz e-posta adresini gerçekten aktif takip ediyor musunuz?
• Telefon numaranız doğrulanabilir ve güncel mi?
• Şirket unvanı, vergi veya ticaret sicil bilgileri doğru mu?

ICANN politikalarındaki sıkılaşma nedeniyle, yanlış bilgi verdiğiniz veya doğrulama e-postalarını yanıtlamadığınız bir domainin, günün birinde aniden pasife alınması işten bile değil. DCHost paneli üzerinden alan adı iletişim bilgilerinizi düzenli aralıklarla gözden geçirmenizi bu yüzden özellikle tavsiye ediyoruz.

2. WHOIS/RDAP görünürlüğü ve gizlilik dengesi değişiyor

Eskiden WHOIS çıktısında tam adınız, adresiniz, e-posta ve telefon numaranız herkes tarafından görülebiliyordu. Bugün, RDAP ve yeni kayıt verisi politikalarıyla birlikte, bu verilerin önemli bir kısmı ya maskeleme (redaction) ile gizleniyor ya da sadece yetkili taraflara gösteriliyor.

Bu şu sonuçları doğuruyor:

• Spam ve kötü niyetli aramalarda azalma mümkün.
• Ancak meşru iletişim (örneğin marka itirazları, teknik sorun bildirimleri) için doğru kanalların tanımlanması gerekiyor.
• WHOIS gizlilik hizmetleri (privacy/proxy) ile ICANN politikaları arasındaki uyum, sözleşme düzeyinde yeniden tanımlanıyor.

Bu dengeyi daha güvenli kurmak için, alan adı güvenliği rehberimizde anlattığımız Registrar Lock, DNSSEC, Whois gizliliği ve 2FA kombinasyonunu uygulamak çok işe yarıyor. DCHost müşteri panelinde bu ayarları tek yerden yönetebilmeniz için sürekli iyileştirmeler yapıyoruz.

3. Transfer süreçleri daha öngörülebilir ama daha disiplinli

Yeni transfer politikalarıyla amaç, kötü niyetli veya yetkisiz transferleri zorlaştırırken, meşru transferleri mümkün olduğunca pürüzsüz hale getirmek. Bu da bazı açılardan sıkılaşma, bazı açılardan sadeleşme anlamına geliyor.

Dikkat edilmesi gerekenler:

• Transfer kilidi (Registrar Lock) durumunuzu bilin; kilitli domain transfer edilemez.
• Whois/RDAP iletişim bilgileriniz güncel değilse, doğrulama adımlarında takılabilirsiniz.
• Yeni kayıt veya önemli whois değişikliklerinden sonra kısa süreli transfer kısıtları uygulanabilir.

Bu kurallar yüzünden, alan adınızı son dakikaya bırakarak taşımaya kalktığınızda, sürenin politik kilitlere takılarak uzaması söz konusu olabilir. Bu yüzden, özellikle markasal değeri yüksek alan adları için transferleri önceden planlamanızı ve TTL, DNS, e-posta tarafını da işin içine alan bir yol haritası çizmenizi öneriyoruz.

4. Alan adı yaşam döngüsü artık daha kritik

ICANN politikalarındaki değişiklikler, alan adı yaşam döngüsünün (aktif dönem, grace period, redemption, pending delete vb.) sınırlarını da daha net hale getirdi. Bu süreler, registry sözleşmelerinde ve konsensüs politikalarında açıkça tanımlanıyor.

Özellikle yenilemeyi unuttuğunuz alan adlarında:

• Hangi tarihte siteniz kapanır,
• Hangi tarihe kadar ekstra ücretle geri alabilirsiniz,
• Ne zaman tamamen silinir ve düşen domain statüsüne geçer,

gibi soruların net cevapları var. Bu süreci şemalar ve örneklerle anlattığımız alan adı yaşam döngüsü rehberimizi okursanız, ICANN tarafındaki kuralların sahadaki davranışı nasıl şekillendirdiğini daha iyi görebilirsiniz.

Hosting ve DNS altyapısı açısından ICANN politikalarının etkisi

ICANN alan adı politikaları kağıt üzerinde soyut görünse de, hosting ve DNS altyapısında çok somut sonuçları var. DCHost tarafında bu sonuçları her gün yaşıyoruz.

DNSSEC, CAA, IPv6 ve modern DNS pratikleri

Politika metinlerinde doğrudan 'şu DNS sunucusunu kullanın' gibi bir ifade elbette yok; ancak DNS güvenliği ve erişilebilirlik konusunda güçlü bir yönlendirme var. Örneğin:

• DNSSEC desteği olmayan bir DNS altyapısı, birçok kurumsal güvenlik standardıyla uyumsuz hale geliyor.
• CAA (Certification Authority Authorization) kayıtları, sertifika otoritelerinin yetkilerinin sınırlandırılması için fiili standart haline geliyor.
• IPv6 desteği, giderek daha fazla ülkede ve operatörde gerekli hale gelirken, ICANN ekosistemi de bu geçişi teknik dokümanlarında ve forumlarında sürekli gündemde tutuyor.

Biz DCHost'ta, DNS altyapımızı DNSSEC, CAA, IPv6 gibi özelliklerle güncel tutarken, müşterilerimize de bu modern pratikleri etkinleştirmeleri için kontrol paneli seviyesinde kolaylaştırılmış arayüzler sunuyoruz.

SSL/TLS ve alan adı güvenliği ilişkisinin güçlenmesi

ICANN doğrudan SSL sertifikalarını yönetmiyor, ancak alan adları ile TLS ekosistemi arasındaki ilişki her geçen gün sıkılaşıyor. Örneğin:

• CAA kayıtları, hangi sertifika otoritelerinin alan adınız için sertifika üreteceğini belirliyor.
• DNS tabanlı ACME challenge (DNS-01) mekanizmaları, wildcard SSL gibi senaryolarda alan adınızın DNS yönetimiyle doğrudan ilişkili.
• DNSSEC, DANE/TLSA gibi kayıtlarla birleştiğinde, e-posta ve web trafiğinde çok daha güçlü bir güvenlik seviyesi mümkün.

DCHost olarak, hem SSL sertifikalarının ne olduğunu ve nasıl yönetileceğini anlattığımız temel rehberlerde hem de TLS 1.3, HSTS, OCSP stapling gibi ileri seviye konularda yayınladığımız teknik makalelerde, alan adı katmanının bu işin tam merkezinde olduğunu özellikle vurguluyoruz.

Küçük işletmeler, ajanslar ve geliştiriciler için aksiyon listesi

ICANN alan adı politikalarındaki değişiklikler; bir hukuk metni olarak bırakıldığında işe yaramaz. Önemli olan, bunu kendi gerçekliğinize adapte etmek. Biz DCHost tarafında müşterilerimize genellikle şu pratik aksiyon listesini öneriyoruz:

1. Domain envanterinizi çıkarın ve kritik olanları işaretleyin

Özellikle ajans, yazılım evi veya çoklu proje yürüten ekipler için ilk adım, hangi alan adlarının gerçekten kritik olduğunu belirlemek. Kurumsal e-posta, fatura sistemi, müşteri paneli, CDN origin gibi kritik servisler hangi domainlere bağlı, netleştirin.

Bu kritik domainler için:

• Otomatik yenileme açık mı?
• Yenileme e-postaları doğru kişiye gidiyor mu?
• Registrar Lock, 2FA, DNSSEC aktif mi?

gibi sorulara net cevap verebilmelisiniz.

2. İletişim bilgilerinizi ve güvenlik ayarlarınızı güncelleyin

ICANN politikalarının önemli bir kısmı, 'kim domain sahibi ve gerektiğinde ona ulaşabiliyor muyuz?' sorusunun etrafında dönüyor. Bu yüzden:

• Alan adı iletişim bilgilerinizi yılda en az bir kez gözden geçirin.
• Şirket e-postalarınızı kullanın; kişisel adreslere bağımlı kalmayın.
• DCHost hesabınızda mutlaka 2FA etkinleştirin.
• Registrar Lock özelliğini, yalnızca planlı transferler sırasında kapatın.

Bu adımlar, hem ICANN'in öngördüğü iyi pratiklerle uyumlu kalmanızı hem de hesabınızın ele geçirilmesi halinde oluşacak zararı minimize etmenizi sağlar.

3. DNS ve SSL yapılandırmalarınızı dokümante edin

Politikalar sıkılaştıkça, denetim ve izlenebilirlik beklentisi de artıyor. Bu yüzden kritik domainleriniz için basit ama güncel bir dokümantasyon hazırlayın:

• Hangi DNS kayıtları nerede tutuluyor (NS, A/AAAA, MX, TXT, CAA, SRV vb.)?
• Hangi SSL sertifikaları hangi alan adlarına bağlı, yenileme tarihleri neler?
• DNSSEC etkin mi, KSK/ZSK anahtar döngüsü nasıl planlanmış?

Bunun temel mantığını anlamak için DNS kayıtları A'dan Z'ye rehberimize göz atabilirsiniz. DCHost olarak, kontrol paneli tarafında bu kritik bilgileri sade ve okunabilir bir şekilde göstermeye özel önem veriyoruz.

4. Projelerinizi alan adı stratejisiyle birlikte planlayın

ICANN alan adı politikalarındaki değişiklikler, sadece teknik detay değil, aynı zamanda stratejik kararlarınızı da etkiliyor. Yeni gTLD'ler, IDN (uluslararasılaştırılmış alan adları), coğrafi uzantılar, marka uzantıları gibi seçenekler, büyük resimde alan adı stratejinizi şekillendiriyor.

Bu noktada, alan adı stratejisi kurma rehberimizde anlattığımız gibi, ccTLD (.tr gibi ülke uzantıları) ile gTLD'lerin (ICANN ekosistemindeki uzantılar) rolünü ayrı ayrı düşünmek, ICANN politikalarıyla yerel regülasyonları birlikte değerlendirmek önemli.

Yaklaşan olası ICANN politika değişikliklerine nasıl hazırlanmalı?

ICANN süreci hiçbir zaman 'tamam, bitti' noktasına gelmiyor. WHOIS/RDAP, transfer politikası, DNS abuse, yeni gTLD turları derken sırada;

• Uyuşmazlık çözüm mekanizmalarının (UDRP vb.) gözden geçirilmesi,
• Veri saklama ve loglama gereksinimlerinde güncellemeler,
• Ulusal ve bölgesel veri koruma düzenlemeleriyle daha sıkı entegrasyon,

gibi başlıklar var. Domain portföyü geniş olan şirketler ve ajanslar için, bu değişiklikler doğrudan operasyonel maliyet ve süreç tasarımı anlamına geliyor.

Biz DCHost olarak, hem ICANN forumlarını hem de ilgili çalışma gruplarını yakından takip edip, müşterilerimizi etkileyecek değişiklikleri önceden öngörmeye çalışıyoruz. Panel değişiklikleri, API güncellemeleri, ek güvenlik adımları gibi konuları, politika metinleri yürürlüğe girmeden önce hazırlayıp test etmeye özen gösteriyoruz.

Sonuç: ICANN politikaları değişirken sakin ve hazırlıklı kalmak

ICANN alan adı politikaları, ilk bakışta uzaktaki bir kurumsal tartışma gibi görünebilir. Ama pratiğe indiğimizde, bu tartışmaların sonucu; sitenizin açık kalıp kalmamasını, e-postalarınızın teslim edilip edilmemesini, markanızın sahte kopyalara karşı ne kadar korunabildiğini doğrudan belirliyor.

Bu yüzden mesajımız basit: Politika metinlerini ezberlemeniz gerekmiyor, ancak etkilediği alanları bilip, kendi işinize çevirecek birkaç temel pratik benimsemeniz şart:

• Alan adı iletişim ve güvenlik ayarlarınızı düzenli gözden geçirin.
• DNS, SSL ve yenileme süreçlerinizi dokümante edin.
• Kritik domainleriniz için transfer ve yenileme planı yapın.
• ICANN ekosistemindeki büyük başlıkları (RDAP, transfer politikası, DNS abuse, yeni gTLD'ler) kabaca takip edin.

Biz DCHost olarak, hem alan adı hizmetlerimizde hem de hosting, VPS, dedicated ve colocation altyapılarımızda bu değişiklikleri sizin yerinize takip edip, panel ve destek süreçlerimize yediriyoruz. Siz projelerinize ve işinize odaklanırken, ICANN tarafındaki karmaşayı sadeleştirilmiş, uygulanabilir adımlara dönüştürmek bizim işimiz. Alan adı portföyünüzü gözden geçirmek veya yeni bir projeyi doğru alan adı ve altyapı stratejisiyle başlatmak istiyorsanız, ekibimizle her zaman konuşabilirsiniz.