Bir SaaS veya CDN platformu alan adınızı bir CNAME hedefine bağlamanızı isteyebilir. Bu yöntem www.example.com gibi bir alt alan adında çalışırken, example.com biçimindeki kök alan adında farklı bir sorun çıkar: DNS bölgesinin kökü, yani apex, zorunlu SOA ve NS kayıtlarını da taşır. Standart bir CNAME bu kayıtlarla aynı isimde bulunamaz. Bu nedenle panelin köke CNAME eklemeyi reddetmesi, yalnızca arayüzden kaynaklanan bir kısıt değildir.
ALIAS/ANAME ve Cloudflare CNAME flattening, bu ihtiyaca sağlayıcı düzeyinde çözüm sunar. Panelde bir hedef adı tanımlanır; DNS yanıtında ise uygun adres kayıtları döndürülür. Bu rehber kök CNAME kısıtını, sağlayıcılar arasındaki farkları ve TTL, DNSSEC, e-posta, TLS ile geçiş kontrollerini açıklar. Hedefin IP adreslerini izlemek, hedef adını değiştirmekten farklıdır; platformun özel alan adı desteği de ayrıca doğrulanmalıdır.
CNAME Neden Apex’te Olmaz?
Standart CNAME ile apex kayıtlarının çatışması
CNAME, bir DNS isminin başka bir isme takma ad olduğunu belirtir. Aynı isimde normal veri kayıtlarıyla birlikte bulunamaz; DNSSEC için kullanılan ilgili imza ve inkâr kayıtları bu kuralın özel istisnalarıdır. Bölge kökündeki SOA ve NS kayıtları bu istisnaya girmez. Dolayısıyla apex üzerinde standart CNAME yayımlamak, bölgenin zorunlu kayıtlarıyla çelişir. DNSSEC kullanmak bu çelişkiyi ortadan kaldırmaz.
Temel davranış RFC 1034’teki kural içinde açıklanır; sonraki DNS ve DNSSEC standartları istisnaları ayrıntılandırır. Burada panelde görünen kayıt türüyle internete verilen DNS yanıtını ayırmak gerekir. Cloudflare panelinde köke CNAME girilebilmesi, apex üzerinde standart CNAME yanıtı yayımlandığı anlamına gelmez: sağlayıcının flattening özelliği adres yanıtını üretir.
SaaS ve CDN platformları neden hedef adı verir?
Platformun IP adresleri değişebilir veya hizmet birden fazla uç noktadan sunulabilir. Sağlayıcının desteklediği hedef adını kullanmak, belgelenmemiş bir IP adresini A kaydına kopyalamaktan daha sürdürülebilir olabilir. Alternatif olarak www için normal CNAME kullanıp kökü www adresine HTTP 301 ile yönlendirebilirsiniz. Bu yönlendirme DNS kaydıyla oluşmaz; yönlendirmeyi sunan HTTP(S) hizmeti ve kullanılan her iki isim için geçerli TLS gerekir.
Seçimden önce platformun apex kullanımını destekleyip desteklemediğini kontrol edin. Özel alan adı kaydı, sahiplik doğrulaması, sertifika hazırlığı ve izin verilen proxy modu tamamlanmadan yalnızca DNS yanıtını değiştirmek yeterli olmaz. Sağlayıcı belirli A/AAAA kayıtları öneriyorsa onun desteklediği yöntemi izleyin. ALIAS veya flattening, uygulamanın kabul etmediği bir alan adını kendiliğinden kullanılabilir hale getirmez.
ALIAS ve ANAME: CNAME Konforunu Kural Bozmadan Vermek
DNS yanıtında adres sentezleme
ALIAS ve ANAME adları, sağlayıcıların sunduğu özellikleri ifade eder; her üründe aynı hedefler ve aynı davranış geçerli değildir. Harici hedef adlarını destekleyen bir uygulamada yetkili DNS hizmeti, yapılandırılan adın adreslerini çözer ve apex sorgusuna A veya AAAA yanıtı üretir. Bu yanıt, panelde kalıcı A/AAAA kayıtları oluşturulduğu anlamına gelmez. Dönen adres türleri hedefin ve hizmetin desteklediği kayıtlara bağlıdır.
Hedef adının IP adresleri değiştiğinde sağlayıcı bunları kendi çözümleme ve önbellek politikasına göre izler. Değişikliklerin anında görülmesi veya kesinti yaşanmaması garanti değildir. Hedef zincirinde hata, zaman aşımı ya da bulunamayan bir isim varsa sentezlenen yanıt da etkilenebilir. Hedef adı tamamen değişirse, paneldeki ALIAS/ANAME değerini ayrıca güncellemeniz gerekir; adres takibi bu yapılandırma değişikliğini sizin yerinize yapmaz.
ALIAS desteğinde sağlayıcı sınırları
DNSimple ALIAS gibi özellikler bir dış hizmetin hedef adını çözebilir. Amazon Route 53 Alias ise desteklenen AWS kaynakları ve aynı hosted zone içindeki uygun kayıtlarla sınırlıdır; herhangi bir harici SaaS adını kabul eden genel bir ALIAS değildir. AWS Route 53’ün ALIAS kaydı anlatımı bu ürünün kapsamını anlamak için başlangıçtır. Sağlayıcı seçerken hedef desteğini, yanıt TTL değerini, yenileme ve hata davranışını, DNSSEC ile varsa sağlık kontrolü koşullarını ayrı ayrı inceleyin.
DNS değişikliklerini altyapı koduyla yönetiyorsanız önce plan çıktısını inceleyin: hedef adı, kayıt türü, proxy durumu ve TTL beklenen biçimde değişmeli, e-posta ve doğrulama kayıtları korunmalıdır. Terraform ile VPS ve DNS otomasyonu rehberi bu iş akışını ele alır. Otomasyon tekrarlanabilirlik sağlar; önbellek sürelerini ortadan kaldırmaz ve geri alma işleminin tüm istemcilere anında yansıyacağı anlamına gelmez.
Cloudflare CNAME Flattening Nasıl Çalışır?
Panelde CNAME, sorgu yanıtında adres
Cloudflare yetkili DNS olarak kullanıldığında apex için eklenen CNAME kaydı bütün planlarda varsayılan olarak flatten edilir. Kayıt adı panelde @ olarak gösterilir. DNS-only durumda Cloudflare hedef zincirini çözerek elde ettiği adres yanıtını döndürür; apex sorgusuna normal CNAME zinciri sunmaz. Hedefin geçerli adres kaydı yoksa flattening bunu telafi edemez. Ayrı bir apex flattening düğmesi aramak gerekmez.
Cloudflare CNAME Flattening dokümantasyonu çözümleme davranışını açıklar. Apex dışındaki bütün CNAME kayıtlarını flatten etmek veya belirli kayıtları seçmek farklı seçeneklerdir ve plan koşullarına bağlıdır. Bir üçüncü taraf sahiplik kontrolü CNAME kaydının kendisini görmek istiyorsa, o doğrulama kaydını flatten etmek kontrolü bozabilir. Web trafiğine ait kök kaydıyla doğrulama için verilen alt alan adı kaydını birbirine karıştırmayın.
Proxy açık ve DNS-only yanıtları
Proxy açıkken, yani turuncu bulutta, istemciye Cloudflare anycast adresleri döner; desteklenen web trafiği Cloudflare üzerinden hizmete gider. DNS-only, yani gri bulutta, flattening hedefin çözümlenen adreslerini sunar. Bu yüzden proxied bir apex yanıtının SaaS hedefinin IP adresleriyle aynı olmasını beklemeyin. Proxy seçimi platformun desteğine, protokol koşullarına ve kenar ile kaynak arasındaki TLS yapılandırmasına uygun olmalıdır.
Cloudflare adreslerinin DNS yanıtında görünmesi, origin adresinin başka kayıtlardan veya geçmiş verilerden öğrenilemeyeceğini kanıtlamaz. Doğrudan origin erişimini sınırlandırmak ayrı bir ağ ve uygulama tasarımıdır. DNS-only modda ise Cloudflare HTTP proxy katmanı devrede değildir. İki modun güvenlik, önbellek ve trafik işleme özellikleri farklıdır; yalnızca flattening kullanıldığı için aynı hizmet davranışı elde edilmez.
Yanıt TTL değeri ile hedefin yenilenme süresi
İki süreyi ayrı değerlendirin: istemci çözümleyicisinin aldığı DNS yanıtını ne kadar sakladığı ve sağlayıcının hedef adını nasıl yenilediği. Cloudflare proxied kayıtlarında Auto TTL 300 saniyedir ve düzenlenemez; bu, bütün kullanıcıların değişikliği tam beş dakikada göreceği taahhüdü değildir. DNS-only flatten edilmiş yanıtta TTL, Cloudflare CNAME kaydıyla dış hedef kaydının TTL değerlerinden düşük olanıdır. Yapılandırmayı ve gerçek yanıtı birlikte kontrol edin. Düşük bir TTL tek başına hedefin her istekte yeniden çözüldüğünü göstermez.
DNS katmanının doğru çalışması, uzun süreli uygulama bağlantılarının da doğru yapılandırıldığı anlamına gelmez. Proxy üzerinden WebSocket veya gRPC kullanıyorsanız desteklenen protokolü, zaman aşımını, keep-alive davranışını ve origin erişimini inceleyin. Cloudflare ile WebSocket ve gRPC yayını rehberi bu uygulama tarafını ele alır. Bağlantı kopmalarını araştırırken DNS yanıtını, Cloudflare katmanını ve kaynak sunucunun günlüklerini ayrı ayrı değerlendirin.
Örnek Senaryolar: Kök Alan Adını Bir Hizmete Bağlamak
SaaS hedefiyle kök alan adı kullanmak
Örnek bir mağaza geçişinde platform store.edge.example.net hedefini veriyor ve site example.com üzerinde yayımlanmak isteniyor olsun. Önce platformda kök alan adını kaydedin, doğrulama gereksinimlerini tamamlayın ve TLS hazırlığını kontrol edin. Ardından desteklenen ALIAS/ANAME veya Cloudflare yöntemini seçin. www CNAME ve kökten HTTP 301 de geçerli bir tasarımdır; seçeneğin uygulanabilirliği yalnızca marka tercihine bağlı değildir.
Canlı www kaydını test amacıyla değiştirmeden, geçici bir alt alan adında platformun rotalarını, başlıklarını ve önbellek davranışını sınayın. Bu test, apex için sahiplik veya sertifika hazırlığının yerine geçmez. Kök ile www arasında bir ana adres belirleyin; diğer adın yönlendirmesini, HTTPS erişimini ve path korunmasını kontrol edin. İki adın aynı platforma bağlanması bağımsız bir yedek hizmet oluşturmaz.
Değişen adresler ve çok bölgeli hizmetler
Çok bölgeli veya otomatik ölçeklenen bir platformda hedef adının adresleri değişebilir. ALIAS/flattening manuel IP kopyalama ihtiyacını azaltabilir; ancak sağlık kontrolü ve failover özelliği kendiliğinden eklenmez. Varsa bu davranışı hedef platform veya ayrı bir yük dengeleme hizmeti sağlar. Hedef zincirini, sağlayıcının yenileme politikasını ve uygulamanın hata oranlarını birlikte izleyin; yalnızca bir A yanıtı almak bölgesel hizmet sağlığını kanıtlamaz.
SSL/TLS ve sertifika tarafı
Kullanılan her HTTPS adı için sertifika kapsamını ve platform yapılandırmasını doğrulayın. example.com sertifikası otomatik olarak www.example.com adını kapsamaz; yalnızca *.example.com içeren bir wildcard da kökü kapsamaz. Proxy kullanılıyorsa istemci–kenar ve kenar–origin TLS bağlantılarını ayrı değerlendirin. ECDSA + RSA ikili SSL ile uyumluluk ve hız rehberi anahtar türlerini ele alır; anahtar seçimi, doğru alan adlarının sertifikada bulunması gereksinimini değiştirmez.
301, ana adres ve arama görünürlüğü
Kökten www adresine veya tersine kalıcı geçişte HTTP 301 yönlendirmesini ilgili URL karşılığına uygulayın. HTTPS kullanan kaynak ad, yönlendirme yanıtını vermeden önce geçerli TLS bağlantısı kurabilmelidir; HSTS varsa HTTPS erişimi daha da önem kazanır. Canonical adresleri, iç bağlantıları ve site haritasını seçilen ana adresle tutarlı tutun. DNS yönteminin kendisi sıralama artışı sağlamaz; yönlendirme döngüleri ve erişilemeyen sayfalar ayrıca kontrol edilmelidir.
E-posta kayıtlarını korumak
Adres sentezleyen bir apex yapılandırması, MX ve TXT gibi kayıtları standart CNAME ile aynı isimde bulundurma sorununu aşar. Mevcut kayıtları yine de eksiksiz koruyun: MX ve SPF TXT kökte bulunabilir, DMARC genellikle _dmarc altında, DKIM ise seçici adlarında yayımlanır. SPF Flattening ile 10 lookup duvarını aşma ayrı bir e-posta yetkilendirme tekniğidir. SPF flattening CNAME flattening değildir; dış gönderici adresleri değiştiğinde yenilenmeyen SPF verisi geçerli postayı reddedebilir veya eski adreslere yetki bırakabilir.
DNSSEC, ACME ve Geçiş Kontrolleri
Sentezlenen yanıtların DNSSEC doğrulaması
DNSSEC uyumu sağlayıcının uygulamasına bağlıdır. İmzalı bir bölge için sentezlenen adres yanıtlarının geçerli imzaları ve üst bölgedeki doğru DS zinciri gerekir; hedef adının DNSSEC zinciri apex yanıtına aynen taşınmış sayılmaz. Cloudflare DNSSEC ayrı olarak etkinleştirilir ve kayıt kuruluşundaki DS adımı tamamlanır; flattening kullanmak bunu otomatik yapmaz. Yalnızca iki ağdan yanıt almak yerine doğrulama yapan bir çözümleyiciyle zinciri de denetleyin.
ACME doğrulaması ve sertifika yenileme
ACME HTTP-01 doğrulamasında alan adına gelen doğrulama isteği doğru token yanıtına ulaşmalıdır. DNS-01 ise _acme-challenge altında TXT doğrulaması kullanır ve otomasyon için DNS API erişimi gerektirebilir. Platformun desteklediği yöntemi izleyin; proxyyi gelişigüzel kapatmak yerine yönlendirme, önbellek ve doğrulama yolu koşullarını kontrol edin. Sertifikanın verilmesi kadar platforma yerleşmesi ve yenileme sonrası kullanılmaya devam etmesi de izlenmelidir.
Planlı geçişte TTL ve geri dönüş
Değiştirilebilir bir TTL kullanıyorsanız planlanan geçişten önce düşürün ve önceden önbelleğe alınmış kayıtların eski TTL süresini tamamlamasını bekleyin. Sonra desteklenen kök kaydı değişikliğini yapın. Yanıt TTL değeri, sağlayıcının hedef yenilemesi ve yerel önbellekler aynı şey değildir. Eski hizmeti gözlem süresince hazır tutun, geri dönüş adımlarını kaydedin ve eski kayda dönmenin de önbellekler nedeniyle anında sonuç vermeyebileceğini hesaba katın.
Origin erişimi ve istemci bilgisi
Proxy kullanıldığında origin, bağlantıları Cloudflare gibi ara katmandan alabilir. Ağ kuralları ve gerçek istemci adresini ileten başlıkların güven sınırı buna uygun olmalıdır; internetteki her isteğin gönderdiği başlığa güvenmeyin. DNS-only modda trafik farklı bir yoldan ulaşır. Flattening hedefi çözse bile origin güvenlik duvarı, sanal sunucu veya platformun alan adı eşlemesi isteği reddedebilir; bu katmanları DNS sorunundan ayırın. Giden trafiği kısıtlanan bileşenlerde, kullanılan hedef hostname için DNS çözümlemesini ve hizmetin gerektirdiği dış bağlantıları da sınayın.
DNS ve uygulama sonucunu birlikte doğrulamak
Geçişten sonra yetkili sunucudan ve bağımsız recursive çözümleyicilerden A/AAAA yanıtlarını karşılaştırın. Proxied kayıtta Cloudflare adresi bekleyin; DNS-only kayıtta hedef ve mevcut kayıt türleriyle uyumu inceleyin. Ardından TLS adını, HTTP durumunu, yönlendirme zincirini, kritik sayfaları ve e-posta kayıtlarını kontrol edin. Hata oranı, erişim günlükleri ve bölgesel denemeler, yalnızca DNS kaydına bakarak görülemeyen sorunları gösterebilir.
Kök Alan Adı İçin Uygun Yöntemi Seçmek
Standart CNAME apex üzerindeki zorunlu SOA/NS kayıtlarıyla birlikte yayımlanamaz. ALIAS/ANAME ve Cloudflare CNAME flattening, sağlayıcının desteklediği hedeflerden adres yanıtı üreterek bu ihtiyacı karşılayabilir. Route 53 Alias hedef kısıtları ayrıca değerlendirilmelidir. Bu yöntemler değişen adresleri izlemeye yardımcı olur; hedef adı değişikliğini, SaaS kaydını, TLS hazırlığını veya sağlık kontrolünü sizin yerinize tamamlamaz.
Uygulanabilir bir geçiş planı için önce platformun apex desteğini ve ana adresi belirleyin; ardından uygun DNS/proxy yöntemini seçin. Mevcut e-posta ve doğrulama kayıtlarını koruyun, süreleri planlayın, sertifikayı ve HTTP yönlendirmelerini sınayın. İkili SSL ile uyumluluk ve hız dengesi rehberi sertifika anahtar türlerini, Terraform otomasyon akışı ise değişikliklerin kodla yönetimini tamamlayıcı olarak ele alır. Son kararı yalnızca kısa URL tercihiyle değil, platform uyumluluğu, izlenebilirlik ve geri dönüş hazırlığıyla verin.
