Gelişmiş DNS Yönlendirme Nasıl Akıllanır? Cloudflare/Route 53 ile Coğrafi, Ağırlıklı ve Split‑Horizon Üzerine Sıcacık Bir Yolculuk

Ofiste Başlayan Küçük Bir DNS Macerası

Hiç başınıza geldi mi? Hani her şeyin yolunda olduğunu düşündüğünüz bir sabahta, kampanya sayfası bir anda ateş alır ve kuzeyde yaşayan kullanıcılarınız ışık hızında açarken, güneydeki ziyaretçiler telefonlarının ekranında dönüp duran bir yükleme simgesine bakakalır. O gün, ofiste kahvemi alıp loglara daldığımda, “Bunu DNS ile tatlı tatlı yönlendirmeden nasıl çözeriz?” diye düşündüm. Çünkü gelişmiş DNS yönlendirme sadece kayıt eklemek değil; kullanıcıyı doğru yere, doğru anda ve doğru ağırlıkla göndermek demek.

Bu yazıda, Cloudflare ve Route 53 üzerinde coğrafi ve ağırlıklı (weighted) DNS senaryolarını, üzerine bir de split‑horizon yaklaşımını ekleyerek sindire sindire konuşacağız. Mesela şöyle düşünün: Trafiğin bir kısmını yeni versiyona nazikçe taşımak, Avrupa’yı Frankfurt’a, Ortadoğu’yu İstanbul’a akıtmak, şirket içindeyken başka, dışarıdayken bambaşka adres görmek. Hepsi mümkün. Yolda küçük püf noktaları da paylaşacağım. Biraz konu dışına dalacağız, ama her dönüşte cebimiz daha dolu olacak.

DNS’in Sahne Arkası: Neden Bazen Beklediğinizi Alamazsınız?

Resolver’lar, TTL’ler ve o meşhur önbellek

DNS, sahnenin arkasında duran sessiz bir kahraman. Bir sorgu yola çıktığında, yol üstünde duran çözümleyiciler onu ellerinden geldiğince hızlandırır. Bunun bedeli de önbellek. Koyduğunuz bir kaydı yaymak bazen saniyeler sürer, bazen beklenmedik şekilde dakikalara uzar. Mesela bir A kaydını değiştirdiniz, fakat bazı kullanıcılarda eski IP çalışmaya devam ediyor. Suç çoğu zaman TTL ayarında. Çok uzun TTL rahat ettirir, ama ani değişikliklerde sizi yavaşlatır. Çok kısa TTL ise herkese sık sık “yeni ne var?” sorusunu sorar, bu da gereksiz gürültü ve maliyet demek.

Yüzdeler neden birebir kullanıcıya yansımaz?

“Yüzde 10’u yeni ortama alalım” dediğinizde, aslında çözümleyici seviyesinde bir dağılım yapmış olursunuz. Yani paylaştırma çoğu zaman kullanıcı değil, resolver bazında. Şirket ağında tek bir resolver varsa, o ofisin tamamı aynı cevabı alabilir. Bu da bazen şaşırtıcı sonuçlar doğurur. Yüzde 10 beklerken, belli bir lokasyonda yüzde 0 veya yüzde 100 görebilirsiniz. Bu doğaldır. Önemli olan, bunun üzerine gözlem yapıp ayarları nazikçe çekip çevirmek.

Coğrafi DNS: “Nereden Geliyorsun?” Sorusu ve Nazik Yönlendirme

Ülke, bölge, şehir… Ne kadar ince ayar?

Coğrafi yönlendirme, kabaca “bu sorgu nereden geliyor” diye bakıp en yakın veya en uygun hedefi döndürmek. Cloudflare’da bunu geo steering mantığıyla, Route 53’te ise geolocation veya geoproximity politikalarıyla düşünebilirsiniz. Bir kampanya döneminde Avrupa trafiğini Frankfurt’a, Kuzey Amerika’yı ise bir Doğu bir Batı kıyısında nazikçe dengeleyerek göndermek sahada çok işimi gördü. Mobil operatörlerin ve VPN’lerin coğrafi işaretleri ara sıra şaşırtabildiğini de unutmayın. Bu yüzden kurgu ne kadar akıllı olursa olsun, her zaman küçük bir pay emniyet bırakmak iyi geliyor.

