CNAME Flattening Nedir? Cloudflare ve Benzeri Çözümler

Bir domain'in kök adresini (apex) başka bir hostname'e CNAME ile yönlendirmek standart DNS'te mümkün değildir. Bunun nedeni teknik bir kural: zone apex'inde başka kayıtlarla birlikte CNAME bulundurulamaz. CNAME flattening bu kısıtlamayı aşmak için geliştirilmiş bir yaklaşımdır — ve nasıl çalıştığı, hangi sağlayıcıların bunu nasıl uyguladığı, standart CNAME'den tam olarak neyle farklılaştığı konusunda ciddi yanlış anlamalar mevcuttur.

Bu kısıtlama en çok CDN veya SaaS platformlarına geçişte hissedilir. www.example.com'u bir CDN hostname'ine yönlendirmek CNAME ile kolaydır; hedef hostname değiştiğinde tek bir kayıt güncellemesi yeterlidir, IP takibi gerekmez. Ama example.com'u — domain'in kendisini — aynı şekilde yönlendirmeye çalıştığınızda standart DNS bunu reddeder. Zone apex'inde SOA ve NS kayıtları bulunmak zorundadır; bu kayıtların yanında CNAME, DNS kurallarına göre var olamaz. Sonuç: CDN veya platform sağlayıcınız size bir hostname vermiş, siz ise bunu apex'e bağlayamamaktasınızdır.

CNAME flattening, authoritative nameserver'ın bu çözümü kullanıcıya görünmez biçimde uygulamasıdır: apex'teki CNAME hedefini önceden çözümler ve istemciye doğrudan IP adresini döndürür. Sağlayıcılar bu mekanizmayı farklı isimlerle — flattening, ALIAS, ANAME — ve farklı teknik detaylarla sunar. Aralarındaki farkları anlamak, doğru sağlayıcı seçimi ve sorun giderme açısından belirleyicidir.

Zone apex'inde CNAME neden kullanılamaz?

Zone apex, bir DNS zone'unun en üst düzey adıdır; genellikle "@" simgesiyle gösterilir ve domain adının kendisine karşılık gelir. DNS kayıt türleri arasında CNAME özel bir anlambilime sahiptir: bir CNAME kaydı, o isim için gelen tüm sorguları başka bir isme yönlendirir. Hangi kayıt türü sorulursa sorulsun — A, MX, NS, SOA — resolver önce CNAME'i takip eder ve ardından hedef isme yönelik orijinal sorguyu tekrarlar.

Bu davranış, CNAME'in aynı isimde başka kayıtlarla bir arada bulunmasını teknik olarak geçersiz kılar. RFC 1034 zone apex'inde SOA ve NS kayıtlarını zorunlu tutar; RFC 1912 ise CNAME'in diğer kayıt türleriyle birlikte aynı isimde yer alamayacağını açıkça belirtir. SOA ve NS zorunlu, CNAME ise bu zorunlu kayıtlarla çelişen bir yapı olduğundan apex'e CNAME eklemek DNS spesifikasyonunu ihlal eder. DNS yazılımları bu yapılandırmayı hata olarak işler.

; Geçersiz yapılandırma — apex'te SOA ve NS ile birlikte CNAME olamaz
@  IN  SOA  ns1.example.com. admin.example.com. ( 2026041601 3600 900 604800 300 )
@  IN  NS   ns1.example.com.
@  IN  NS   ns2.example.com.
@  IN  CNAME  myapp.cdn-provider.com.   ; HATA — apex'te geçersiz

; Geçerli yapılandırma — subdomain'de CNAME serbesttir
www  IN  CNAME  myapp.cdn-provider.com.   ; Sorunsuz çalışır

Pek çok DNS paneli apex'e CNAME girişini yazılım düzeyinde engeller. İzin veren paneller bulunsa da oluşan yapılandırma geçersizdir ve resolver davranışı tutarsız olur; bazı resolver'lar CNAME'i takip ederken bazıları SOA/NS sorgularını yanıtsız bırakır. Pratikte zone apex kısıtlamasına en çok, subdomain yönlendirmesine alışmış kullanıcılar ilk CDN geçişlerinde çarparlar. CNAME ve A kaydı farkları yazısında bu iki kayıt türünün DNS'teki anlambilimi ayrıntılı karşılaştırılmaktadır.

