ICANN Alan Adı Politikaları: Yürürlük ve Uygulama

ICANN politikaları alan adı yönetimini nasıl etkiler?

Alan adınız; web sitenizin, kurumsal e-postanızın ve marka kimliğinizin ortak giriş noktasıdır. ICANN alan adı politikaları, özellikle genel üst seviye alan adlarında (gTLD) kayıt verilerinin işlenmesini, registrar değişikliğini ve kötüye kullanım süreçlerini etkiler. Her güvenlik tavsiyesi bir ICANN zorunluluğu olmadığı gibi, kabul edilen her politika da hemen yürürlüğe girmez.

Durum kontrolü: 4 Kasım 2026. İlk kez Kasım 2025’te yayımlanan bu rehber, yürürlükteki kuralları ve uygulama bekleyen değişiklikleri ayıracak şekilde güncellendi. Aşağıdaki takvim domain sahipleri, ajanslar ve teknik ekipler içindir; belirli bir uzantının kayıt koşulları ayrıca kontrol edilmelidir.

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

ICANN, küresel DNS ve benzersiz internet tanımlayıcılarının koordinasyonunda görev alan, çok paydaşlı bir organizasyondur. Buradaki sözleşme ve konsensüs politikaları .com, .net, .org gibi gTLD’ler için tanımlanan kapsamda geçerlidir. .tr gibi ülke kodu uzantılarının (ccTLD) yerel kayıt ve transfer kurallarını aynı kabul etmeyin. Alan adı satan sağlayıcı bir bayi de olabilir; doğrudan yükümlülükleri olan akredite registrar ile müşteriye hizmet sunan markayı ayırın.

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: ICANN tarafından akredite edilmiş kayıt kuruluşlarıyla yapılan Registrar Accreditation Agreement (RAA)
• Konsensüs politikaları: GNSO gibi yapıların uzun süren çalışma gruplarıyla ürettiği, kapsamlarına ve ilgili sözleşmelere göre akredite registrarları ve kayıt operatörlerini bağlayan kurallar

Politika geliştirme, tartışma, kamuoyu görüşü ve karar aşamalarını içerir. Uygulamaya alınan değişiklikler alan adı yönetiminde şu konuları etkileyebilir:

• Kayıt süreci ve gerekli iletişim bilgileri
• Registrar ve kayıt sahibi değişikliği
• Askıya alma ve kötüye kullanım işlemleri
• Registry ve registrarın RDAP veya DNSSEC desteği

Her yeni gereksinimin hangi tarafı bağladığını ve hangi tarihte uygulanacağını ilgili metinden kontrol edin.

Hangi değişiklik yürürlükte, hangisi bekliyor?

4 Kasım 2026 itibarıyla temel ayrım şöyledir. “Kabul edildi” bir politika kararını, “yürürlükte” ise ilgili tarafların uygulamakla yükümlü olduğu aşamayı ifade eder:

Her başlığın resmî kaynakları ve uygulanabilir kontrolleri aşağıdadır. DNSSEC, CAA ve TLS bölümündeki teknik öneriler ise bu takvimden ayrı değerlendirilir.

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

WHOIS uzun süre kayıt verilerini serbest metinle sundu. RDAP aynı alanda standart, makine tarafından işlenebilir sorgular sağlar. ICANN’in RDAP açıklamasına göre, 28 Ocak 2025’ten itibaren gTLD registry ve registrarlarının WHOIS sunma yükümlülüğü genel olarak kalktı; .com, .name ve .post istisnaları bulunur. Bu tarih bütün WHOIS sunucularının kapandığı anlamına gelmez. Kişisel verilerin gizlenmesi ise protokolün kendisinden ayrı politika ve hukuk kurallarına bağlıdır.

Öne çıkan noktalar:

• RDAP: Standart JSON yanıtları ve yetkili hizmeti bulma desteği, metin kazıyan WHOIS entegrasyonlarının yerine kullanılabilir.
• Kayıt verisi politikası: Registration Data Policy 21 Ağustos 2025’te yürürlüğe girdi; veri toplama, aktarım, yayımlama ve açıklama koşullarını düzenler.
• Kuruluş adı: Registrant Organization girildiğinde bunun kayıt sahibi kuruluş olarak kabul edileceği ve yayımlama tercihi açıklanmalıdır. Alanın doğru tüzel kişiyi gösterdiğini kontrol edin.
• İdari iletişim: Politika, idari ve faturalama kişisine ait kayıt verilerinin işlenmesi için önceki RA/RAA zorunluluklarını kaldırır. Bu, ödeme için gereken fatura bilgilerinin alınamayacağı anlamına gelmez.