EDNS ipucu ve test ederken dikkat

Bazı çözümleyiciler, istemcinin gerçek lokasyonuna dair küçük ipuçları taşır. Buna teknik tarafta “istemcinin konum ipucu” gibi düşünebilirsiniz. Test ederken farklı çıkar noktasına sahip resolver’lar üzerinden sorgu yapmak işe yarar. Tek bir internet bağlantısından bakıp “tamamdır” demek, kendimizi kandırmak olur. Birkaç farklı şehirden, bir iki bulut sunucudan ve mümkünse mobil ağdan bakınca resim tamamlanır. Bu açıdan Cloudflare’ın geo steering anlatımı ile Route 53’ün yönlendirme politikaları sayfasını sakin bir akşam okumak, kavramları yerine oturtuyor.

Ağırlıklı (Weighted) DNS: Trafiği Yumuşacık Bölmenin En Tatlı Yolu

Canary, mavi‑yeşil ve nazik geçişler

Yeni bir sürüme yüzde 5, sonra 10, sonra 25 derken nazikçe geçmek istiyorsanız, ağırlıklı DNS nefis bir yöntem. Mesela şöyle düşünün: Üretimde çalışan bir uygulamanız var. Yeni sürümü yan tarafta hazır ettiniz. Önce küçük bir kitleyi yeni tarafa alıyorsunuz. Loglar temizse, hatalar sakinse, değeri artırıyorsunuz. Bir sorun çıkarsa ağırlığı eski sürüme geri kaydırmak bir tık kadar yakın. Bu yaklaşım, geceyarısı tam kesinti yerine, gündüz saatlerinde yumuşak bir akışla ilerlemeyi sağlıyor.

Gerçek yüzde ile hissedilen yüzde arasındaki fark

Burada en sık duyduğum soru şu: “Yüzde 10 dedim, ama ekip tamamı yeni sürümü görüyor.” Az önce konuştuğumuz gibi, bu çoğu zaman çözümleyici mercek etkisi. Ofiste tek DNS çıkışı varsa, oradaki herkes aynı cevabı alabilir. Çözüm, test ve ölçümü farklı resolver’lar üzerinden yapmak ve kararları aceleye getirmemek. Ayrıca TTL’leri geçiş döneminde makul bir süre kısaltmak, ani geri dönüş gerektiğinde hayat kurtarıyor.

Sağlık kontrolleri ve “kırılınca düşmesin” temennisi

Weighted DNS’in yanında bir sağlık kontrolü mekanizması eşlik ettiğinde, hedeflerden biri sorun yaşarsa trafik kendiliğinden diğerine kayıyor. Cloudflare ve Route 53’te farklı adlarla anılsa da mantık aynı: uçların nabzını tutmak. Tek hatırlatma: DNS, uygulama katmanındaki hataları anında görmez. Bir endpoint “yaşıyor” gibi görünüp, uygulama tarafta hata veriyor olabilir. O yüzden uygulama sağlığını da ölçen uçlar eklemek tatlı bir sigorta.

Split‑Horizon: İçerden Bakınca Başka, Dışardan Bakınca Başka Dünya

Kurumsal ağ, VPN ve özel bölgeler

Split‑horizon, aynı alan adının içeriden farklı, dışarıdan farklı cevaplar vermesi. Şirket içindeyken “app.example.com” özel IP’ye çözülsün, dışarıdayken ise dış yüze baksın gibi düşünebilirsiniz. Route 53’te özel barındırma bölgeleri bu işi doğal karşılıyor. Detayları merak edenler için AWS’nin private hosted zone sayfası gayet akıcı. Cloudflare tarafında da özel ağlar ve tünellerle benzer desenler kurulabiliyor; burada kilit nokta, istemcinin nereden geldiğini tanıyacak bir kapı aralamak.

İki gerçek, tek alan adı