CNAME flattening nasıl çalışır?

Normal CNAME davranışında authoritative nameserver, istemciye yalnızca CNAME kaydını döndürür. İstemci bu kaydı alır ve hedef hostname'i ayrıca çözmek için yeni bir sorgu yapar. Bu iki adımlı süreç, apex'te sorun çıkarmaz — ancak apex'e CNAME koyulması zaten yasak olduğundan bu senaryoyu ele almanın başka bir yolu gerekir.

CNAME flattening'de authoritative nameserver, sorguyu istemciye iletmeden önce kendi içinde çözümler. CNAME hedefini takip eder, zincirin sonundaki IP adresine ulaşır ve istemciye bu IP'yi doğrudan bir A yanıtı olarak döndürür. İstemci hiçbir zaman CNAME kaydının varlığından haberdar olmaz; perspektifinden bakıldığında apex'te yalnızca bir A kaydı varmış gibi görünür. Zone apex'indeki SOA ve NS kayıtlarıyla çelişme sorunu ortadan kalkar çünkü istemci katmanında CNAME hiç görünmez.

; 1. Zone'da tanımlı (DNS panelinde girilen)
@    300  IN  CNAME  myapp.cdn-provider.com.

; 2. Nameserver'ın arka planda yaptığı (istemciye görünmez)
;    myapp.cdn-provider.com → 203.0.113.50 çözümlenir

; 3. İstemciye döndürülen yanıt (istemci yalnızca bunu görür)
example.com.   300  IN  A  203.0.113.50

Bu mekanizmanın ön koşulu, authoritative nameserver'ın CNAME hedefini çözümleyebilmesi — yani kendi başına recursive sorgu yapabilmesi ya da hedefin IP'sini başka bir yolla bilmesidir. Bazı sağlayıcılar bu çözümlemeyi her sorguda anlık yapar; bazıları sonucu önbelleğe alır ve belirli aralıklarla günceller. Bu fark hem gecikme hem de TTL davranışı açısından önemli sonuçlar doğurur.

Cloudflare, Route 53 ve NS1: farklı sağlayıcı uygulamaları

CNAME flattening teknik bir mekanizma olarak RFC'lerle standartlaştırılmamıştır. Her sağlayıcı bunu kendi nameserver yazılımına özgü biçimde implement etmiştir ve farklı isimler kullanır.

Cloudflare bu özelliği "CNAME Flattening" olarak adlandırır ve zone root için varsayılan olarak etkinleştirir; isteğe bağlı olarak tüm CNAME kayıtları için de açılabilir. Sorgulama anında CNAME hedefini çözümler, sonucu kısa süreli önbellekte tutar. Cloudflare'ın proxy modunda apex için zaten Cloudflare'ın kendi IP'si döndüğünden flattening'in etkisi sınırlıdır; DNS Only modunda ise hedef IP doğrudan açığa çıkar ve flattening apex sorununun tek çözümü haline gelir. Cloudflare DNS kurulumu yazısında bu iki mod arasındaki temel fark ele alınmaktadır.

AWS Route 53 aynı sorunu "ALIAS record" adıyla çözer. ALIAS teknik olarak standart bir DNS kayıt türü değildir; yalnızca Route 53'e özgü bir uzantıdır. Hedef bir AWS kaynağı — CloudFront dağıtımı, Application Load Balancer veya S3 static site endpoint'i — olduğunda Route 53 bu kaynağın IP adreslerini arka planda otomatik olarak takip eder; IP değiştiğinde zone ayrıca güncellemek gerekmez. Hedef AWS dışı bir hostname olduğunda bu otomatik takip çalışmaz ve davranış önemli ölçüde farklılaşır.

NS1 de "ALIAS" adını kullanır; mekanizma Route 53'e yakındır: sağlayıcı CNAME hedefini periyodik aralıklarla çözümler ve sonucu zone'da günceller. Güncelleme sıklığı, TTL uyumunu doğrudan etkiler — daha sık güncelleme, CNAME hedefinin IP değişimlerini daha hızlı yansıtır.