Kamuya açık verinin gizlenmesi, privacy/proxy hizmetiyle aynı şey değildir. Kamuya kapalı veriler için gerekçeli açıklama talebi yapılabilir; başvuru otomatik erişim hakkı sağlamaz. Kayıt verisi politikasına 12 Mayıs 2026’da eklenen acil talep hükümlerinin yürürlüğü, talep sahibini doğrulayan ayrı bir konsensüs politikasının tam uygulanmasına bağlıdır. Metindeki bu koşul gerçekleşmeden hızlandırılmış süreleri bütün taleplere uygulanıyormuş gibi kabul etmeyin.

Transfer politikası: mevcut kural ve kabul edilen reform

Yürürlükteki Transfer Policy, kayıt verisi politikasına uyum için güncellenen ve en geç 21 Ağustos 2025’te uygulanması gereken sürümdür. 7 Haziran 2026 Yönetim Kurulu kararı ise daha kapsamlı reform tavsiyelerini kabul etti. 4 Kasım 2026 kontrolünde bu reform ICANN uygulama kuyruğunda yer alıyor. TAC ve kilit tavsiyelerini bugünkü alan adı transfer işleminizin otomatik olarak yürürlükteki koşulları saymayın.

Bugün yapılacak bir transferde kontrol edilecekler:

• AuthInfo/EPP kodunu güvenli kanaldan alın. Kendi kendine yönetim imkânı yoksa mevcut politika, kodun verilmesi ve ilgili clientTransferProhibited kilidinin kaldırılması için beş takvim günü kuralı içerir; diğer geçerli transfer engelleri ayrıca değerlendirilir.
• Kayıt sahibinin erişebildiği iletişim kanalını doğrulayın. Gelen registrarın FOA yükümlülüğünün uygulanmasına ilişkin ICANN ertelemesi bulunduğundan iki tarafın mutlaka aynı onay e-postalarını göndereceğini varsaymayın; mevcut registrarın bildirimlerini takip edin.
• İlk kayıttan veya önceki registrar transferinden sonraki 60 günlük dönem ve kayıt sahibi değişikliği ayrı kilit nedenleridir. Ayrıntılı kontrol listesi aşağıdadır.

Kabul edilen reformun şu başlıkları, yürürlük takvimi tamamlandığında iş akışlarını değiştirecektir:

• TAC: Kodun istek üzerine oluşturulması, registry’de 336 saatlik (14 gün) ömrün uygulanması ve güvenli saklama kuralları. Erken geçersizleştirme koşulları bulunur; hash ile saklama yönlendirmesi registry rolüne aittir.
• Bildirimler: Gelen registrarın FOA şartının kaldırılması, mevcut registrar bildirimlerinin Transfer Confirmation olarak düzenlenmesi ve kod verilmesinin kayıt sahibine bildirilmesi.
• Kilitler: Yeni kayıt ve registrar transferi sonrasında 720 saatlik (30 gün) model; kayıt sahibi verisi değişikliği sonrasındaki mevcut 60 günlük kilidin kaldırılması. Bunlar uygulama bekleyen tavsiyelerdir; bugünkü kilitlerin kalktığı anlamına gelmez.

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

5 Nisan 2024’te yürürlüğe giren sözleşme değişikliklerinde DNS abuse; malware, botnet, phishing, pharming ve bu dört türün dağıtım aracı olduğunda spam olarak tanımlanır. Pharming, kullanıcıların genellikle DNS ele geçirme veya zehirleme yoluyla sahte hizmetlere yönlendirilmesidir. Her istenmeyen e-posta, içerik anlaşmazlığı veya hukuka aykırılık iddiası bu dar DNS abuse tanımıyla aynı değildir; başka hukuk ve sözleşme hükümleri ayrıca uygulanabilir.

Domain sahipleri için pratik etkileri:

• Registrar, incelemeye elverişli kanıtla belirlediği DNS abuse olayında kötüye kullanımı durdurmak veya kesintiye uğratmak için gecikmeden makul ve uygun önlem almalıdır. Tek başına şikâyet otomatik askıya alma kararı değildir.
• İlgili registry, kanıtı alan adının kayıtlı olduğu registrara ileterek veya uygun gördüğünde doğrudan müdahale ederek katkı sağlar. Tarafların görevleri aynı değildir.
• Meşru bir sitedeki ele geçirilmiş alt sayfayı temizlemek, bütün domaini kapatmaktan daha uygun olabilir. Etki, aciliyet ve meşru hizmetlere verilecek zarar birlikte değerlendirilir; her olay için tek bir evrensel müdahale süresi yoktur.
• Bildirimde tam URL’yi, zamanı ve kanıtı inceleyin; hosting sağlayıcısı ve registrar ile düzeltme adımını koordine edin. İletişim bilgilerini güncel tutun ve hassas verileri gereksiz paylaşmayın.