Split‑horizon kurarken en büyük risk, kayıt ayrışması. İç bölgede güncellemeyi yaptınız ama dışı unuttunuz, veya tam tersi. Bir gün staging’e girmeniz gerekirken prod’a bağlanırsınız. Bu yüzden kayıtların “tek bir kaynaktan yönetilmesi” için küçük bir ritüel oluşturmak iyi oluyor. Adlandırma standardı, değişiklik listesi ve pratik bir gözden geçirme. Küçük görünen ama büyük kazalar önleyen alışkanlıklar.

Bu arada isim sunucularınızı kendiniz yönetiyorsanız ve dış dünyaya doğru kimlik bilgisi vermek istiyorsanız, kendi ad sunucunuzu ve glue record’larınızı kurmak üzerine anlattığım adımlar hoş bir başlangıç olabilir. Temel taşlar yerindeyse, split‑horizon ve gelişmiş politikalar daha güvenli yürüyor.

Uçtan Uca Kurgular: Coğrafi + Weighted + Split‑Horizon Birlikte Nasıl Akar?

Senaryoyu canlı düşünelim

Diyelim uygulamanız üç bölgede çalışıyor: Frankfurt, İstanbul ve Virginia. Avrupa trafiğini ağırlıklı olarak Frankfurt’a, Ortadoğu’yu İstanbul’a, Kuzey Amerika’yı Virginia’ya akıtmak istiyorsunuz. Üstüne, yeni sürümü önce İstanbul’da küçük bir yüzdede açıp, sonra Frankfurt ve Virginia’ya yayacaksınız. Dış dünyaya coğrafi + ağırlıklı bir politika, iç dünyaya ise split‑horizon ile özel IP’ler. Böyle bir kurgu, beklenmedik durumlarda geri dönüşü de kolaylaştırır. İçeride bir sorun oldu mu, iç DNS dışarıdan bağımsız ayakta durur. Dış dünyada bir bölge düşse, diğer bölgeler nazikçe yükü alır.

TTL taktiği ve küçük ritüeller

Geçiş günlerinde TTL’i biraz kısa tutup (örneğin dakikalar seviyesinde), işler yerine oturunca makul bir seviyeye geri almak iyi gidiyor. Sık yapılan bir hata, geçiş bittiği halde TTL’i düşük bırakmak. Gereksiz sorgu, gereksiz maliyet, bıçak sırtı değişiklik. Küçük bir alışkanlık edinin: değişiklik öncesi ve sonrası not alın, bir hafta sonra geri dönüp TTL’i gözden geçirin. Bu kadar basit.

IPv6’yı unutmamak

Bugün trafiğin ciddi bir kısmı IPv6 ile akıyor. AAAA kayıtlarını eksik geçince garip sorunlar yaşanabiliyor. Geçenlerde minik bir AAAA kaydıyla ilgili küçük ama aydınlatıcı bir hikaye paylaşmıştım; orada da gördüğüm gibi, tek bir eksik kayıt koca zinciri etkileyebiliyor. Hatta altyapınız IPv6‑only bir bölgede ise, IPv6‑only bir sunucu üzerinde NAT64/DNS64 köprüsü kurma adımları işinizi kolaylaştırır. DNS tarafında bunun karşılığı, A ve AAAA kayıtlarını tutarlı yönetmek ve testleri her iki protokolde ayrı ayrı yapmak.

Uygulama katmanını da düşünmek

DNS işinizi yapsa bile, taşıdığınız trafiğin üst katmanda iyi karşılanması gerekiyor. TLS, HTTP/2/3, gzip/brotli gibi detaylar kullanıcı deneyimini bariz etkiliyor. Cloudflare üzerinden son adımı da güzelleştirmek için, HTTP/2 ve HTTP/3’ü uçtan uca etkinleştirme rehberimizi el altında tutmak hoş olur. O yazıda, tarafa göre nasıl test edildiğini ve ufak tuzakları da anlatmıştım.

Test, Gözlem ve Sorun Giderme: “Nerede Ne Oldu?”yu Sakince Bulmak

Tek bir araçla değil, birkaç pencereden bakmak

