CNAME kaydı nedir
CNAME kaydı (canonical name record), bir DNS adının başka bir adın alias'ı olduğunu söyler. www.example.com CNAME example.net şu anlama gelir: www.example.com hakkında ne öğrenmek istiyorsanız onun yerine example.net'e sorun. Soldaki ad alias'tır; sağdaki ad canonical name, yani kanonik ad ya da hedeftir.
CNAME bir hostname tutar, asla bir IP adresi tutmaz. Sitenin nerede olduğunu söylemez; bunu hangi başka adın bildiğini söyler. Bütün mesele de budur: hedefin sahibi adreslerini istediği an değiştirebilir ve onu gösteren her alias, kimse kendi zone'unu düzenlemeden bu değişikliği izler.
Kayıt, diğer DNS kayıtlarıyla aynı dört parçadan oluşur: ad, TTL, tür ve değer. Bir zone dosyasında aşağıdaki örnek gibi görünür. Hedefin sonundaki noktaya dikkat edin: adın tam olduğunu işaretler; hatalar bölümü bu ayrıntıya geri dönecek.
Bakmaya başlayınca CNAME'leri her yerde görürsünüz. Bir CDN hostname'ini gösteren www, barındırılan bir mağaza platformunu gösteren shop.example.com, bir durum sayfası servisini gösteren status.example.com; SaaS araçlarının oluşturmanızı istediği doğrulama kayıtları da çoğu zaman CNAME'dir. Diğer kayıt türlerini DNS rehberi anlatıyor; bu rehber alias'ta kalıyor.
Bir zone dosyasında CNAME kayıtları
$ORIGIN example.com.
; name TTL class type target (canonical name)
www 3600 IN CNAME example.cdn-provider.net.
shop 3600 IN CNAME shops.hosted-store.example.
status 3600 IN CNAME example.status-service.example.Resolver bir CNAME'i nasıl izler
Tarayıcılar hiçbir zaman CNAME istemez. Bir adres isterler: IPv4 için A kaydı, IPv6 için AAAA kaydı. CNAME, onlar adına sorguyu yapan resolver yolda bir tanesine rastladığında devreye girer.
Resolver, example.com'un yetkili (authoritative) nameserver'larına www.example.com'un A kaydını sorar. Bunlar adres yerine CNAME ile cevap verir: www.example.com, example.cdn-provider.net'in alias'ıdır. Resolver bu kez hedef ad için, cdn-provider.net'in nameserver'larında sorguya yeniden başlar ve A kaydını orada alır. Tarayıcıya iki kaydı birlikte döner: önce CNAME, sonra adres.
İki ad için de yetkili olan aynı nameserver ise bütün zinciri tek cevapta verir ve ikinci gidişi kurtarır. Aksi hâlde her adım ayrı bir sorgudur; bu yüzden bir CNAME soğuk önbellekte birkaç milisaniyeye mal olabilir, cevaplar önbelleğe girdikten sonra ise hiçbir şeye mal olmaz.
CNAME türünün kendisini sorarsanız resolver alias'ta durur ve onu izlemez. Çevrimiçi araçların çoğundaki CNAME sorgulama (CNAME lookup) tam olarak bunu yapar: bir alias'ın hangi adı gösterdiğini söyler, sonunda ulaştığı adresi değil.
$ dig www.example.com A +noall +answer
www.example.com. 3600 IN CNAME example.cdn-provider.net.
example.cdn-provider.net. 60 IN A 203.0.113.25
$ dig www.example.com CNAME +short
example.cdn-provider.net.CNAME ile A ve AAAA kayıtları arasındaki fark
A kaydı bir adı bir IPv4 adresine, AAAA kaydı bir IPv6 adresine eşler. Her sorgunun sonu bunlardır: resolver hangi alias zincirini izlerse izlesin, bir A ya da AAAA kaydında durur. CNAME ise bir adı başka bir ada eşler ve her zaman bir adım daha gerektirir.
Adresi siz yönetiyorsanız ve nadiren değişiyorsa A ya da AAAA kaydı kullanın: kendi sunucunuz, sabit IP'li bir load balancer, bir VPS. Adresin bakımını kendiniz yaparsınız; değişirse onu tutan her kaydı düzenlemeniz gerekir.
Adresi başkası yönetiyorsa CNAME kullanın: bir CDN, barındırılan bir platform, bir SaaS aracı. Onların adresleri değişebilir, bölgeye göre farklı olabilir ya da bir havuzdan gelebilir; sizin bunu bilmeniz gerekmemelidir. Özellikle bir CDN aynı hostname'e farklı yerlerde farklı edge adresleriyle cevap verebilir; onun hostname'ine giden bir CNAME bu davranışı bedavaya alır, kopyalanmış bir IP adresi ise tek bir cevabı dondurur.
Hızdaki pratik fark küçüktür. CNAME yalnızca hedef önbellekte değilse bir sorgu ekler ve popüler hedefler neredeyse her zaman önbellektedir. Bakımdaki fark ise büyüktür: bir sağlayıcının IP'sine sabit yazılmış bir A kaydı, sağlayıcı adreslerini değiştirdiğinde bir sitenin aylar sonra karanlığa gömülmesinin klasik nedenidir.
Kök alan adı neden CNAME olamaz
Kural, DNS'in ilk spesifikasyonundan gelir. RFC 1034 bölüm 3.6.2, bir adda CNAME varsa orada başka veri bulunmaması gerektiğini söyler; RFC 2181 de bunu teyit eder. Nedeni çözümlemenin işleyişidir: CNAME "bu adla ilgili her şey başka yerde" demektir, bu yüzden onu bulan resolver o adda başka bir şey aramayı bırakır. Yanındaki ikinci bir kayıt ya yok sayılır ya da çelişki yaratır. Tek istisna, CNAME'in kendisini imzalayan DNSSEC kayıtlarıdır.
Kök alan adında (apex, yalın example.com) her zaman başka kayıtlar vardır. Her zone'un apex'inde bir SOA kaydı ve NS kayıtları bulunmak zorundadır; çoğu alan adında orada ayrıca e-posta için MX kayıtları, SPF ve alan adı doğrulaması için TXT kayıtları da vardır. Apex'teki bir CNAME bunların hepsinin yerini almak zorunda kalırdı; bu yüzden standart bunu yasaklar ve çoğu DNS sağlayıcısı böyle bir kaydı kaydetmeyi reddeder.
Kabul eden sağlayıcılar ise öngörülemeyen şekillerde bozulan bir zone üretir: bazı resolver'lar CNAME'i döner ve MX kayıtlarını kaybeder, e-postalar geri dönmeye başlar; diğerleri MX kayıtlarını döner ve alias'ı yok sayar. www'nun CNAME için klasik yer olmasının ve yalın alan adının başka bir cevaba ihtiyaç duymasının nedeni budur; o cevap bir sonraki bölümde.
Apex'te bir CNAME'in çakışacağı kayıtlar zaten var
example.com. 3600 IN SOA ns1.dns-host.example. hostmaster.example.com. ( ... )
example.com. 3600 IN NS ns1.dns-host.example.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.mail.example ~all"
; example.com. 3600 IN CNAME example.cdn-provider.net. <- not allowed here
www.example.com. 3600 IN CNAME example.cdn-provider.net. ; fine: www has no other recordsALIAS, ANAME ve CNAME flattening
İnsanlar yalın alan adını da bir CDN'e koymak istediği için DNS sağlayıcıları geçici çözümler geliştirdi. Farklı adlarla anılırlar ama hepsi aynı şeyi yapar: sağlayıcı alias'ı sizin yerinize izler ve sonucu apex'te sıradan A ve AAAA kayıtları olarak yayımlar.
example.com üzerinde CNAME'e benzeyen bir şey yapılandırırsınız. Bir sorgu geldiğinde sağlayıcının nameserver'ı hedefi kendisi çözer, bulduğu adresleri alır ve onlarla cevap verir. Dış dünyaya göre apex'te düz A ve AAAA kayıtları vardır; bu yüzden SOA, NS, MX ve TXT yanlarında kurallara uygun şekilde durabilir. Bazı sağlayıcılar buna ALIAS kaydı, bazıları ANAME, bazıları da CNAME flattening der. Amazon Route 53'ün yalnızca AWS kaynaklarını gösteren kendi alias kayıtları vardır. ANAME bir standart olarak önerildi ama hiç tamamlanmadı; dolayısıyla bunların her biri bir sağlayıcı özelliğidir, sağlayıcı değiştirdiğinizde sizinle gelen bir kayıt türü değil.
Ödünleşimleri bilmeye değer. Adresler ziyaretçinin bulunduğu yere göre değil, sağlayıcının nameserver'ının bulunduğu yere göre seçilir; bu yüzden bölgeye göre farklı cevap veren bir CDN, sağlayıcı ziyaretçinin ağını iletmediği sürece (EDNS Client Subnet) daha az uygun bir edge verebilir. Cevabın ne sıklıkla yenileneceğini de sağlayıcı belirler ve bu, hedefin TTL'inin gerisinde kalabilir. DNS barındırıcınızı değiştirdiğinizde de özellik sizinle gelmez.
Daha yeni, standart bir cevap da var: HTTPS kayıt türünün (RFC 9460) apex'te kullanılmasına izin verilen bir alias biçimi vardır. Tarayıcıların bu biçimi desteklemesi henüz sınırlı; onu bugünün çözümü değil, geleceğin bir seçeneği olarak görün.
CNAME'in yapmadığı şey
CNAME bir yönlendirme (redirect) değildir. Bir adın hangi adreslere çözüleceğini değiştirir, başka hiçbir şeyi değil. Adres çubuğu www.example.com göstermeye devam eder; tarayıcı her istekte yine Host: www.example.com gönderir ve TLS el sıkışmasında www.example.com için geçerli bir sertifika ister.
Bunun insanların takıldığı iki sonucu vardır. Birincisi, hedefin arkasındaki sunucunun sizin hostname'inizi kabul edecek şekilde yapılandırılmış olması gerekir. www'yu bir CNAME ile somebody-else.example.net'e yönlendirmek, onların sunucusunun sizin sitenizi sunmasını sağlamaz; sunucu tanımadığı bir Host için ne sunuyorsa onu sunar, çoğu zaman bir hata sayfası ya da varsayılan bir site. CDN'lerin ve barındırma platformlarının sizden önce hostname'i panele eklemenizi, sonra DNS'i yönlendirmenizi istemesinin nedeni budur.
İkincisi, sertifika hedefin adını değil sizin adınızı kapsamalıdır. example.cdn-provider.net için bir sertifika www.example.com ziyaretçisinin işine yaramaz; kendi adınız için bir sertifika yoksa DNS doğru olsa bile tarayıcılar sertifika uyarısı gösterir.
İstediğiniz şey ziyaretçileri bir URL'den diğerine göndermek, yani adres çubuğunun değişmesiyse, bu bir HTTP yönlendirmesidir: bir web sunucusunun cevap olarak verdiği 301 ya da 302. Bkz. 301 ve 302 yönlendirmeleri.
Sık yapılan CNAME hataları
Apex'te CNAME. Yukarıda anlatıldı: example.com üzerine zorla CNAME koymak yerine DNS barındırıcınızın kök alan adı için sunduğu seçenekleri kullanın.
Başka kayıtların yanında CNAME. Kural yalnızca apex için değil, her ad için geçerlidir. www bir doğrulama için TXT kaydına ihtiyaç duyuyorsa ya da shop'ta zaten bir MX kaydı varsa, oraya ayrıca CNAME ekleyemezsiniz. Çoğu sağlayıcı reddeder; reddetmeyenler sizi resolver'dan resolver'a farklı cevap veren bir adla bırakır. Servis izin veriyorsa doğrulama kayıtlarını kendilerine ait bir ada koyun.
Eksik sondaki nokta. Bir zone dosyasında sonunda nokta olmayan bir ad görelidir ve sonuna zone adı eklenir. example.com içindeki www CNAME example.cdn-provider.net, var olmayan bir ad olan example.cdn-provider.net.example.com. hâline gelir. Hedefi sondaki noktasıyla yazın. Web tabanlı DNS editörleri farklı davranır: çoğu hedefi noktasız alıp noktayı kendisi ekler, birkaçı ise noktayı ister. Forma güvenmek yerine sonucu dig ile kontrol edin.
IP adresine CNAME. Bir CNAME'in değeri hostname olmak zorundadır. www CNAME 203.0.113.25 ya reddedilir ya da hiçbir zaman çözülmeyen bir ad olarak kaydedilir. Adresin yeri A ya da AAAA kaydıdır.
Uzun zincirler. Bir CNAME başka bir CNAME'i gösterebilir, ama her adım olası bir sorgu ve bir TTL daha demektir. Resolver'lar sabit sayıda adımdan sonra vazgeçer; bir döngü (a'dan b'ye, b'den yeniden a'ya) ise doğrudan başarısız olur. Doğrudan sağlayıcınızın verdiği son adı gösterin.
Bir alias'ı gösteren MX ya da NS. RFC 2181 bölüm 10.3, MX ve NS kayıtlarının hedeflerinin CNAME değil, kendi adresleri olan adlar olması gerektiğini söyler. Bazı e-posta sunucuları yine de teslim eder, bazıları etmez.
Sahipsiz (dangling) CNAME'ler. Bir servisi iptal edip promo.example.com CNAME old-campaign.platform.example kaydını yerinde bırakırsanız, o adı daha sonra aynı platformda sahiplenen herkes sizin alt alan adınızda içerik sunabilir. Buna subdomain takeover (alt alan adı ele geçirme) denir. Servisi silerken CNAME'i de silin.
Sondaki nokta, doğrusu ve yanlışı (example.com zone dosyası)
; wrong: relative target, becomes example.cdn-provider.net.example.com.
www 3600 IN CNAME example.cdn-provider.net
; right: fully qualified target
www 3600 IN CNAME example.cdn-provider.net.
; wrong: a CNAME plus another record at the same name
shop 3600 IN CNAME shops.hosted-store.example.
shop 3600 IN MX 10 mail.example.com.CNAME kaydı nasıl sorgulanır
dig (Linux, macOS, WSL üzerinden Windows) en net araçtır. dig www.example.com CNAME +short alias'ın hedefini yazdırır. dig www.example.com +noall +answer adreslere kadar bütün zinciri yazdırır. dig @1.1.1.1 ... ya da dig @8.8.8.8 ... belirli bir genel resolver'a sorar; önbellekteki bir cevaptan şüphelendiğinizde işe yarar. dig +trace ise delegasyonu kök sunuculardan aşağı doğru izler ve her önbelleği atlayarak yetkili nameserver'ların şu an ne söylediğini gösterir.
nslookup düz Windows dahil her yerde vardır: nslookup -type=CNAME www.example.com. Windows PowerShell'de Resolve-DnsName www.example.com -Type CNAME daha derli toplu bir cevap verir.
Çevrimiçi sorgulama araçları kendi resolver'larından, çoğu zaman aynı anda birkaç ülkeden cevap verir. Özellikle tek bir soru için kullanışlıdırlar: dünyanın geri kalanı sizinle aynı cevabı görüyor mu? Bazı konumlar eski hedefi, bazıları yenisini gösteriyorsa değişiklik hâlâ yayılıyordur.
Cevap yanlış görünüyorsa doğrudan yetkili nameserver'a sorun. Önce dig NS example.com +short ile onu bulun, sonra @ ile ona sorgu gönderin. Yetkili sunucuda doğru cevap varken genel bir resolver'da yoksa, karşınızdaki henüz süresi dolmamış bir önbellektir. Yetkili sunucu yanlışsa kaydın kendisinin düzeltilmesi gerekir; NS kayıtları hangi DNS barındırıcısını gösteriyorsa orada.
# the target of the alias
dig www.example.com CNAME +short
# the full chain, alias to address, from a public resolver
dig @1.1.1.1 www.example.com +noall +answer
# straight from the authoritative nameserver, no cache involved
dig NS example.com +short
dig @ns1.dns-host.example www.example.com CNAME +short
# Windows
nslookup -type=CNAME www.example.com
Resolve-DnsName www.example.com -Type CNAMECNAME için TTL ve yayılma
Bir zincirdeki her kayıt kendi TTL'i boyunca önbellekte tutulur. Yukarıdaki dig örneğinde CNAME'in TTL'i 3.600 saniye, hedefin A kaydınınki 60 saniyedir. Bir resolver alias'ı bir saat, adresi bir dakika tutar. Bir CDN ile istediğiniz bölünme tam olarak budur: sağlayıcı adreslerini bir dakika içinde taşıyabilir, sizin kendi kaydınız ise neredeyse hiç değişmez.
Bu, kendi değişikliklerinizin ne kadar süreceğini de söyler. www'yu bir hedeften diğerine yönlendirirseniz, eski CNAME'i önbelleğe almış resolver'lar TTL'i dolana kadar onu kullanmaya devam eder; TTL 3.600 ise geçiş, kaydettiğiniz andan itibaren bir saat içinde tamamlanır. Planlı bir değişiklikten bir gün önce TTL'i 300'e indirin, değişikliği yapın, sonra yeniden yükseltin.
İki şey kaydın TTL'inden uzun sürer. Daha önce var olmayan bir ad, zone'un SOA kaydındaki negatif önbellek süresi boyunca "yok" olarak önbellekte tutulabilir; biri o adı sorguladıktan hemen sonra eklenen CNAME'in görünmesi bu kadar sürebilir. Kayıt firmanızda (registrar) nameserver değiştirmek ise bir kaydı değiştirmekten farklı bir işlemdir: registry'nin delegasyona verdiği TTL'e bağlıdır ve bu çoğu zaman bir iki gündür. Genel olarak yayılmayı DNS rehberi anlatıyor.
CDN.com.tr'de bir alan adını CNAME ile CDN'e yönlendirmek
Tipik CDN kurulumunda www ve diğer alt alan adları CDN hostname'ine giden bir CNAME ile bağlanır, kök alan adı ise ayrıca ele alınır. CDN.com.tr'de panelde üç sunum yönteminden birini seçersiniz.
Varsayılan Uç Nokta, içeriğinizi DNS işi gerektirmeden bir xyz.cdn.com.tr hostname'inden sunar. Test etmenin en hızlı yoludur; daha sonra kendi alan adınıza geçebilirsiniz.
Özel Alan Adı/Alt Alan Adı (CNAME), DNS'inizi olduğu yerde bırakır. Hostname'i panele eklersiniz, örneğin www.example.com ya da assets.example.com, ve DNS barındırıcınızda onu panelin gösterdiği, <yourname>.cdn.com.tr biçimindeki hedefe yönlendiren bir CNAME oluşturursunuz. Hedefi fazladan önek eklemeden, birebir kopyalayın. Kök alan adı bu yöntemi kullanamaz; onun için panel A kaydı ya da Tam DNS Transferi sunar. CNAME ile bağlanan bir hostname kendi sertifikasını alır; sertifika, istekler edge'e ulaşır ulaşmaz HTTP üzerinden doğrulanır. CDN hostname'lerinde A kayıtlarının yanında AAAA kayıtları da bulunduğu için, bize giden bir CNAME ada IPv6'yı da kazandırır; sizin tarafınızda ek bir kayıt gerekmez.
Tam DNS Transferi, alan adının nameserver'larını CDN.com.tr'ye taşır. Apex sorununun temiz cevabı budur: panel zone editörünüz olur, kök alan adı CNAME geçici çözümü olmadan edge'e yönlendirilir ve kök, alt alan adlarını da kapsayan bir wildcard sertifika alır. Panel, nameserver değişikliğinden önce mevcut kayıtlarınızı (MX, TXT, alt alan adları) tarar ve içe aktarır; sertifikayı da geçişten önce mevcut sağlayıcınızdaki bir DNS TXT kaydıyla aldırabilirsiniz, böylece HTTPS ilk dakikadan çalışır.
CDN DNS kurulum rehberi geçişi adım adım anlatıyor. CNAME çözülmeye başlayınca isteklerin gerçekten edge'den geçtiğini kontrol edin: X-Proxy-Cache-MT yanıt başlığı, edge'in cevabı kendi önbelleğinden verip vermediğini gösterir.
$ dig www.example.com CNAME +short
yourname.cdn.com.tr.
$ curl -sI https://www.example.com/ | grep -i x-proxy-cache-mt
X-Proxy-Cache-MT: HITCNAME kaydı hakkında sık sorulanlar
Kök alan adım için CNAME kaydı kullanabilir miyim?
Standart DNS kurallarına göre hayır. CNAME bulunduğu addaki tek kayıt olmak zorundadır; kök alan adında ise her zaman SOA ve NS kayıtları, genellikle de MX ve TXT kayıtları vardır. A ve AAAA kayıtlarını, DNS sağlayıcınızın ALIAS, ANAME ya da flattening özelliğini kullanın veya DNS'inizi siteyi sunan sağlayıcıya taşıyın ki apex'e doğrudan cevap verebilsin.
CNAME bir yönlendirmeyle aynı şey mi?
Hayır. CNAME yalnızca bir adın hangi adreslere çözüleceğini değiştirir; tarayıcı sizin hostname'inizi adres çubuğunda, Host başlığında ve sertifika kontrolünde tutmaya devam eder. Yönlendirme ise ziyaretçiyi başka bir URL'e gönderen, 301 gibi bir HTTP yanıtıdır.
CNAME başka bir alan adını gösterebilir mi?
Evet, en yaygın kullanımı budur: www.example.com'un başkasının alan adındaki bir CDN ya da SaaS hostname'ini göstermesi. Hedefin yalnızca çözülebilen bir hostname olması yeterlidir. Arkasındaki servisin de sizin hostname'inizi kabul edecek şekilde yapılandırılmış olması ve onun için bir sertifika tutması gerekir.
Aynı adda bir CNAME ile bir MX ya da TXT kaydı olabilir mi?
Hayır. CNAME olan bir ad, DNSSEC imzaları dışında başka kayıt tutamaz. Bir servis aynı adda hem TXT kaydı hem CNAME istiyorsa, servis izin veriyorsa TXT kaydını başka bir ada koyun ya da CNAME yerine A kaydı kullanın.
CNAME, A kaydından daha mı yavaş?
Yalnızca soğuk önbellekte, resolver hedefi ayrıca sorgulamak zorunda kaldığında; bunun maliyeti birkaç milisaniyedir. Önbellekteki cevapların ek maliyeti yoktur. Sağladığı esneklik genellikle bu farktan çok daha değerlidir, özellikle hedef adreslerini değiştiren bir CDN'e aitse.
Bir CNAME değişikliğinin etkili olması ne kadar sürer?
En fazla eski kaydın TTL'i kadar: resolver'lar önceki cevabı süresi dolana kadar tutar. TTL 3.600 saniyeyse bu en fazla bir saattir. Yepyeni bir ad, kısa süre önce sorgulanıp "yok" olarak önbelleğe alındıysa daha uzun sürebilir. Planlı değişikliklerden bir gün önce TTL'i düşürün.
CNAME ile DNAME arasındaki fark nedir?
CNAME tek bir adı birebir alias'lar. DNAME ise bütün bir alt ağacı alias'lar: old.example.com altındaki her ad, new.example.net altındaki aynı ada eşlenir, ama old.example.com'un kendisi eşlenmez. DNAME web sitelerinde nadirdir ve birçok DNS barındırıcısı onu sunmaz.