Güncel yazılım, güçlü ve benzersiz parolalar, MFA, uygun WAF kuralları ve temiz e-posta pratikleri farklı riskleri azaltır; hiçbiri kötüye kullanımın yaşanmayacağını garanti etmez. Hesap, uygulama ve yedek güvenliği rehberimiz bu kontrolleri birlikte planlamaya yardımcı olur.

DNSSEC ve teknik güvenlik gereksinimleri

Registry düzeyinde DNSSEC desteği, alan adınızın otomatik imzalandığı anlamına gelmez. İlgili sözleşmenin TLD işletmecisine yüklediği DNSSEC ve IPv6 görevleri ile son kullanıcının DNS sağlayıcısında yapacağı ayarlar farklıdır. Bu rehberdeki ICANN değişiklikleri tüm domain sahiplerine yeni bir DNSSEC, DANE veya CAA zorunluluğu getirmiş gibi okunmamalıdır.

DNSSEC, kısaca, alan adınızın DNS kayıtlarının kriptografik olarak imzalanması. Geçerli bir güven zinciri ve DNSSEC doğrulaması yapan bir çözücü kullanıldığında, sahte veya değiştirilmiş DNS yanıtları tespit edilebilir. 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 kesinti riskini azaltarak anahtar yenilemenin nasıl yapılacağını merak ediyorsanız, DNSSEC key rollover rehberimize göz atmanızı öneririz.

Yeni gTLD programı ve uzantı ekosisteminin genişlemesi

2026 yeni gTLD turunun başvuru dönemi artık gelecek bir plan değildir. ICANN’in 7 Ekim 2026 duyurusu, başvuruların 30 Nisan–12 Ağustos 2026’da alındığını ve 7 Ekim’de yayımlandığını doğrular. 4 Kasım 2026 itibarıyla String Confirmation Day 17 Kasım için planlanıyor. Değerlendirme, olası itirazlar ve sözleşme/delegasyon aşamaları tamamlanmadan bir uzantının kullanılabilir olacağı veya belirli tarihte satışa çıkacağı sonucu çıkarılamaz.

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 bilgileri güncel tutun

Gerekli kayıt verilerini doğru sağlayın; e-posta ve telefonun biçim kontrolü ile gerçekten erişilebilir olduğunun doğrulanması farklı işlemlerdir. WHOIS Accuracy Program, ilgili kayıt veya iletişim değişikliklerinde istisnalarıyla birlikte 15 günlük doğrulama çerçevesi içerir; her durumda hem telefonun hem e-postanın ayrıca doğrulanmasını istemez. Gerekli kayıt sahibi yanıtı gelmezse manuel doğrulama veya doğrulama tamamlanana kadar askıya alma gündeme gelebilir. Bu eski doğruluk yükümlülüklerini yeni RDAP geçişinin getirdiği ani bir kural gibi düşünmeyin.

Ö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?
• Kayıtta istenmişse şirket unvanı, vergi veya ticaret sicil bilgileri doğru mu?

Yanlış kayıt bilgileri veya yanıtlanmayan doğrulama talepleri nedeniyle alan adınız askıya alınabilir. Bu nedenle registrarınızın bildirimlerini takip edin ve alan adı iletişim bilgilerinizi düzenli aralıklarla gözden geçirin.

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

Geçmişte WHOIS çıktılarında ad, adres, e-posta ve telefon gibi bilgiler çoğu zaman herkese açık yayımlanıyordu. Bugün kişisel kayıt verilerinin önemli bir kısmı kamuya açık sorgularda gizlenebiliyor. RDAP bir sorgulama protokolüdür; hangi verilerin yayımlanacağı veya bir talep üzerine açıklanacağı, geçerli kayıt verisi politikalarına ve hukuka bağlıdır.

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 hizmetlerinin (privacy/proxy) kapsamını, kayıt verilerinin kamuya açık sorgularda gizlenmesinden ayrı değerlendirin; hizmet koşullarını okuyun.

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.

3. Transferleri kilit ve doğrulama koşullarına göre planlayın