Bir kaydı güncellediniz ve “neden hâlâ eskisi geliyor?” diye soruyorsunuz. Burada üç adımlık bir rutin çok iş görüyor: önce TTL’in geçmesini beklemek, sonra farklı resolver’lardan testi tekrarlamak, en sonda da uygulama loglarına bakmak. Bazen kayıt doğru dönüyor, ama CDN önbelleği sizi eski içeriğe bağlı tutuyor. Bazen CDN tertemiz, ama uygulama tarafında rota yanlış. Bunu ayırt etmek için basitçe “DNS ne diyor?”, “HTTP başlığı ne diyor?”, “uygulama logu ne diyor?” üçlüsünü art arda kontrol edin.

Dokümantasyonlar ve sakin akşam okumaları

Kavramların isimleri bazen kafayı karıştırabiliyor. “Geolocation mı, geoproximity mi?” diye sorarken, küçük bir referansa bakmak iyi geliyor. Cloudflare’ın resmi dokümanlarındaki geo steering bölümü ve AWS’nin Route 53 yönlendirme politikaları özet ve nokta atışı. Split‑horizon yaklaşımının tarihsel bağlamını merak ediyorsanız, split‑horizon DNS üzerine kısa notlar da merakı tatlı tatlı gideriyor.

Küçük Tuzaklar ve Nazik Çözümler

Negatif önbellek ve “yok” cevabı

DNS’te “böyle bir kayıt yok” cevabı bile önbelleğe alınabiliyor. Yanlışlıkla bir kaydı silip geri eklediğinizde, bazı kullanıcılar bir süre “yok” cevabını almaya devam eder. Bu yüzden kritik kayıtları silmek yerine, mümkünse hedefini değiştirin. Silmek şartsa, yedek bir kayıt adıyla geçici köprü kurmak bazen daha güvenli.

İsimlendirme ve okunabilirlik

Topoloji büyüdükçe kayıt adları kabarıp gidiyor. “app‑eu‑blue.example.com”, “app‑eu‑green.example.com” gibi uçlar, ağırlıklı DNS’te hayat kurtarıyor. Hedefin ne olduğunu okur okumaz anlamak, gece yarısı hatayı daha hızlı ayıklatır. İki basit kural iyi gidiyor: anlamlı adlar ve kısa, tekrar edilebilir ritüeller. Dağıtım öncesi bir kontrol listesi, dağıtım sonrası kısa bir gözden geçirme.

Önce temel taşlar

DNS’in üzerinde uçuşan tüm bu akıl oyunlarının sağlıklı olması için temel taşları sağlam koymak önemli. Özellikle kendi alan adınızın otoritatif isim sunucularına karar verirken, yapı taşlarından emin olun. İlk kez kuranlar için, özel ad sunucusu ve glue record kurulumunu adım adım görmek güven veriyor. Bu parça düzgünse, gerisi daha kolay akıyor.

Kapanış: Yumuşak Geçişlerin ve Doğru Adreslerin Mutluluğu

Şunu fark ettim: DNS tarafında küçük, sakin bir dokunuş çoğu zaman uygulama tarafındaki büyük değişikliklerden daha etkili olabiliyor. Coğrafi yönlendirme ile kullanıcıyı yakın hissettirmek, ağırlıklı DNS ile geçişleri yormadan yapmak, split‑horizon ile içerisi‑dışarısı dengesini kurmak. Hepsi kendi başına anlamlı, birlikteyse şahane. Karşılığında da daha mutlu kullanıcılar, daha sakin gece nöbetleri.

Pratik tavsiye olarak, geçiş günlerinde TTL’i nazikçe kısaltın, farklı resolver’lardan test etmeyi alışkanlık haline getirin, bakım öncesi küçük bir geri dönüş planını kenarda tutun. Coğrafi kurgularda küçük istisnalar için bir kaçış rotası bırakın, weighted senaryolarda da ölçümü tek kaynaktan değil farklı pencerelerden yapın. Umarım bu yolculuk, kendi sisteminizde bir iki taşı yerine oturtur. Sorularla, notlarla, aklınıza takılanlarla yine buluşuruz. Bir dahaki yazıda görüşmek üzere.