Bir Domain, Bir Kahve ve Kökte CNAME Dileği

{
“title”: “Apex Alan Adında CNAME Olur mu? Kökte Yönlendirme Sırrı: ALIAS/ANAME ve Cloudflare Flattening”,
“content”: “n

Hiç şöyle oldu mu? Alan adını yeni bir SaaSu2019a bağlayacaksın, dökümanda kocaman u201cCNAME ekleu201d yazıyor, ama senin kafandaki plan apex u2013 yani kök domain. u201cwwwu201d istemiyorsun, tertemiz ornek.com çalışsın, hem de tek kaydıyla. DNS paneline giriyorsun, CNAME yazmaya kalkıyorsun ve pat: izin yok. İşte o gün, ben de ofiste aynı duvara tosladım. Kahveyi bir kenara bırakıp u201cPeki şimdi ne olacak?u201d diye düşündüm. Aslında mesele kural dışı bir şey yapmak değil; DNSu2019in yıllardır süren kuralını, modern dünyanın ihtiyaçlarıyla barıştırmak.

n

Bu yazıda, u201cApex alan adında CNAME olur mu?u201d sorusunu tam kalbinden konuşalım. Cevabın kısa kısmı u201chyıru201d; ama hikâye burada bitmiyor. Çünkü devreye ALIAS/ANAME gibi sentetik kayıtlar ve Cloudflare CNAME Flattening gibi pratik çözümler giriyor. Mesela şöyle düşünün: Sizin tarafınızda A/AAAA girişi var gibi dursun ama perde arkasında CNAME hedefi takip edilsin; IP değişse bile siz sabit kalın. Gelin bunu gerçek dünyadan örneklerle, basit ama işlevsel bir dille birlikte çözelim.

nn

CNAME Neden Apexu2019te Olmaz? Kuralın Özünü Bir Cümlede

n

DNSu2019in temel şıklığı ve katı kuralı

n

DNSu2019in en sevdiğim yanı, basit kuralların üzerine örülü kocaman bir dünya olması. O basit kural şudur: Bir isim CNAME ise, onunla birlikte başka kayıt olamaz. Kökte, yani apexu201te ise NS ve SOA zaten olmak zorunda. E hal böyleyken apexu2019e CNAME koyduğunuz an, u201cCNAME tek başına olmalıu201d kuralı ile u201cApexu2019te NS/SOA zorunluduru201d kuralı çakışıyor. Sonuç belli: Apexu2019te CNAME yasak.

n

Bu yasağın kitap cümlesini görmek isterseniz, RFC 1034’teki kural yeterince açık anlatır. Elbette günlük hayatta kimse u201cBen RFC okuyayım da akşamları rahat uyuyayımu201d diye dolaşmıyor. Ama cebinizde şu kadar kalsın: u201cKök alan adı CNAME olamaz, çünkü apex diğer zorunlu kayıtlarla birlikte yaşamak zorunda.u201d

n

Gerçek hayatta bu neden can yakıyor?

n

SaaS kullanan herkes bilir; çoğu platform u201cBize CNAME ile gelu201d der. Çünkü IP değişebilir, yük dengeleme devreye girer, global trafik yönlendirme yapılır. Bu güzel ama, sizin kök alan adınızda bu esnekliği CNAME ile veremezsiniz. Genellikle ilk akla gelen çözüm, u201cwwwu2019yi CNAME yapayım, kökü wwwu2019ye 301 ile yönlendireyimu201d olur. Bu kabul gibi görünse de her proje u201cwwwu201d kullanmak istemez. Kimisi markası gereği çıplak alan adını sever, kimisi dağınık subdomain yapısından kaçmak ister.

n

Benim için en kritik nokta, değişimin hızlandığı günlerde böyle kısıtların insanı yavaşlatması. Bir gecede üst servis sağlayıcı IP değiştirir, siz u201cA kayıtlarınıu201d güncelleyene kadar trafik hırpalanır. İstediğimiz şey, kökte CNAME rahatlığı ama kuralları bozmadan.

nn

ALIAS ve ANAME: CNAME Konforunu Kural Bozmadan Vermek

n

Sentetik kayıt fikri neden akıllıca?

n

ALIAS ve ANAME, farklı sağlayıcıların benzer bakış açıları. Temelde yaptıkları şu: Siz panelde u201cCNAME gibiu201d bir hedef gösteriyorsunuz; yetkili DNS, o hedefin A/AAAA IPu2019lerini kendi tarafında çözüyor ve isteyen herkese normal A/AAAA gibi sunuyor. Böylece dışarıdan bakınca apexu2019inizde CNAME yok, kural bozulmuyor. Ama siz u201cCNAME esnekliğiniu201d alıyorsunuz. IP değişse bile, yetkili DNS tekrar çözüyor ve güncel IPu2019leri döndürüyor.

n

Bu yaklaşım bana, u201cYolda lastiği değiştirmeku201d gibi geliyor. Arabayı durdurmadan, akışı bozmadan sorun çözülüyor. Dezavantajı yok mu? Elbette sağlayıcı, sizin için ek bir çözümleme (resolve) yapıyor; bu da perde arkasında biraz daha iş, biraz daha bekleme penceresi demek. Ama modern DNS altyapıları bunu gayet sağlıklı yönetiyor.

n

Kimler sağlıyor, nasıl düşünmeli?

n

Birçok DNS sağlayıcı bu tür sentetik kayıtları destekliyor. Konseptin arkasındaki mantık benzer; ayrıntılar değişebilir. Amazon tarafında bu yaklaşımı anlamak için AWS Route 53’ün ALIAS kaydı anlatımı iyi bir rehberdir. Yıllar içinde gördüm ki işin püf noktası, sadece u201cbunu destekliyor mu?u201d demek değil; u201cNasıl cache ediyor, TTLu2019i nasıl yönetiyor, hedefteki değişikliği ne kadar hızlı yakalıyor?u201d gibi pratik soruları da sormak.

n

Eğer ekosisteminizde altyapıyı otomatik yönetiyorsanız, bu noktada otomasyon kilit role bürünüyor. Birkaç satır YAML ya da HCL ile DNS yaşam döngüsünü kontrol etmek, gece 03:00 alarmı yerine sabah kahvesiyle düzeltme yapabilmek demek. Bu arada, DNS ve sunucu kurulumlarını birlikte ele aldığım Terraform ile VPS ve DNS otomasyonu yazısında bu işin sahadaki karşılığını da örnekledim.

nn

Cloudflare CNAME Flattening: Kökte CNAME Hissi, A/AAAA Gerçeği

n

Flattening tam olarak ne yapıyor?

n

Cloudflareu2019ın u201cCNAME Flatteningu201d dediği şey, yetkili DNS sunucusunda CNAME hedefini çözüp, sonuçtaki A/AAAA kayıtlarını son kullanıcıya vermek. Dışarıdaki dünya, apexu2019te normal A/AAAA görür; ama kaynak, panelde gösterdiğiniz hedef hosttur. Böylece köke CNAME koymadan CNAME konforunu yaşarsınız. Mantık basit, etkisi büyük.

n

Detaylarını merak edenler, Cloudflare CNAME Flattening dokümantasyonu üzerinden resmi açıklamayı da inceleyebilir. Orada anlatılan şeyin sahadaki hissi şu: u201cHedef host değişti mi, Cloudflare onu yakalayıp yeni IPu2019leri yayar; sen apexu2019te kayıt taşımakla uğraşma.u201d

n

Turuncu bulut, gri bulut ve gerçekte dönen IP

n

Cloudflareu2019da iki mod var: Proxy açıkken turuncu bulut, kapalıyken gri bulut. Proxy açıksa son kullanıcı aslında Cloudflareu2019ın anycast IPu2019lerine gider; arka tarafta hedefinize istek forward edilir. Proxy kapalıysa, flattening hedefi çözüp gerçek A/AAAA döner. Yani u201cFlatteningu201d, hem proxylu hem proxiesiz senaryoda iş görür ama dönen IP setinin niteliği proxy durumuna göre değişir.

n

Bu ayrım önemli çünkü performans, güvenlik ve kayıtların u201cgizliliğiu201d açısından farklı dinamikler var. Proxylu mod, orijini saklayıp kenar güvenlik sağlar; proxiesiz mod, şeffaf ve yalın çalışır. Hangi yolu seçerseniz seçin, apex u201cCNAME gibi davranıru201d ama DNS dünyasıyla kavga etmez.

n

TTL ne oluyor, gecikme var mı?

n

Flattening, hedef kaydın TTLu2019ini bir ölçüde dikkate alır, ama bu ilişki bire bir değildir. Cloudflare ve benzeri sağlayıcılar, hedefi belirli aralıklarla çözer; sonuçlarını da kendi önbelleklerinde yönetir. Pratikte gördüğüm şu: Uygun bir TTL seçimi ve sağlıklı bir hedef altyapı ile gecikme endişe edilecek seviyede olmaz. Yine de değişiklik anlarında birkaç dakikalık u201cgeçiş penceresiu201d doğal bir durum.

n

Cloudflare üzerinde başka detaylar da var; örneğin WebSocket ya da gRPC gibi uzun soluklu bağlantılar kuruyorsanız, kenar ve kaynak arasındaki davranışı iyi tanımak gerekir. Bu konuda pratik notları derlediğim Cloudflare ile WebSocket ve gRPC yayını yazısını da bir kenara not edin; kökte flattening yapsanız bile uygulama katmanı trafiği, uzatmalı bağlantılar ve time-out ayarlarıyla şekillenir.

nn

Gerçek Dünya Senaryoları: u201cMesela Şöyle Düşününu201d Bölümü

n

SaaS u201cCNAME isteru201d ama siz u201cwwwu201d istemezsiniz

n

Bir e-ticaret altyapısına geçiyorsunuz, döküman u201cCNAME verinu201d diyor. Siz ise sadece ornek.com ile yaşamak istiyorsunuz. Burada üç yol var gibi durur: Klasik u201cwwwu2019ye CNAME, kökten wwwu2019ye HTTP 301u201d, ya da u201cALIAS/ANAMEu201d, ya da u201cCloudflare Flatteningu201d. Eğer marka kimliğiniz u201cwwwu201du2019süz bir adresi dayatıyorsa, apexu2019te sentetik çözümle gitmek gayet temiz bir yol. SaaS tarafı IP değiştirirse, sizin apex kaydınız güncel IPu2019leri zaten almaya devam eder.

n

u201cwwwu201d kullanmakta sakınca yok; hatta bazıları CDN tarafındaki kuralları daha rahat yönetir. Ama apex sevdası ağır basıyorsa, flattening tam olarak bu özgürlüğü veriyor. İlk kez kurarken bir u201c301 mi flattening mi?u201d tartışması yaşanır; burada aslında teknik doğruluktan çok marka tercihi, SEO alışkanlıkları ve yönlendirme politikanız belirleyici olur.

n

Çoklu bölge, değişken IP ve u201cSık değişen hedefu201d senaryosu

n

Bir üretim ortamında arka tarafta IPu2019ler değişebilir; özellikle çok bölgeli ya da otomatik ölçeklenen ortamlarda. CNAME rahatlığını apexu2019te istiyorsanız, ALIAS/ANAME veya flattening hedefteki değişimleri yakalar. u201cBu gece IP değişti, A kayıtlarını unuttuku201d kabusu yaşamazsınız. Üstelik tüm bunlar, kullanıcıya u201cA/AAAAu201d olarak görünür; yani kural ihlal etmeden konfor kazanırsınız.

n

SSL/TLS ve sertifika tarafı

n

Kök yönlendirmeyi çözmek tek başına yetmez; uçtaki sertifikalar da doğru olmalı. Hem ornek.com hem de www.ornek.com için sertifika kapsamınızı netleştirin. Tarayıcı uyumluluğu ve performans dengesini konuştuğum ECDSA + RSA ikili SSL ile uyumluluk ve hız yazısı, u201ckökte mi wwwu2019de mi?u201d gibi soruların ötesinde, sertifika seçiminde de düşünmenize yardımcı olur. Unutmayın, DNS kayıtlarını akıllıca kurgulamak kadar, sertifikayı doğru kesmek de kesinti riskini azaltır.

n

HSTS, yönlendirme ve SEO tarafı

n

HSTS kullanıyorsanız, u201ctime-to-first-secureu201d etkisini düşünün. Kökten wwwu2019ye yönlendiriyorsanız 301 kalıcı olsun, kanonik adresinizi tekleştirin. Flattening tercih ediyorsanız ve tek host üzerinden ilerleyecekseniz, kanonik etiketleri ve site haritalarını düzenli tutun. Teknik olarak hangisini seçtiğiniz değil, tutarlılıkla yürütmeniz arama motorlarında daha pürüzsüz bir sonuç verir.

n

E-posta, SPF/DMARC ve apex üzerindeki diğer kayıtlar

n

Güzel taraf şu: Flattening ve ALIAS gibi yöntemlerde dışarıya A/AAAA döndüğü için apexu2019te MX, TXT, SPF ve DMARC kayıtlarınızı normal şekilde tutabilirsiniz. u201cCNAME olursa diğer kayıtlar yaşayamazu201d kuralına takılmazsınız, çünkü aslında CNAME sunmuyoruz. Bu arada, e-postada doğrulama ve sınırları genişleten teknikleri seviyorsanız, ben u201cDNS limitleriyle medeni şekilde baş etmeu201d dendiğinde SPF Flattening ile 10 lookup duvarını aşma yaklaşımını çok pratik buluyorum; fikir olarak benzeşirler, biri e-posta tarafında, diğeri apex yönlendirmesinde nefes aldırır.

nn

İnce Ayar: DNSSEC, Sert Çevreler, ACME ve Yayılım

n

DNSSEC ile araları nasıl?

n

DNSSEC kapalı bir kutu değil ama beklenti ayarlamak şart. Flattening yaptığınızda, dönen kayıt A/AAAA olduğundan, imzalar da sizin alan adınızın zinciriyle gelir. Hedef hostnameu2019in kendi DNSSEC zincirini u201cdirektu201d taşımış olmazsınız; çünkü siz zaten yetkili sunucuda çözümleyip u201cyeni bir cevapu201d üretiyorsunuz. Yıllardır bu düzenle sorunsuz çalışan çok yapı gördüm; kritik olan, DNS sağlayıcınızın DNSSEC uygulamasının sağlam olması.

n

ACME doğrulama ve otomatik sertifika yenileme

n

Letu2019s Encrypt gibi ACME akışlarında HTTP-01 veya DNS-01 doğrulaması yaparsınız. Kökte flattening varsa, proxy açıksa bazı doğrulama endpointu2019lerinin u201cgörünürlüğüu201d etkilenebilir. Burada iki küçük kural işimi çok kolaylaştırıyor: Doğrulama sırasında proxyu2019yi gerekirse kısa süreli kapatmak ve mümkünse DNS-01 ile TXT doğrulaması tercih etmek. Böylece apex mi, www mi, hangi yol daha rahat, hepsini bir çırpıda geçersiniz.

n

TTL ve u201cGerçekten ne zaman yayılır?u201d sorusu

n

DNS bir söz. u201cŞu kadar süre bu cevaba güvenu201d der. Flattening ve ALIAS, hedefin TTLu2019ine bakarak ve kendi iç ritmiyle çözüme yeni IPu2019leri taşır. Bu yüzden değişiklik yaptığınız an ile herkesin yeni IPu2019yi gördüğü an arasında küçük bir pencere kalır. Bu pencereyi daraltmak için kritik geçişlerde TTLu2019leri önce düşürmek, kesimden sonra tekrar yükseltmek hâlâ altın kural.

n

Güvenlik duvarları, giden trafik ve u201cHedef hostnameu201d

n

Arka planda hedef hostnameu2019e giden trafiği kabul etmeyen kısıtlar varsa, u201cflattening yaptık, iş bittiu201d demeyin. Özellikle proxylu senaryolarda gerçek istemci IPu2019sini görmek istiyorsanız, bağlantı başlıklarını doğru yorumlayan uygulama katmanı ve ilgili firewall kuralları şart. u201cNeden geceleri kopuyor?u201d diye düşündüren gizli bir kural bazen tek satırlık bir ayardır.

n

Takip etmek, ölçmek ve akşamı huzurlu kapamak

n

Kritik bir geçişte ben asla sadece u201cDNS kaydını değiştirdiku201d diyerek iş bırakmıyorum. Sağlayıcının health check imkanlarını, kendi izleme panellerinizi, hatta bir iki bağımsız bölgeden yapılan curl denemelerini rutine ekleyin. Cloudflare gibi kenar platformlarında uzun süreli bağlantılar kuruyorsanız, yazının başında andığım WebSocket/gRPC notlarını tekrar gözden geçirin. Her şey yolundaysa zaten sessizlik en güzel işaret olur.

nn

Kapanış: Kökte CNAME Değil, CNAMEu2019in Hissi

n

Toparlayalım. u201cApex alan adında CNAME olur mu?u201d sorusunun kısa cevabı hayır. Ama günümüzün pratik çözümleri, bu u201chyıru201dı günlük hayatta bir şölene çeviriyor. ALIAS/ANAME ve Cloudflare CNAME Flattening, kökte CNAMEu2019in verdiği esnekliği kural bozmadan yaşatıyor. Hedef hostname değiştiğinde, siz panelde dolaşmadan güncel IPu2019lere kavuşuyorsunuz. MX, TXT, SPF, DMARC gibi apex kayıtlarınız da huzur içinde yerinde kalıyor.

n

Ne yapalım peki? Şöyle küçük bir akış aklımda hep çalışır: Marka tercihlerinizi düşünün, u201cwwwu201d mi yoksa çıplak alan mı? CDN/proxy ihtiyacınızı tartın; uzun soluklu bağlantılarınız ve güvenlik ayarlarınız net mi? Sonra, DNS sağlayıcınızın sunduğu seçeneklere bakın; flattening/ALIAS hangi detaylarla geliyor? Geçişi planlarken TTLu2019i bir tık düşürün, doğrulamaları yapın, izlemeyi açın. Eğer işin uygulama tarafında TLS dünyasıyla da ilgileniyorsanız, ikili SSL ile uyumluluk ve hız dengesini konuştuğumuz notlar aklınızda bulunsun. İlham veriyorsa, u201cDNS ile altyapıyı birlikte taşımaku201d fikrini de Terraform otomasyon akışı ile somutlaştırın. Umarım bu yazı, apexu2019te CNAME arayanların gönlüne su serpmiştir. Sorularınız olursa, her zaman beklerim; bir sonraki yazıda görüşmek üzere.

“,
“focus_keyword”: “Apex alan adında CNAME”,
“meta_description”: “Apex alan adında CNAME olur mu? ALIAS/ANAME ve Cloudflare CNAME Flattening ile kök DNS yönlendirmeyi, TTL ve e-posta kayıtlarıyla birlikte net ve pratik anlatım.”,
“faqs”: [
{
“question”: “Apex alan adında CNAME gerçekten yasak mı?”,
“answer”: “Evet. Kökte NS ve SOA zorunludur ve CNAME tek başına yaşamak ister. Bu yüzden apex’te CNAME kullanamazsın. Pratikte çözüm, ALIAS/ANAME ya da Cloudflare CNAME Flattening gibi yöntemlerdir; dışarıya A/AAAA döndükleri için kuralı bozmazlar.”
},
{
“question”: “Flattening veya ALIAS kullanırsam e-posta kayıtlarım etkilenir mi?”,
“answer”: “Hayır. Dışarıya A/AAAA döndüğü için apex’te MX, TXT, SPF ve DMARC kayıtlarını normal şekilde tutabilirsin. Zaten asıl dert, CNAME’in yanında başka kayıtların olamamasıydı; flattening/ALIAS bunu aşar.”
},
{
“question”: “Kök alanı www’ye yönlendirmek mi, yoksa flattening kullanmak mı daha iyi?”,
“answer”: “Bu daha çok tercih meselesi. Marka dili, SEO alışkanlıkları ve altyapı mimarisi belirleyici olur. www’ye 301 verip CNAME’i www’de tutmak gayet temizdir; ama çıplak domaine âşıksan flattening/ALIAS ile kökte esnekliği alırsın. Her iki yaklaşımda da tutarlılık ve doğru TLS/izleme ayarları işin anahtarıdır.”
}
]
}