Transfer planını duyurulan reformun hedeflerine göre değil, işlem tarihinde geçerli politikaya göre hazırlayın. Kayıt sahibi adı, kuruluşu veya e-posta adresindeki önemli değişiklik, registrar değişikliğiyle aynı işlem değildir; önce hangi işlemin yapılacağını netleştirin.

Dikkat edilmesi gerekenler:

• İsteğe bağlı transfer kilidi: clientTransferProhibited durumunu kontrol edin ve planlı transfer için güvenli biçimde kaldırın. Bu işlemin başka politika kilitlerini kaldırdığını varsaymayın.
• İlk kayıt / önceki transfer: Mevcut politika, ilk kayıttan sonraki 60 gün içinde ve önceki registrar transferinden sonraki 60 gün veya belirlenen daha kısa dönemde transferin reddedilmesine izin verir; politika istisnaları ve sağlayıcının uygulaması kontrol edilmelidir.
• Kayıt sahibi değişikliği: Kural olarak 60 günlük registrarlar arası transfer kilidi doğurur. Registrar önceden vazgeçme seçeneği sunuyorsa seçim, değişiklik talebinden önce yapılmalıdır; kilit oluştuktan sonra kaldırılacağına güvenmeyin.
• Planlama: Amaç hem registrar hem sahiplik bilgisi değişikliği ise işlem sırasını destek ekibiyle kararlaştırın. Yanlış iletişim bilgisini sırf kilitten kaçmak için korumayın.

Transfer, DNS veya hosting taşımasıyla aynı işlem değildir. Nameserver, zone hizmeti ve kayıtlar korunuyorsa yalnız registrar değişikliği için TTL düşürmek gerekmez. DNS de değişecekse kayıtları ve DS/DNSSEC zincirini önceden doğrulayın; düşürdüğünüz TTL’nin eski önbellek süresi dolmadan etkili olmayacağını hesaba katın. E-posta ve eski DNS hizmetinin kapanış tarihini plana dahil edin.

4. Alan adı yaşam döngüsünü ve yenileme sürelerini takip edin

Alan adı yaşam döngüsündeki aktif dönem, grace period, redemption ve pending delete gibi aşamaları bilmek yenileme planlaması için önemlidir. Süreleri ve koşulları tüm uzantılar için aynı kabul etmeyin; ilgili registry kurallarını, geçerli politikaları ve registrarınızın yenileme koşullarını birlikte inceleyin.

Ö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 yanıtlarını ilgili uzantının ve registrarın koşullarında arayın. Expired Registration Recovery Policy yenileme bildirimleri, süresi dolan kayıtların geri alınması ve ücretlerin açıklanması için temel kurallar içerir; her domain için aynı kapanış veya silinme günü vermez. Alan adı yaşam döngüsü rehberimiz bu aşamaları planlamanıza yardımcı olur.

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.

DNSSEC, CAA, IPv6 ve modern DNS pratikleri

DNS güvenliği ve erişilebilirliği için aşağıdaki teknik başlıkları değerlendirin. Bunları tüm alan adı sahiplerine yönelik tek bir ICANN zorunluluğu gibi okumamak gerekir:

• DNSSEC desteğini, kurumunuzun tabi olduğu güvenlik standartlarının gereksinimleriyle birlikte değerlendirin.
• CAA (Certification Authority Authorization) kayıtlarıyla alan adınız için sertifika düzenlemeye yetkili sertifika otoritelerini sınırlandırabilirsiniz.
• IPv6 desteğini, hedef ağların erişim ihtiyaçlarına ve altyapınızın olanaklarına göre planlayın.

Kullandığınız DNS sağlayıcısının DNSSEC, CAA, IPv6 desteğini ve bu özelliklerin yönetim yöntemlerini kontrol edin; panelde sunulan seçenekler hizmete göre değişebilir.

SSL/TLS ve alan adı güvenliği ilişkisi

ICANN doğrudan SSL sertifikalarını yönetmiyor; buna karşılık DNS ve alan adı yönetimi, TLS sertifikalarının yetkilendirilmesi ve doğrulanmasıyla ilişkili. Örneğin:

• CAA kayıtları, hangi sertifika otoritelerinin alan adınız için sertifika düzenlemeye yetkili olduğunu belirtir.
• DNS tabanlı ACME challenge (DNS-01) mekanizmaları, wildcard SSL gibi senaryolarda alan adınızın DNS yönetimiyle doğrudan ilişkili.
• DNSSEC ile doğrulanan TLSA kayıtları, DANE destekleyen uygulamalarda TLS kimlik doğrulamasını güçlendirebilir; yalnızca kayıt yayımlamak tüm e-posta ve web istemcilerinde bu korumayı sağlamaz.