; Cloudflare paneli — Tür: CNAME (flattening otomatik)
Ad:     @
Hedef:  myapp.cdn-provider.com

; AWS Route 53 — Tür: A – Alias
Ad:     example.com
Alias:  myapp.cloudfront.net (AWS kaynağı)

; NS1 paneli — Tür: ALIAS
Ad:     @
Hedef:  myapp.cdn-provider.com

Üç uygulamada ortak olan şey şudur: authoritative nameserver, istemciye CNAME yerine IP döndürür. Farklılaştıkları nokta, önceden çözümlemenin ne zaman yapıldığı, önbellekleme süresi ve hangi kaynakların otomatik takip edildiğidir. Bir sağlayıcıdan diğerine geçildiğinde bu ince farkları göz önünde bulundurmak, beklenmeden farklı davranışların önüne geçer.

ALIAS ve ANAME kaydıyla ilişkisi: farklı isim, aynı mekanizma

CNAME flattening, ALIAS ve ANAME arasındaki ilişki çoğu zaman karışıklığa neden olur. Kısa yanıt: bunlar aynı problemi çözen farklı isimlendirmelerdir. Uzun yanıt ise biraz daha nüanslıdır.

Standart DNS kayıt türleri IANA tarafından tanımlanır ve RFC'lerle belgelenir. Bu standart listede ALIAS veya ANAME adında bir kayıt türü yer almaz. Bu terimler, farklı sağlayıcıların kendi nameserver yazılımına ekledikleri özel uzantıların adlarıdır. Cloudflare "CNAME flattening" mekanizmasını sunarken tip olarak CNAME kullanır; Route 53 "ALIAS record" adını verir ve bunu A veya AAAA kaydı gibi görüntüler; bazı diğer sağlayıcılar ise "ANAME" der. İsimler farklı, çözdükleri sorun aynı: apex'e hostname yönlendirmesi.

ALIAS ve ANAME kaydı yazısında bu kayıt tiplerinin apex domain sorununu nasıl ele aldığı ayrıntılı incelenmektedir. Burada altını çizmek gereken nokta şudur: nameserver'ın bu kaydı nasıl işlediği, kayıt tipinin adından daha önemlidir. ALIAS veya ANAME kullanan bir nameserver, flattening mekanizmasını arka planda çalıştırıyorsa sonuç aynıdır; aynı mekanizmayı kullanmıyorsa kayıt adı ne olursa olsun apex yönlendirmesi doğru çalışmaz.

Standartlaştırma eksikliğinin pratik bir sonucu daha vardır: zone dosyasını bir sağlayıcıdan dışa aktarıp başka birine olduğu gibi aktaramazsınız. CNAME flattening veya ALIAS kayıtları hedef sağlayıcıda manuel olarak yeniden oluşturulmalıdır. Standart zone dosyası dışa aktarımları bu kayıtları genellikle temsil edemez ya da yanlış biçimde dışa aktarır.

Performans ve TTL davranışı: flattening'in getirdiği trade-off'lar

CNAME flattening kullanıcı perspektifinden bir sorgu adımını kaldırır — istemci CNAME hedefini ayrıca çözmek zorunda kalmaz. Ama bu iş nameserver tarafına geçer ve bazı durumlarda beklenmedik performans etkileri yaratabilir.

Nameserver'ın CNAME hedefini çözümlemesi ek bir upstream sorgu anlamına gelir. CNAME zinciri birden fazla halkadan oluşuyorsa (örneğin A → B → C → IP), nameserver zincirin tamamını takip etmek zorundadır. Zincir uzun veya hedef nameserver yavaş yanıt veriyorsa apex sorgularının yanıt süresi artar. Çoğu büyük sağlayıcı bu problemi önbelleklemeyle çözer: çözümlenmiş IP bir süre bellekte tutulur ve her gelen sorgu için yeniden çözümleme yapılmaz.

; Zone'da tanımlı flattening kaydı
@             300  IN  CNAME  myapp.cdn.com.

; CDN sağlayıcısının A kaydı (çok kısa TTL)
myapp.cdn.com.  60  IN  A  203.0.113.50

; Cloudflare'ın istemciye döndürdüğü yanıt:
; Zone'daki TTL (300) kullanılır — CDN'in 60'ı değil
example.com.   300  IN  A  203.0.113.50

