CNAME, bir alan adının başka bir alan adına takma ad (alias) olarak bağlanmasını sağlar. IP adresi döndürmez; yalnızca "bu sorguyu şu adrese yönlendir" bilgisini taşır. DNS resolver bu kaydı gördüğünde zinciri takip etmek zorunda kalır ve hedef adresin kendi kaydına ulaşana kadar sorgulamayı sürdürür.
Bu basit tanımın arkasında birkaç önemli yapısal sınır gizlidir. CNAME'in doğru çalıştığı durumlar kadar çalışamayacağı durumlar da DNS yapılandırmasında en sık karşılaşılan hataların kaynağını oluşturur.
DNS çözümleme zincirinde CNAME'in konumu
Resolver www.sirket.com için sorgu başlattığında ve karşısında bir CNAME kaydı bulduğunda, dönen değer bir IP adresi değil, bir FQDN'dir (Fully Qualified Domain Name). Resolver bu yeni adı alır ve o ada ait kaydı çözümlemek için ikinci bir sorgu başlatır. Bu işleme "CNAME chaining" adı verilir. Teknik olarak zincirleme sonsuz uzayabilir, ancak çoğu resolver 8 ile 16 atlama arasında bir sınır uygular ve bu sınıra ulaşıldığında SERVFAIL döndürür.
TTL hesabı CNAME zincirinde beklentinin dışına çıkabilir. CNAME kaydınızın TTL değeri ne olursa olsun, resolver hedef adresin TTL'ini de beklemek zorundadır. Örneğin 3600 saniyelik bir CNAME kaydı, 60 saniyelik TTL'e sahip bir CDN adresine işaret ediyorsa, önbellekteki çözümleme süresi CNAME TTL'ini değil, hedefin 60 saniyelik TTL'ini izler. Zincirdeki en kısa TTL belirleyicidir.
Her atlama ayrı bir sorgu maliyeti taşır. Tek bir www.sirket.com ziyareti için www.sirket.com → sirket-cdn.net → sirket-cdn-us.net → 104.22.10.15 gibi üç halkalı bir zincir, resolver'ın üç ayrı sorgu yapmasını gerektirir. Önbellekte bu değerler varsa maliyet düşer, ancak TTL süresi dolduğunda tüm zincir yeniden çözülür.
A kaydından farkı ve seçim kriteri
A kaydı doğrudan bir IPv4 adresi döndürür. CNAME bir isim döndürür ve ek sorgu gerektirir. Bu fark iki senaryoda belirleyicidir.
Hedef IP değişebilirse CNAME tercih edilir. CDN servisleri, SaaS platformları ve e-posta dışı üçüncü taraf entegrasyonlar zamanla IP adreslerini değiştirebilir. Siz bir A kaydıyla bu IP'yi sabitlediyseniz, her değişiklikte kendi DNS yapılandırmanızı güncellemeniz gerekir. CNAME kullandığınızda hedef servis kendi IP havuzunu güncellerken sizin kaydınıza dokunmanıza gerek kalmaz.
Hedef IP sabit ve kendi kontrolünüzdeyse A kaydı yeterlidir. Kendi sunucunuzu işaret ediyorsanız bir CNAME katmanı eklemenin pratikte avantajı yoktur; sadece ek bir DNS sorgusu ve potansiyel bir hata noktası eklersiniz.
CNAME kaydı aynı ada başka kayıt eklenmesini engeller. Bir subdomain için CNAME tanımladığınızda, o adın MX, TXT veya başka kayıtları olamaz. Bu kısıt, mail altyapısını CNAME üzerine kurmaya çalışanlarda sorun üretir ve konuya sonraki bölümde ayrıca değineceğiz.
Apex domain'de CNAME kullanılamaz
Sonucu önce verelim: sirket.com için CNAME koyamazsınız. www.sirket.com için koyabilirsiniz.
Neden? RFC 1034, zone apex'inin SOA ve NS kayıtlarını zorunlu olarak barındırması gerektiğini belirtir. CNAME ise tek başına o adın tüm DNS kayıtlarını temsil etme iddiasındadır; yani aynı adda başka kayıt barındırılamaz. Bu ikisi bir arada var olamaz. DNS mimarisi apex'i CNAME'e izin vermeyecek şekilde tasarlanmıştır.
Pratikte bu kısıt gerçek sorunlar doğurur. Kullanıcıların bir kısmı URL'yi subdomain olmadan yazar. sirket.com için iki çözüm yolu vardır:
- Apex domain için A kaydı koyun, CDN veya hosting platformunun sağladığı sabit IP'yi kullanın, yönlendirme (www'ya 301) sunucu katmanında yapılır.
- ANAME veya ALIAS kaydı destekleyen bir DNS sağlayıcısı kullanın. Bu kayıt türleri DNS standartlarının dışındadır ancak resolver tarafında CNAME'i simüle eder ve apex üzerinde çalışır.
Cloudflare'in "CNAME flattening" özelliği üçüncü bir alternatiftir. Cloudflare, apex'te CNAME gibi davranan ancak resolver'a düz A kaydı döndüren kendi uygulamasını çalıştırır. Bu yüzden Cloudflare üzerinden yönetilen bir domainle apex'e CNAME kurabilirsiniz; ama bu standart bir DNS davranışı değil, Cloudflare'e özgü bir çözümdür. Başka bir sağlayıcıya geçtiğinizde aynı yapı çalışmaz.
Yaygın kullanım senaryoları
www subdomaini: www.sirket.com adresini sirket.com'a CNAME olarak bağlamak yaygın bir yapıdır. Apex A kaydıyla sabitlenirken www esnek tutulur. Yönlendirme tercihine göre (www'ya mı apex'e mi?) bu yapı ters de kurulabilir, ancak ikisi arasındaki tutarlılık ve canonical etiketle uyum önemlidir.
CDN entegrasyonu: CloudFront, Fastly, Akamai gibi servisler kendi optimize edilmiş DNS adlarına CNAME vermenizi ister. cdn.sirket.com → sirket.cloudfront.net yapısında CloudFront kendi IP havuzunu dinamik olarak yönetir; siz IP takibi yapmazsınız. Mevcut yapılandırmayı doğrulamak için alan adının DNS kayıtlarını sorgulayabileceğiniz bir araçla kayıt değerlerini anlık olarak görebilirsiniz.
Üçüncü taraf servis entegrasyonu: Destek portalları, form araçları veya pazarlama platformları özel subdomain üzerinden çalışmak için CNAME ister. destek.sirket.com → sirket.helpscout.net gibi bir yapıda SSL sertifikası hedef platforma aittir. Bu kurulumda sertifikanın sizin subdomaininizi kapsaması gerekir; genellikle platform tarafında bir doğrulama adımı (DNS veya HTTP üzerinden) gereklidir.
Birden fazla ortam yönetimi: staging.sirket.com veya test.sirket.com gibi subdomain'ler farklı ortam IP'lerine CNAME ile bağlanabilir. IP değiştiğinde CNAME kaydını güncellemeniz yeterlidir; staging altyapısını döndüren sistemde başka değişiklik gerekmez.
CNAME değişikliği öncesi TTL yönetimi
Mevcut bir CNAME kaydını güncellemeyi planladığınızda, değişikliği DNS yönetim panelinden kaydetmek yeterli değildir. Eski değer, TTL süresi boyunca dünyanın çeşitli resolver'larında önbellekte yaşamaya devam eder. 86400 saniyelik (24 saat) bir TTL'e sahip CNAME kaydında bu pencere oldukça geniştir; bazı ziyaretçiler değişiklikten bir gün sonra hâlâ eski hedefe yönlendirilir.
Bunu önlemenin standart yöntemi önceden TTL'i düşürmektir. Değişikliği planladıktan 24-48 saat önce TTL değerini 300 saniyeye (5 dakika) indirin. Bu süre geçtikten sonra eski önbellek değerleri resolver'lardan temizlenmiş olur; artık TTL'i düşük tutarken asıl hedef değişikliğini yapabilirsiniz. Geçiş tamamlandıktan sonra TTL'i tekrar önceki değerine getirin.
Zincirdeki her halkanın kendi TTL'i olduğunu unutmamak gerekir. Sizin yönettiğiniz CNAME kaydının TTL'ini düşürdünüz, ancak hedef platform kendi kaydı için farklı bir TTL belirlemiş olabilir. Hedef değiştiğinde zincirin tamamının propagasyon süresini doğru hesaplamak için her halkanın TTL değerini ayrı ayrı kontrol etmek gerekir.
Değişiklik sonrasında propagasyonun tamamlanıp tamamlanmadığını doğrulamak için farklı coğrafyalardaki resolver'lara sorgu atabilirsiniz. Google'ın 8.8.8.8 ve Cloudflare'in 1.1.1.1 adresleri farklı önbellek durumlarını temsil eder; her ikisinden de beklenen değeri gördüğünüzde propagasyon büyük ölçüde tamamlanmış demektir. Kendi bölgenizden doğrudan sorgulama için DNS kayıt sorgulama aracıyla anlık resolver yanıtını görebilirsiniz.
Kritik bir servis geçişinde propagasyon penceresini küçültmek için tek seçenek TTL'i önceden düşürmektir. Acil durum planı yoksa ve TTL yüksekken değişiklik yapılırsa, eski ve yeni hedefe giden iki farklı kullanıcı grubu oluşur. Bunu öngörmek, geçiş sonrası hata ayıklamaya harcanan zamanı ciddi ölçüde azaltır.
Yanlış yapılandırmanın ürettiği sorunlar
CNAME döngüsü en sık karşılaşılan yapılandırma hatasıdır. a.sirket.com → b.sirket.com → a.sirket.com gibi dairesel bir yapı oluştuğunda resolver maksimum atlama sayısına ulaşır ve SERVFAIL döndürür. Tarayıcıda bu durum "sunucuya ulaşılamıyor" hatası olarak görünür; sorunun kaynağı DNS seviyesinde olduğu için uygulama veya sunucu katmanına yönelik standart hata ayıklama adımlarıyla tespit etmek vakit alır. DNS kayıtlarını anlık sorgulayarak zinciri adım adım izlemek, döngü noktasını belirlemenin en hızlı yoludur.
E-posta çakışması daha sessiz bir sorundur. Bir subdomain hem CNAME hem MX kaydı barındıramaz. mail.sirket.com'u bir CNAME olarak yapılandırdıysanız, MX kaydı aynı ada eklenemez; var olan MX kaydı ise CNAME tarafından etkisizleştirilir. E-posta altyapısı her zaman A kaydı veya doğrudan IP üzerine kurulmalıdır. SPF ve DKIM TXT kayıtlarını CNAME'li bir adrese eklemek de aynı sorunu üretir; DNS standardı gereği bu kayıtlar CNAME ile birlikte var olamaz ve çoğu panel ikincisini sessizce yoksayar.
SSL uyuşmazlığı üçüncü taraf entegrasyonlarda sık görülür. Hedef CNAME adresinin SSL sertifikası sizin alan adınızı kapsamıyorsa tarayıcı güvenlik uyarısı gösterir. Yeni bir CNAME yapılandırması sonrasında sertifika durumunu ayrıca doğrulamak iyi bir pratiktir; SSL sertifika kontrolü bu doğrulamayı hızlandırır.
CNAME zincirinin uzunluğu da gereksiz yere artmamalıdır. Her halka ek bir DNS sorgusu ve ek bir TTL bağımlılığı ekler. Tercihen bir, zorunlu durumlarda iki halkadan oluşan bir zincir hem performans hem de bakım kolaylığı açısından daha sürdürülebilirdir. Üçüncü taraf platformların zaman zaman kendi CNAME zincirlerine sahip olduğunu da hesaba katarsanız, sizin eklediğiniz her halka bu mesafeyi daha da uzatır. Mevcut yapıyı net görmek için alan adına ait kayıt yapısını sorgulayabileceğiniz bir araçla halkaları sayabilirsiniz. Platforma göre değişen zincir uzunlukları, özellikle CDN servisi değişimlerinde sürpriz olarak karşınıza çıkar.