ALIAS ve ANAME Kaydı Nedir? Apex Domain Sorunu Nasıl Çözülür?
example.com'u bir load balancer hostname'ine yönlendirmeye çalıştığınızda standart DNS neden buna izin vermez? Cevap zone apex kısıtında saklıdır: RFC 1034, bir isim için CNAME tanımlıysa başka kayıt türü bulunamayacağını söyler. Kök domain üzerinde SOA ve NS kayıtları her zaman zorunludur; dolayısıyla example.com üzerine CNAME eklemek bu kayıtlarla doğrudan çakışır ve standart DNS buna izin vermez. www.example.com için CNAME çalışmasına rağmen kök domain için çalışmamasının sebebi budur.
Vercel, Netlify, Heroku, AWS Elastic Load Balancer ve benzer platformlar, hostname biçiminde hedef sağlar — sabit bir IP adresi değil. Subdomain yönlendirmeleri için bu sorunsuz çalışır; ancak kök domaini bu hostname'e bağlamak istediğinizde standart CNAME yolu kapanır. A kaydıyla IP'yi doğrudan yazmak geçici bir çözümdür, ancak platform IP'yi değiştirdiğinde kayıt güncel kalmaz.
ALIAS ve ANAME, bu boşluğu kapatmak için farklı DNS sağlayıcılarının geliştirdiği, standart dışı ama yaygın biçimde desteklenen mekanizmalardır. Her ikisi de aynı amaca hizmet eder: resolver'a A kaydı gibi görünen bir yanıt döndürürken arka planda hostname'i gerçek zamanlı çözümler. İsim farklılığı implementasyon farkından değil, sağlayıcının tercihinden kaynaklanır. RFC'lerde tanımlı resmi bir tip değildir.
Zone apex kısıtı: kök domainde CNAME neden yasak
DNS zone'unun kök noktasına zone apex denir. example.com ile yönettiğiniz bir zone için apex, tam olarak example.com.'dur. Bu noktada SOA (Start of Authority) ve NS kayıtları her zaman bulunmak zorundadır; zone bu kayıtlar olmadan geçerli kabul edilmez.
RFC 1034'e göre bir isim için CNAME kaydı varsa, o isim için başka hiçbir kayıt türü olamaz. Bu kural mutlak biçimde uygulanır. example.com. için CNAME eklemek, SOA ve NS kaydını aynı anda tutmayı imkânsız kılar; RFC uyumlu DNS sunucuları bu çakışmayı reddeder ya da tanımsız davranış üretir.
www.example.com. 3600 IN CNAME example.com.
blog.example.com. 3600 IN CNAME platform.hosting.net.
example.com. 3600 IN CNAME myapp.loadbalancer.net.
; SOA ve NS ile çakışır — standart DNS'de geçersiz
Bu kısıt, zone bütünlüğünü korumak için konulmuştur ve ortadan kaldırılmaz. Sorunun çözümü CNAME'in apex'te çalışmasını sağlamak değil, CNAME olmadan aynı davranışı üretmektir. ALIAS ve ANAME tam olarak bunu yapar.
ALIAS ve ANAME'nin çalışma mekanizması
ALIAS veya ANAME kaydı eklendiğinde DNS sunucusu, gelen A veya AAAA sorgusu için hedef hostname'i dahili olarak çözümler ve sonucu doğrudan IP olarak döndürür. Resolver bu sürecin farkında değildir; aldığı yanıt sıradan bir A kaydından ayırt edilemez.
; Zone dosyasında (sağlayıcıya göre sözdizimi farklılık gösterir):
example.com. 3600 IN ALIAS myapp.loadbalancer.net.
; Resolver'ın gördüğü (sağlayıcının döndürdüğü):
example.com. 60 IN A 203.0.113.42
Çözümleme sırası şöyle işler: kullanıcı example.com için A kaydı sorguladığında DNS sunucusu ALIAS hedefi olan myapp.loadbalancer.net'i dahili olarak sorgular, dönen IP'yi alır ve bu IP'yi example.com'un A kaydı yanıtı olarak iletir. CNAME zinciri hiçbir zaman dışarıya çıkmaz. Bu, apex kısıtını aşar çünkü resolver'a dönen yanıt RFC açısından temiz bir A kaydıdır.
Hedef hostname'in IP'si değiştiğinde ALIAS/ANAME bunu otomatik takip eder. Dinamik cloud altyapısında — IP'nin değiştiği load balancer, CDN veya platform ortamlarında — A kaydını elle güncellemek yerine ALIAS hedefi sabit kalır ve çözümleme her zaman güncel IP'yi döndürür. CNAME ve A kaydı arasındaki temel fark burada da kendini gösterir: statik IP için A kaydı yeterlidir, değişken hedef için CNAME benzeri bir mekanizma gerekir.
Sağlayıcı implementasyonları: Cloudflare, Route 53 ve ötesi
ALIAS/ANAME standart bir DNS kayıt türü olmadığından her sağlayıcı kendi adını, davranışını ve kısıtlarını belirler. Kullanmadan önce sağlayıcınızın implementasyonunu anlamak, ileride karşılaşılabilecek kısıtların önüne geçer.
Cloudflare — CNAME Flattening: Cloudflare DNS'te apex domain üzerine doğrudan CNAME kaydı girebilirsiniz; Cloudflare bunu otomatik olarak flatten eder. Resolver'a dönen yanıt, hedef hostname'den elde edilen IP adresidir. Bu davranış tüm zone'larda varsayılan olarak etkindir ve ek yapılandırma gerektirmez. Proxied mod seçildiğinde flatten işlemi Cloudflare ağı üzerinden yürütülür; DNS Only modda ise kaynak IP doğrudan döner.
AWS Route 53 — Alias record: Route 53'te "Alias record" adıyla sunulan bu özellik yalnızca AWS kaynaklarını hedefleyebilir: Elastic Load Balancer, CloudFront dağıtımı, S3 static website endpoint, API Gateway ve aynı hosted zone içindeki başka Route 53 kayıtları. Harici bir hostname — başka bir CDN veya platform — Route 53 Alias hedefi olamaz. Alias kaydı için DNS sorgu ücreti uygulanmaz; yoğun trafik altında bu maliyet avantajı belirgin hale gelebilir.
{
"Name": "example.com.",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "my-lb-1234567890.us-east-1.elb.amazonaws.com.",
"EvaluateTargetHealth": true
}
}
Diğer sağlayıcılar: DNSimple ve NS1, ALIAS adıyla sunar ve harici hostname hedeflerini kabul eder. PowerDNS, ANAME kaydını destekler. Azure DNS'in kendi Alias mekanizması vardır, yalnızca Azure kaynaklarına işaret edebilir. Standart BIND veya NSD kurulumlarında ALIAS/ANAME varsayılan olarak bulunmaz; üçüncü taraf modül veya yamalı sürümler gerektirir. Managed DNS sağlayıcılarına geçişin bu kısıtlamayı çözmek için de tercih edilmesinin bir nedeni budur.
ALIAS/ANAME'nin gerekli olduğu ve gereksiz kaldığı durumlar
ALIAS/ANAME değer ürettiği durumlar belirgindir: kök domaini dinamik IP kullanan bir platforma yönlendirme, load balancer veya CDN hostname'ine apex bağlama ve IP'nin değişeceği cloud ortamlarında statik A kaydından kaçınma. Vercel, Netlify ve benzeri platformların domain bağlama adımlarına bakıldığında, kök domain için ALIAS veya sağlayıcıya özgü eşdeğerinin açıkça istendiği görülür.
Gereksiz kaldığı durumlar da aynı derecede nettir. Kök domain sabit bir IP adresine — dedicated sunucu, VPS — işaret edecekse doğrudan A kaydı kullanmak hem daha basit hem daha güvenilirdir; ALIAS katmanı ek karmaşıklık getirir, avantaj sağlamaz. Sadece www alt alanını yönlendiriyorsanız apex kısıtı devreye girmez; subdomain için CNAME standart biçimde çalışır. example.com'dan www.example.com'a HTTP 301 yönlendirmesi de DNS meselesine değil, web sunucusu veya proxy yapılandırmasına aittir.
Sağlayıcı değiştirirken ALIAS/ANAME davranışının da değişeceğini göz önünde bulundurun. Cloudflare'da tanımlı bir CNAME Flattening yapılandırması, zone'u Route 53'e taşıdığınızda Alias record olarak otomatik dönüşmez. Zone transferi sırasında apex yönlendirmesini yeni sağlayıcının mekanizmasına göre ayrıca yapılandırmak gerekir; aksi hâlde kök domain yanıtsız kalabilir.
TTL davranışı, DNSSEC uyumluluğu ve operasyonel farklar
ALIAS/ANAME'nin standart dışı yapısı birkaç operasyonel fark üretir. Bunları bilmek, özellikle DNS kayıt türlerinin genel davranışını bilen yöneticiler için beklentileri düzeltir.
TTL kontrolü sağlayıcıdan sağlayıcıya farklılık gösterir. Çoğu managed DNS sağlayıcısı ALIAS kaydı için TTL ayarlamanıza izin verir; ancak arka planda dahili çözümleme döngüsünün kendi TTL'si vardır. ALIAS hedefinin TTL'si zone kaydındaki değerden daha kısa olabilir ve bu durumda IP değişimlerinin resolver önbelleklerine yansıma hızı tahmin edilenden farklı çıkabilir. Cloudflare Proxied modda kaynak IP gizlendiğinden bu durum pratikte görünmez; DNS Only modda ise dikkat gerektirir.
DNSSEC uyumluluğu daha karmaşık bir konudur. ALIAS mekanizması gerçek zamanlı çözümleme yaptığından, döndürülen A kaydı için DNSSEC imzası (RRSIG) standart zone imzalama sürecinin dışında oluşur. Cloudflare gibi sağlayıcılar bu durumu kendi altyapısında yönetir ve DNSSEC etkinken ALIAS'ın çalışmasını sağlar. Kendi nameserver'ınızı işletiyorsanız ve DNSSEC kullanıyorsanız, ALIAS benzeri bir implementasyonun imzalama ile nasıl bütünleştiğini sağlayıcı dokümantasyonundan ayrıca teyit etmeniz gerekir.
Hedef çözümleme sıklığı da implementasyona göre farklılaşır. Bazı sağlayıcılar ALIAS hedefini sürekli izler ve IP değiştiğinde hemen günceller; bazıları hedef hostname'in TTL'sini doldurur ve o süre geçmeden yeniden sorgulamaz. Dakikalar içinde IP değiştirebilen bir platform kullanıyorsanız, sağlayıcınızın güncelleme politikasını anlamak yayılma gecikmesi beklentinizi şekillendirir.
ALIAS ve ANAME, DNS standardlarının yıllardır çözmediği pratik bir ihtiyacı karşılar. Apex domain üzerine CNAME benzeri davranış kazandırmak için geliştirilmiş bu mekanizmalar, managed DNS ekosisteminde artık olağan bir özellik hâline gelmiştir. Hangi sağlayıcıyı kullandığınıza ve hedefin ne olduğuna — AWS kaynağı mı, harici platform mı — göre doğru implementasyonu seçmek, işlemin ilk adımıdır.
Kök domaini sabit IP'ye bağlarken A kaydı, dinamik hostname'e bağlarken ALIAS/ANAME yeterlidir; wildcard DNS'te olduğu gibi burada da mekanizmanın sınırlarını bilmek, zone dosyasında öngörülemeyen durumların önüne geçer. Sağlayıcı değiştirme planınız varsa apex yönlendirme yapılandırmasını geçiş kontrol listesinin başına almak, en sık gözden kaçan adımları ortadan kaldırır.