DNS Trafik Yönlendirmesi Hangi Sorunu Çözer?
Bir uygulama farklı bölgelerde hizmet verdiğinde hangi istemcinin hangi hedefe ulaşacağı önem kazanır. Coğrafi politikalar konum eşlemesini, ağırlıklı politikalar hedef seçiminin dağılımını, split-horizon ise iç ve dış DNS görünümlerini düzenler. Bu yöntemler uygulamanın kapasitesini veya veri tutarlılığını kendiliğinden sağlamaz. Doğru seçim için kararın DNS yanıtında mı yoksa HTTP isteği sırasında mı verildiğini ayırmak gerekir.
Bu rehber Cloudflare Load Balancing ve Amazon Route 53 üzerinden coğrafi, ağırlıklı ve split-horizon tasarımları karşılaştırır. Cloudflare’ın DNS-only ve proxied modları aynı katmanda çalışmaz; standart bir DNS kaydı eklemek bütün Load Balancing özelliklerini açmaz. Önce kullanılacak ürünü, çalışma modunu ve planın sunduğu politika seçeneklerini belirleyin; ardından hedefler, sağlık kontrolleri ve geri dönüş koşullarını tanımlayın.
DNS Yanıtı, HTTP İsteği ve Önbellek
Çözümleyiciler ve TTL
Route 53 ve Cloudflare DNS-only yük dengelemesinde yetkili sunucu sorguya bir adres yanıtı seçer. Recursive çözümleyici bu yanıtı TTL süresince önbellekte tutabilir ve çok sayıda istemciye aynı cevabı verebilir. TTL, yeni bir kayıt değerinin mevcut önbelleklere anında uygulanmasını sağlamaz. Cloudflare proxied yük dengelemesinde istemciye Cloudflare adresleri döner; origin seçimi HTTP/HTTPS katmanında yapılır ve aynı DNS TTL açıklaması doğrudan bu seçimin zamanlayıcısı sayılamaz.
Ağırlıklar neden tam kullanıcı yüzdesi değildir?
DNS düzeyindeki ağırlıklar, yetkili sunucuya ulaşan sorgular için yanıt seçimini etkiler; yüzde 10 ağırlık tam yüzde 10 kullanıcı veya uygulama isteği demek değildir. Ortak resolver önbelleği, istemci etkinliği ve açık bağlantılar dağılımı değiştirebilir. Cloudflare proxied moddaki istek yönlendirmesi ise farklıdır; oturum bağlılığı ve seçilen politika da sonucu etkiler. Gerçek sürüm trafiğini DNS sorgu sayısıyla değil uygulama ölçümleriyle birlikte değerlendirin.
Coğrafi Yönlendirme ve Konum Sinyalleri
Geolocation, geoproximity ve gecikme seçimi
Route 53 geolocation, sorguların tahmini konumlarını tanımlanmış ülke, kıta veya desteklenen alt bölge kayıtlarıyla eşler. Geoproximity, kaynak konumları ve bias değerleriyle coğrafi kapsama alanlarını değiştirir; latency-based routing ayrı bir politikadır. Cloudflare geo steering, konumlara havuzlar bağlar ve havuz sırasını failover için kullanır. Bu seçeneklerin hiçbiri tek başına her kullanıcıyı fiziksel olarak en yakın, en düşük gecikmeli veya sağlıklı sunucuya ulaştırma garantisi değildir.
ECS ve Cloudflare çalışma modu
DNS-only seçimde destekleniyorsa ECS istemci ağ öneki, aksi durumda recursive çözümleyiciye ait konum sinyali kullanılabilir. Cloudflare proxied mod, çözümleyicinin konumu yerine kullanıcı isteğiyle ilişkili veri merkezini esas alır. VPN ve mobil ağlar görünür yolu değiştirebilir. Farklı bölgelerdeki bir bulut sunucu, mobil bağlantı ve kurumsal ağ ile denemeler yapın. geo steering anlatımını ve yönlendirme politikaları sayfasını okurken DNS-only ile proxy katmanını ayrı değerlendirin.
Ağırlıklı Yönlendirme ile Kademeli Dağıtım
Canary ve mavi-yeşil geçişler
Örnek bir dağıtımda eski sürüme 95, yeni sürüme 5 göreli ağırlık atanabilir. Bu değerler ölçülmüş bir kullanıcı oranı değil, açıklayıcı bir başlangıç örneğidir. Yeni sürümün hata oranını, gecikmesini, kapasitesini ve veri uyumluluğunu gözleyerek ilerleyin. DNS ağırlığını geri almak önbelleğe alınmış yanıtları veya açık bağlantıları sonlandırmaz. Kesin kullanıcı grupları gerekiyorsa uygulama ya da uygun proxy katmanında sürüm seçimi planlayın.
Route 53 kayıtları ve Cloudflare ağırlıkları
Route 53 weighted grubunda kayıtların adı ve türü aynı, set identifier değerleri farklı olmalıdır; göreli ağırlıkları birlikte değerlendirilir. Cloudflare’da havuz ağırlıkları Random global steering seçeneğine bağlıdır; seçilmiş havuzun içindeki endpoint ağırlıkları ayrı düzeydedir. Geo steering’de aynı konuma bağlı havuzlar sırayla failover için kullanılır; bu listeye genel bir havuz yüzdesi anlamı yüklemeyin. Proxy modu ve session affinity de gerçek dağılımı etkiler.
Sağlık kontrolünün sınırları
Sağlık kontrolü, seçilen ürünün gerçekten izlediği hedef ve eşiklere bağlıdır. Route 53 Alias için Evaluate Target Health ayrı bir ayardır; bütün uygun kayıtlar sağlıksız olduğunda Route 53 bazı durumlarda yine bu gruptan yanıt döndürür. Cloudflare’ın fallback havuzu da sağlıklı bir alternatifin varlığını garanti etmez. Kontrol yolunu uygulamanın hizmet verebilmesini temsil edecek biçimde tasarlayın; ağır bağımlılık testleri veya aşırı hassas eşikler zincirleme arızayı ve sık hedef değişimini tetiklememelidir.
Split-Horizon: İç ve Dış DNS Görünümleri
Özel bölge ve istemcinin çözümleme yolu
Split-horizon aynı isim için farklı çözümleme bağlamlarında farklı kayıtlar sunar. Route 53 private hosted zone ilişkili VPC’lere hizmet verir; gerekli VPC DNS ayarları açık olmalı ve istemci bu görünümü kullanacak çözümleme yoluna ulaşmalıdır. Özel bölge otomatik olarak özel IP üretmez, yapılandırdığınız kayıtları döndürür. private hosted zone sayfası bu kapsamı açıklar. Cloudflare’da iç adlar için özel resolver yönlendirmesi ve istemci/ağ yapılandırması gerekir; yalnızca public DNS veya bir tünel yeterli değildir.
Özel görünümde eksik kayıtlar ve erişim kontrolü
Aynı isimde public ve private zone varsa, ilişkili VPC’de eşleşen özel bölgedeki eksik kayıt için public zone’a otomatik dönüş beklemeyin. Gerekli iç kayıtları açıkça tanımlayın ve iki görünümün amaçlanan farklarını birlikte yönetin. VPN bağlantısı da tek başına doğru DNS sunucusunu seçtirmez. DNS yanıtını değiştirmek erişim yetkisi vermez veya engellemez; ağ kuralları, kimlik doğrulama ve uygulama izinleri ayrı kontrollerdir.
Kendi yetkili DNS sunucularınızı işletiyorsanız kendi ad sunucunuzu ve glue record’larınızı kurmak rehberi delegasyon ve gerektiğinde glue kayıtlarını anlamaya yardımcı olur. Bu, Cloudflare veya Route 53 yönetilen yönlendirme özelliklerini kullanmanın genel önkoşulu değildir. Markalı ad sunucusu da bir iç DNS görünümü oluşturmaz. Split-horizon için asıl konu istemcinin hangi resolver yolunu kullanacağı ve o bağlamda hangi bölgenin yanıt vereceğidir.
Coğrafi ve Ağırlıklı Politikaları Birleştirmek
Bölge seçimi ve bölge içi dağıtım
Varsayımsal bir uygulamada Frankfurt, İstanbul ve Virginia hedefleri olsun. Önce hangi konumun hangi bölgeye gideceğini, ardından o bölgedeki sürüm dağılımını tanımlayın. Route 53’te aynı kayıt grubuna iki politika atamak yerine uygun Alias ve alt kayıt gruplarından oluşan karar ağacı kurulur. Cloudflare’da geo havuz seçimi ile seçilen havuzdaki endpoint ağırlıkları farklı katmanlardır; daha karmaşık birleşimler için desteklenen pool-set politikasını kontrol edin. İç DNS görünümü bu ağaca erişim güvenliği veya bağımsız failover eklemez.
TTL ve geri dönüş planı
Değiştirilebilir DNS TTL değerini geçişten önce düşürün; düşük değer yetkili sunucularda yayımlandıktan sonra eski TTL’nin dolmasına zaman tanıyın. Cloudflare proxied kayıtlarının DNS TTL’si ile origin yönlendirmesini birbirine karıştırmayın. Önceki yapılandırmayı, geri dönüş koşulunu ve eski hedefin ne kadar hazır tutulacağını kaydedin. Geçiş sonrası TTL’yi sorgu yükü, maliyet ve değişiklik gereksinimine göre seçin; bütün kurulumlara uygun tek bir süre yoktur.
IPv4 ve IPv6 yollarını ayrı doğrulamak
A ve AAAA kayıtları yayınlıyorsanız her iki adres ailesinde hedefin gerçekten erişilebilir olduğunu, TLS’nin ve sağlık kontrollerinin doğru çalıştığını test edin. AAAA kaydı rehberi adres kaydının rolünü ele alır. IPv6‑only bir sunucu üzerinde NAT64/DNS64 köprüsü kurma ise IPv6 istemcilerin IPv4 hedeflere çıkışına yönelik bir konudur; NAT64/DNS64 tek başına IPv4 istemcilerin IPv6-only sitenize gelmesini sağlamaz. Böyle bir giriş için IPv4 erişimi olan uygun proxy veya başka bir geçiş tasarımı gerekir.
CDN, origin ve uygulama katmanı
Bir CDN kullanıldığında istemci–kenar yolu ile kenar–origin yolu farklıdır. Kenarda önbellekten sunulan yanıt origin’e gitmeyebilir; dinamik isteklerde origin yolu ve uygulama süresi önem kazanır. Coğrafi origin seçimi, kullanıcının hangi CDN kenarına ulaştığını tek başına belirlemez. HTTP/2 ve HTTP/3’ü uçtan uca etkinleştirme rehberimiz protokol tarafını tamamlar; DNS politikası TLS, HTTP/2 veya HTTP/3’ü kendiliğinden etkinleştirmez.
Test ve Sorun Giderme
DNS sonucu ile gerçek isteği karşılaştırmak
Önce yetkili DNS yanıtını ve gerçek politika yapılandırmasını inceleyin, sonra farklı recursive çözümleyicilerdeki önbellek görünümünü karşılaştırın. Cloudflare proxied modda origin seçimini yalnızca dig çıktısından anlayamazsınız; yük dengeleme ve uygulama günlükleri gerekir. HTTP durumunu, TLS adını, önbellek başlıklarını ve sunucu tarafındaki bölge bilgisini kontrol edin. Eski içerik CDN önbelleğinden, yanlış hedef resolver önbelleğinden veya uygulama yönlendirmesinden kaynaklanabilir.
Politika ve fallback davranışını belgelemek
geo steering bölümü konumların havuzlara eşlenmesini; Route 53 yönlendirme politikaları ise AWS politika türlerini açıklar. Route 53 geolocation için tanımsız veya konumu bulunamayan sorguları kapsayan default kayıt planlayın; yoksa bu sorgulara yanıt verilmeyebilir. Sağlık kontrollü coğrafi geçişte daha geniş coğrafya/default seçimini de yapılandırın. Split-horizon DNS kavramı farklı DNS görünümlerini anlatır; ürünün resolver ve bölge eşleşme kuralları ayrıca incelenmelidir.
Yaygın Yapılandırma Hataları
Negatif DNS önbelleği
NXDOMAIN veya NODATA gibi olumsuz yanıtlar da önbelleğe alınabilir. RFC 2308’de negatif önbellek süresi, yanıttaki SOA TTL’si ile SOA MINIMUM değerinden düşük olanına dayanır; yalnızca A kaydının TTL’sine bakmak yeterli değildir. Kaydı silip yeniden eklemek eski olumsuz yanıtı temizlemez. Başka bir ad kullanmak ancak istemciler gerçekten o adı kullanacak şekilde değiştirilebiliyorsa işe yarar; eski adın önbelleğini düzeltmiş olmaz.
Hedef adları, oturumlar ve veri uyumu
app-eu-blue.example.com ve app-eu-green.example.com gibi anlamlı hedef adları yapılandırmayı okunabilir kılar; tek başına sürüm yalıtımı sağlamaz. DNS yeniden çözülürken istemci farklı bir hedefe gidebilir. Oturum bağlılığı gerekiyorsa bunu destekleyen yönlendirme katmanını kullanın veya uygun oturum paylaşımını tasarlayın; sırf ağırlıklı geçiş yapılıyor diye stickiness’i kapatmayın. Eski ve yeni sürümün veri şeması ve işlem uyumu da hazır olmalıdır.
Yetkili bölgeyi ve sorumluluğu doğrulamak
Değişiklik doğru yetkili bölgede yapılmalıdır. Kendi DNS altyapınız varsa özel ad sunucusu ve glue record kurulumu delegasyon sorunlarını araştırmak için ilgili olabilir; yönetilen Cloudflare/Route 53 kullanımında ayrıca özel ad sunucusu kurmanız gerekmez. Hangi ekibin public kayıtları, private görünümü, sağlık kontrollerini ve uygulama dağıtımını yönettiğini kaydedin. Doğru DNS yanıtı, sağlıklı uygulama veya güvenli iç ağ erişimiyle aynı kontrol değildir.
Yönlendirmeyi Ölçülebilir Bir Sürece Dönüştürmek
Coğrafi politika bir konum eşlemesi, ağırlıklar bir seçim dağılımı, split-horizon ise çözümleme görünümü sağlar. Önce DNS-only ile proxy modunu ayırın; sonra sağlık kontrolü, fallback, oturum ve kapasite koşullarını tanımlayın. Yüzdeleri uygulama ölçümleriyle doğrulayın ve bütün hedeflerin sağlıksız olduğu durumu da test edin. Bu yöntemler performans ve geçiş yönetimine yardımcı olabilir, ancak kesintisizlik veya daha iyi SEO sıralaması vaat etmez.
Küçük ve izlenebilir bir değişiklikle başlayın. DNS yanıtlarını, gerçek istek dağılımını, bölgesel gecikmeyi ve hataları ayrı ölçün; ilgili önbellek sürelerini bekleyin. Geri dönüş planının da önbellek ve açık bağlantı sınırları vardır. Son durumda kullanılmayan kayıtları, sağlık kontrollerini, plan maliyetlerini ve iç/dış görünüm farklarını gözden geçirerek yapılandırmayı belgelendirin.
