IDN: Türkçe Karakterleri Domain'de Kullanmak Mümkün mü?
Türkçe karakterli domain fikri, yerel izleyiciye yönelik bir web varlığı kurmak isteyenler için cazip görünür. "müzik.com" ya da "şehir.net" biçiminde bir adres akılda kalıcıdır ve dil tutarlılığı sağlar. Teknik gerçeklik ise bu cazibeyi belirli ölçüde karmaşıklaştırır.
IDN (Internationalized Domain Name) standardı 2003'ten bu yana IETF protokollerinde yer alır. Büyük tarayıcıların çoğu IDN'i tanır, modern DNS çözümleyicileri Punycode dönüşümünü yönetir; buna karşın nameserver yazılımları, e-posta altyapıları ve bazı içerik yönetim sistemleri tutarsız destek sunar. MX katmanı posta yönlendirmesinde Punycode'u ayrı doğrular. Destekleniyor, ama her katmanda eşit ölçüde değil.
Üç somut soruyu yanıtlamak bu tabloyu netleştirir: Punycode dönüşümü nasıl çalışır? IDN uyumlu nameserver ne anlama gelir, hangi senaryoda zorunlu hale gelir? Tarayıcı adres çubuğuyla DNS katmanı birbirinden nasıl ayrışır?
DNS'in ASCII Sınırı ve IDN'in Bu Sınırı Aşma Biçimi
DNS protokolü 1980'lerde tanımlandı. O dönemde alfabe ASCII ile sınırlıydı; kayıt türleri hâlâ A, CNAME, MX, TXT olarak bu kısıtın üstünde durur; yani yalnızca a-z arası harfler, 0-9 rakamlar ve tire karakteri geçerliydi. Bu kısıtlama protokolün çekirdeğine işledi ve onlarca yıl boyunca değişmedi.
ş, ğ, ü, ö, ç, ı gibi Türkçe karakterler bu kümenin dışında kalır. DNS protokolünü yeniden yazmak yerine, Unicode karakterleri ASCII'ye dönüştüren bir ara katman geliştirmek çok daha pratikti. ASCII-Compatible Encoding (ACE) adı verilen bu yaklaşımın somut uygulaması Punycode'dur (RFC 3492).
Punycode, bir domain etiketini alır, ASCII bölümünü olduğu gibi bırakır, ASCII dışı karakterleri ise belirli bir algoritmayla ASCII karakterlerinden oluşan bir koda dönüştürür. Sonuç her zaman "xn--" önekiyle başlar. Registrar sisteminiz ya da tarayıcınız bu dönüşümü arka planda sizin adınıza yapar; DNS sorgusuna gönderilen her zaman Punycode biçimidir.
Bu mimari, DNS protokolünü hiç değiştirmeden Unicode domaine kapı açar. Çözüm zarif görünür; ancak dönüşümün her katmanda tutarlı biçimde gerçekleşmesi gerektiği için zincirin herhangi bir halkası bu dönüşümü atlasa tüm sistem tutarsızlaşır.
Punycode Dönüşümü: Türkçe Örnekler ve Pratik Sonuçlar
Dönüşüm mantığını somutlaştırmak için birkaç örnek:
müzik.com→xn--mzik-7na.comşehir.net→xn--ehir-xta.netgüvenlik.com.tr→xn--gvenlik-q4a.com.tr; .tr tescili yine nic.tr belgelerini isteröğrenci.org→xn--renci-9qa3b.org
"xn--" öneki sabit; sonraki kısım IANA standardına uygun bir algoritmadan üretilir. Algoritma deterministik olduğundan aynı Unicode giriş her zaman aynı Punycode çıktısını verir; iki farklı araçta hesaplasanız da sonuç değişmez.
Her label ayrı işlenir. Domain yapısında label, iki nokta arasındaki bölümdür. "güvenlik.com.tr" ifadesinde yalnızca "güvenlik" labeli Punycode'a çevrilir; "com" ve "tr" ASCII olduğu için olduğu gibi kalır. Çok bölümlü IDN subdomainlerde her bölüm bağımsız değerlendirilir: "müzik.şehir.com" için her iki label da ayrı ayrı kodlanır, ardından birleştirilir.
Registrar paneli çoğu zaman Unicode girişi kabul eder ve dönüşümü sizin yerinize yapar. Zone dosyası düzenleme, programatik API çağrısı veya WHOIS sorgusu sırasında ise Punycode biçimiyle doğrudan çalışmak gerekir. Bu iki ortam arasında geçerken ne gördüğünüzü bilmemek, "kayıt başarılı" mesajına rağmen yanlış kaydın saklandığı durumlar doğurabilir; özellikle eski panel sürümlerinde bu karışıklık kaydedilmiş sorunlardandır.
Subdomain senaryolarında dikkat gereken bir nokta daha var. "api.müzik.com" gibi bir adreste "müzik" labeli Punycode'a çevrilir, "api" olduğu gibi kalır. Zone dosyasına kayıt eklerken subdomain kısmını ASCII olarak, parent domaini Punycode olarak yazmak standart yaklaşımdır. Eğer zone dosyası başlığında IDN domaini yanlış biçimde belirtilmişse, altındaki tüm kayıtlar hatalı çözümleme üretebilir.
IDN Uyumlu Nameserver: İki Ayrı Senaryo
IDN uyumluluğu çoğu zaman yalnızca domain adıyla ilişkilendirilir. Nameserver katmanı daha az konuşulur; ama bazı kurgumlarda belirleyici olur. İki ayrı senaryoyu birbirinden ayırt etmek gerekir.
İlk senaryo: nameserver'ın kendisi IDN barındırıyorsa. "ns1.türk-host.com" gibi Türkçe karakterli bir nameserver adresi, Punycode biçimiyle kayıt edilmek zorundadır. Bu durumda registrar panelinin söz konusu nameserver değerini doğru biçimde kayıt altına alıp almadığını test edin. Bazı eski paneller "xn--" önekine karşı hata döndürür ya da sessizce yok sayar; kayıt tamamlandı görünse de arka planda nameserver doğru tanımlanmamıştır.
İkinci senaryo: nameserver ASCII isimlere sahip, ancak IDN bir domain için kayıt tutuyor. Zone dosyasına A, CNAME, MX gibi kayıtlar eklenirken, bu kayıtlara atanan domain Punycode biçiminde yazılmak zorundadır. Zone başlığında ve kayıt satırlarında Punycode kullanılmadıkça kayıt eşleşmez ya da hatalı çözümleme üretir.
BIND 9.x ve Knot DNS her iki senaryoyu da destekler. Özel nameserver kuruyorsanız, kurulumun ardından bir zone dosyasına xn-- önekli kayıt ekleyip dig ile sorguyu doğrulayın. Özel nameserver kurulum sürecinde bu test adımını atlamak, görünmez yönlendirme hatalarına yol açar; çözümleme bazen kısmen çalışıyor gibi görünür ama belirli kayıt tiplerinde sessizce başarısız olur.
Nameserver yazılımınız IDN desteği sunmuyorsa alternatif yol, IDN domaini yönetmek için IDN uyumlu bir dış DNS sağlayıcısına yönlendirmektir. Bu durumda nameserver kayıtlarını registrar panelinde güncelleyerek zone yönetimini IDN destekleyen platforma devretmiş olursunuz.
Tarayıcı Adres Çubuğu ile DNS Günlüğü Neden Farklı Konuşur?
Tarayıcılar IDN domainleri adres çubuğunda Unicode olarak gösterir. "xn--mzik-7na.com" yerine "müzik.com" görürsünüz. Bu kullanıcı deneyimi açısından tutarlıdır; ama bir güvenlik mekanizması da arka planda çalışır.
Homograph saldırısı şu anlama gelir: Latince "a" (U+0061) ile Kiril "а" (U+0430) görsel olarak neredeyse aynıdır. Bu benzerlikten yararlanan sahte domainler, kullanıcıyı kolayca yanıltabilir. Tarayıcılar bu nedenle karışık alfabe kullanan IDN domainlerini adres çubuğunda Unicode yerine Punycode olarak gösterir; böylece "şüpheli" görünüm kullanıcıyı uyarır.
Türkçe karakterler bu açıdan ayrı bir kategoride yer alır. ş, ğ, ü, ö, ç, ı harfleri Latin alfabe uzantısı kabul edilir; başka alfabe sistemleriyle karıştırma riski taşımaz. Yalnızca Türkçe karakter içeren bir domain bu yüzden adres çubuğunda Unicode biçiminde görünür. Buna karşın hem Latin hem Kiril karakter içeren bir kombinasyon girilirse, tarayıcı güvenlik önlemi olarak Punycode gösterimini seçer.
DNS çözümleme katmanında ise tarayıcı her zaman Punycode kullanır. Kullanıcı adres çubuğuna "müzik.com" yazmış olsa bile, DNS sorgusuna gönderilen değer "xn--mzik-7na.com"dur. DNS günlüklerini veya trafik analizini izleyenler Unicode değil, Punycode biçimini görür. Bu ayrım CDN yapılandırması ve güvenlik duvarı kuralları yazarken önem taşır; kural içine Unicode değil Punycode yazmak gerekir, aksi halde eşleşme sağlanamaz.
Tarayıcı önbelleğinin bu dönüşümü nasıl sakladığı da dikkat gerektiren bir noktadır. Önbellek girdileri Punycode anahtarıyla saklandığından, tarayıcı geçmişinde veya sekme geri döndürme davranışında tutarsızlıklar gözlemlenmişti; güncel tarayıcı sürümlerinde bu sorunlar büyük ölçüde giderilmiş olmakla birlikte, eski sürümlerde çalışan kullanıcıları olan sitelerde kontrol etmeye değer.
E-posta Protokolünde IDN Desteği Neden Zayıf Kalmaya Devam Ediyor?
IDN domaini seçerken en çok göz ardı edilen alan e-postadır. Birçok kişi tarayıcının sorunsuz çalıştığını görünce e-postanın da çalışacağını varsayar. İkisi farklı protokollerdir.
SMTP geleneksel olarak yalnızca ASCII kabul eder. RFC 6530 ile başlayan EAI (Email Address Internationalization) standardı IDN domainli adresleri mümkün kılmıştır; ancak uçtan uca destek zayıf kalmaya devam ediyor. Gönderen sunucu EAI desteklese bile alıcı sunucu desteklemiyorsa teslim başarısız olur ya da bir hata kodu döner. Büyük e-posta sağlayıcılarının önemli bir bölümü EAI'yi henüz tam olarak hayata geçirmemiştir.
Pratik sonuç açıktır: "info@müzik.com" adresine e-posta göndermek, çoğu durumda ya başarısız olur ya da alıcı taraf tarafından reddedilir. E-posta teslim edilebilirliği zaten DNS yapılandırmasına duyarlıdır; bir de IDN kaynaklı protokol uyumsuzluğu eklenmesi sorunları çözmek yerine katmanlar. Bu tablo, IDN domaini web adresi olarak tutmayı, e-posta içinse ayrı bir ASCII domain kullanmayı zorunlu kılabilir.
MX kayıtları zone dosyasında Punycode biçiminde doğru girilse bile, MX değerini okuyan e-posta istemcilerinin bunu yorumlaması altyapıdan altyapıya değişir. Kurumsal e-posta sunucularında bu davranışı test etmeden IDN domainine geçmek risklidir. Test edilmemiş bir IDN e-posta kurulumu hem gelen hem giden trafiği sessizce düşürebilir.
IDN Domaini Ne Zaman Seçmeli, Ne Zaman Kaçınmalı?
Üç koşul bir araya geldiğinde IDN domain makul bir seçimdir: hedef kitle yalnızca Türkçe konuşuyor, siteye erişim e-posta gerektirmiyor ve altyapı sağlayıcıları IDN desteği sunuyor. İçerik siteleri, QR kodla erişilen kurumsal tanıtım sayfaları ve yerel hizmet rehberleri bu tanıma girer. Basılı materyal ya da billboard'da yer alan ve kullanıcının elle yazmak yerine tarayacağı domainlerde de işe yarar; Punycode'u kimse elle girmez ama Unicode adresi tarama için uygundur.
Kaçınmayı düşünmeniz gereken durumlar daha uzun bir liste oluşturur. E-posta birincil iletişim kanalıysa EAI desteğinin tutarsızlığı sizi zorlar. API entegrasyonlarınız veya webhook URL'leriniz IDN içeriyorsa, istemci kütüphanelerinin Punycode dönüşümü desteklemesi gerekir; bazı eski kütüphaneler bunu yapmaz ve sessizce hata üretir. Vercel ve Netlify gibi platformlarda özel domain kurulumu sırasında IDN içeren adresler zaman zaman ek doğrulama adımı ya da manuel Punycode girişi gerektirir.
SEO açısından IDN domain teknik olarak standart bir domain gibi indekslenir; arama motorları Punycode'u anlayarak içeriği normal biçimde tarar. Bununla birlikte arama sonuçlarında snippet içinde "xn--..." biçimi görünüyorsa kullanıcı güveni olumsuz etkilenebilir. Özellikle sosyal medya paylaşımlarında bazı platformlar Punycode biçimini olduğu gibi gösterir ve link önizlemesi oluşturmaz.
Uluslararası kullanıcı kitlesine yönelik, içerik yönetim sisteminizin IDN'i beklemediği ya da ekip üyelerinin farklı araçlar kullandığı geniş ekiplerde ASCII domain tercih etmek genellikle daha az sorun üretir. IDN domain yanında bir ASCII domain tutmak, her iki erişim biçimini destekler: Unicode domain görünümüyle öne çıkarken, ASCII domain e-posta ve API entegrasyonlarında güvenilir seçenek olarak çalışır.
SSL/TLS Sertifikası IDN Domain İçin Nasıl Alınır?
SSL/TLS sertifikası sürecinde domain adı sertifika otoritesine Punycode biçiminde iletilir. Sertifika otoriteleri IDN domainleri tanır; CA panelleri çoğunlukla Unicode girişi kabul eder ve dönüşümü arka planda yapar, ancak otomasyon araçlarına doğrudan Punycode vermek daha güvenilir sonuç üretir.
Let's Encrypt üzerinden ACME protokolüyle sertifika alırken certbot gibi araçlara domaini Punycode biçiminde girmek en tutarlı yaklaşımdır. certbot --domain xn--mzik-7na.com komutu, bazı araç sürümlerinde Unicode girişini yanlış işleyen durumları önler. İşlem tamamlandıktan sonra sertifika içeriğini openssl x509 -noout -text -in cert.pem komutuyla doğrulayın; SAN (Subject Alternative Name) alanında beklenen Punycode değerinin listelendiğini teyit edin.
Wildcard sertifika kullanıyorsanız SAN alanına *.xn--mzik-7na.com biçiminde Punycode ile girin. Zone dosyası üzerinde yetki doğrulaması (DNS-01 challenge) yapılırken eklenen TXT kaydının da Punycode domain altında yer aldığından emin olun. Zone yönetimi için IDN desteği olan bir DNS sağlayıcısı kullanmak bu adımı basitleştirir; sağlayıcının API'si Punycode değerini parametre olarak kabul ediyorsa TXT kaydı hatasız eklenir.
IDN domain kullanımında en sık karşılaşılan sorun, farklı katmanlardaki araçların birinin Unicode, diğerinin Punycode beklentisiyle çalışmasıdır. Registrar paneli Unicode kabul ederken zone dosyası Punycode ister; tarayıcı adres çubuğu Unicode gösterirken CDN kuralları Punycode eşleştirmesi bekler. Bu uyumsuzlukları önceden haritalamak, sonradan hata ayıklamaktan çok daha az maliyet taşır.
Domain portföy yönetimi açısından IDN domainleri ayrı bir kategori olarak takip etmek işe yarar: yenileme bildirimleri Punycode biçiminde gelir, WHOIS sorguları Punycode kullanır, alan sahipliği belgesi Punycode değeriyle düzenlenir. Unicode ve Punycode arasındaki görsel fark, süresi dolan domainleri gözden kaçırmayı kolaylaştırır.
Türkçe karakterli domain, doğru katmanlarda doğru biçimde kullanıldığında teknik bir engel olmaktan çıkar. Punycode dönüşümünü anlayan, nameserver yapılandırmasını test eden ve e-posta altyapısını ayrı tutan bir kurgu, IDN domainin tüm avantajlarını sürdürülebilir şekilde sunar.