Sertifikanın hangi adları kapsadığı, DNS doğrulamasına kimin eriştiği ve yenilemenin nasıl izlendiği birlikte kaydedilmelidir. SSL sertifikaları rehberi temel kavramları açıklar; TLS sürümü, HSTS ve OCSP gibi uygulama ayarları ayrıca değerlendirilir.

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

ICANN alan adı politikalarını operasyonel planlarınıza yansıtmak için şu pratik aksiyon listesini kullanabilirsiniz:

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, güncel ödeme yöntemi ve yenilemeyi doğrulayan izleme var mı?
• Yenileme e-postaları yetkili kişiye gidiyor; domain çalışmasa da erişilebilen kurtarma kanalı bulunuyor mu?
• Registrar kilidi ve sunuluyorsa 2FA açık mı? DNSSEC için geçerli güven zinciri ve değişiklik sorumlusu belli 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:

• İletişim verisini değiştiğinde güncelleyin; yıllık portföy kontrolünü buna ek bir güvence olarak yapın.
• Kurumsal kontrolünüzdeki, takip edilen e-posta adreslerini kullanın; alan adınız erişilemez olduğunda da ulaşabileceğiniz kurtarma kanalı bulundurun.
• DCHost hesabının güvenlik seçeneklerini kontrol edin; 2FA sunuluyorsa etkinleştirin ve kurtarma kodlarını güvenli saklayın.
• İsteğe bağlı registrar kilidini planlı transfer dışında açık tutun; politika kaynaklı kilitlerin ayrı olduğunu unutmayın.

Bu kontroller iletişim kaybı ve yetkisiz işlem riskini azaltır. Başarı ölçütü yalnız ayarın açık görünmesi değil; doğru kişinin bildirim alması, kurtarma yoluna erişmesi ve değişikliği denetleyebilmesidir.

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

Değişiklikleri izleyebilmek ve sorun giderme sırasında doğru bilgilere ulaşabilmek için kritik domainlerinizin basit ama güncel bir dokümantasyonunu 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ış?

Kayıt türleri için DNS kayıtları A’dan Z’ye rehberine bakabilirsiniz. Zone dökümünü güncel tutun; API anahtarları ve kurtarma sırlarını sıradan dokümantasyona koymayın. Dokümanın sahibi ve son kontrol tarihi belli olsun.

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 (genel üst düzey alan adları) 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ı?

Yeni bir duyuruyu değerlendirirken şu üç kaydı ayrı tutun:

• Politika kararı: Öneri veya kamuoyu görüşü mü, GNSO kararı mı, Yönetim Kurulu kabulü mü?
• Uygulama durumu: Kuyrukta mı, uygulama çalışması başladı mı, kesin yürürlük tarihi yayımlandı mı?
• Sizin işleminiz: Hangi uzantı ve sağlayıcı etkileniyor; veri, API, transfer veya sözleşmede hangi işlem gerekiyor?

Transfer reformunu resmî uygulama listesinde, kayıt verisi değişikliklerini ilgili politika metninde, yeni gTLD aşamalarını program duyurularında izleyin. Böylece taslak bir değişiklik için gereksiz işlem yapmadan kesinleşmiş tarihlere hazırlanabilirsiniz.

Her değişiklik için sorumlu kişiyi, etkilenebilecek API veya panel işlemlerini ve doğrulama adımını kaydedin. Test ortamında beklenen sonucu ve hata durumunu kontrol edin; üretim değişikliğini yayımlanmış yürürlük tarihiyle uyumlu planlayın.

Alan adı portföyünüz için ilk kontroller

Önce kritik domainlerin kayıt sahibi verisini, kilit gerekçelerini ve yenileme durumunu kontrol edin. Ardından RDAP entegrasyonlarını ve kötüye kullanım bildirim kanalını gözden geçirin. DNS, TLS ve e-posta yapılandırmalarının çalışması ayrıca doğrulanmalıdır.

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.

Alan adı politikasındaki bir değişikliğin kapsamını, hosting, VPS, dedicated ve colocation altyapılarınız üzerindeki olası etkilerinden ayrı değerlendirin. Alan adı işlemleriyle altyapı veya panel işlemlerinin hangilerini sizin, hangilerini sağlayıcınızın yapacağını netleştirin. 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.