; Bazı diğer sağlayıcılar:
; Hedef kaydın TTL'ini (60) kullanır — daha hızlı güncelleme yansıması

Hangi TTL kullanılacağı sağlayıcıya göre değişir. Zone'daki TTL mi, CNAME hedefinin TTL'i mi, yoksa sağlayıcının kendi politikası mı geçerli olacak? Bu, CNAME hedefinin IP'si değiştiğinde güncel değerin istemcilere ne hızda yansıyacağını belirler. CDN sağlayıcıları IP adreslerini sık değiştirir; yüksek TTL bu değişikliklerin gecikmeli yansımasına neden olabilir. Geçiş dönemlerinde TTL değerini düşük tutmak önerilir. TTL seçiminin propagation üzerindeki etkisi için TTL değeri optimizasyonu yazısı ayrıntılı bir çerçeve sunmaktadır.

Coğrafi yönlendirme konusunda da dikkat edilmesi gereken bir trade-off mevcuttur. CDN'ler Anycast veya GeoDNS aracılığıyla istemcinin konumuna göre farklı IP döndürür. Nameserver tarafında yapılan flattening çözümlemesi ise nameserver'ın konumunu veya IP'sini temel alabilir — istemcinin konumunu değil. Bu bazı durumlarda istemcinin en yakın CDN node'una yönlendirilmemesine yol açar. Büyük sağlayıcılar bu problemi kendi altyapılarıyla genellikle çözer; ancak üçüncü taraf nameserver çözümlerinde bu risk değerlendirilmelidir.

Ne zaman flattening gerekmez?

CNAME flattening her durumda zorunlu değildir ve gereksiz yere kullanmak sağlayıcı bağımlılığı ile ekstra karmaşıklık yaratır. Kullanımı zorunlu kılan koşulları net biçimde tanımlamak, hangi durumda daha basit bir yolun mevcut olduğunu görmek açısından önemlidir.

Apex'i doğrudan bir IP adresine bağlayabiliyorsanız flattening'e gerek yoktur. Kendi sunucunuz varsa veya sabit bir IP adresiyle çalışan bir yük dengeleyici kullanıyorsanız apex'e standart bir A kaydı girmek hem daha basit hem de daha öngörülebilir davranış sunar. Flattening yalnızca apex'i bir hostname'e yönlendirmeniz gerektiğinde — ve o hostname'in IP'si doğrudan elinizde olmadığında — devreye girer.

www subdomain'ini canonical adres olarak kullanan mimarilerde de flattening çoğu zaman gereksizdir. Bu yaklaşımda example.com, HTTP katmanında www.example.com'a yönlendirilir. Bu yönlendirmeyi yapacak sunucunun IP'si apex'teki A kaydıyla tanımlanır; gerçek içerik ve CDN entegrasyonu www üzerinden çalışır. Apex için yalnızca bu sunucuyu işaret eden bir A kaydı yeterlidir, CDN'e bağlantı kurulmasına gerek kalmaz.

Sonuç olarak flattening'i zorunlu kılan senaryo şudur: apex'i bir hostname'e yönlendirmeniz gerekiyor ve o hostname'in IP'si sizin kontrolünüzde değil. CDN, SaaS platform veya bulut yük dengeleyicisi gibi IP'si değişebilen ya da size açık olmayan bir hedefe apex yönlendirmesi yapılacağında flattening ya da eşdeğer ALIAS mekanizması pratikte kaçınılmaz hale gelir.

CNAME flattening standart DNS'in dışında, sağlayıcıya özgü bir çözümdür. Bu, hem gücünü hem de sınırını belirler: gücü, RFC'nin yasakladığı bir yapılandırmayı nameserver katmanında şeffaf biçimde mümkün kılmasıdır; sınırı ise taşınabilirlik eksikliği ve sağlayıcı spesifik davranış farklılıklarıdır. Zone'u başka bir DNS sağlayıcısına taşırken bu kaydın dışa aktarılmayacağını, hedefte manuel olarak oluşturulması gerekeceğini baştan hesaba katmak, geçiş sırasında kesinti yaşanmasını önler.