GeoDNS ile Coğrafi Yönlendirme Nasıl Çalışır?

GeoDNS (Geographic DNS), bir alan adına yapılan DNS sorgularını, sorguyu gönderen kullanıcının coğrafi konumuna göre farklı IP adreslerine yönlendiren bir mekanizmadır. Standart DNS'te bir alan adı için tek bir A kaydı bulunur; GeoDNS bunu bölgeye göre çoğaltır, anycast ise aynı IP'yi her yerde duyurur. GeoDNS'te aynı alan adı için birden fazla coğrafi bölgeye özgü A kaydı tanımlanır ve hangi kaydın döneceğini yetkili nameserver, sorgunun geldiği IP adresine bakarak belirler.

Temel amaç gecikmeyi (latency) azaltmaktır. İstanbul'daki bir kullanıcı Frankfurt'aki sunucuya bağlanmak yerine İstanbul yakınındaki bir CDN node'una yönlendirilirse; çok origin'li yapı çoklu CDN planına oturur ve içerik daha hızlı ulaşır. Fakat GeoDNS salt bir performans aracı değildir; içerik lisanslama, veri egemenliği gereksinimleri veya bölgesel failover senaryoları için de kullanılır.

Cloudflare Load Balancer ve AWS Route 53, bu işi yapan en yaygın iki araçtır; sağlık sinyali olmadan dağıtım round robin seviyesinde kalır. İkisi de aynı sorunu çözer, ancak mimari anlayışları, yapılandırma granülaritesi ve fiyatlandırma modelleri birbirinden belirgin biçimde ayrılır. Aşağıda her iki yaklaşımı, Türkiye ve Almanya kullanıcılarını farklı CDN node'larına yönlendirme senaryosu üzerinden karşılaştıracağız.

GeoDNS Nasıl Çalışır: Sorgudan Yönlendirmeye

DNS sorgusunu yapan taraf genellikle son kullanıcının ISP'si tarafından işletilen recursive resolver'dır; kullanıcının kendisi değil. Bu ayrım önemlidir, çünkü GeoDNS yetkili nameserver'ı, recursive resolver'ın IP adresine bakarak konum tahmini yapar. Kullanıcı İstanbul'da olsa bile şirket VPN'i üzerinden Londra'daki bir recursive resolver kullanıyorsa, nameserver onu Londra bölgesine atayabilir.

EDNS Client Subnet (ECS) bu sorunu kısmen çözer. ECS desteği olan resolver'lar, DNS sorgusuna son kullanıcının IP adresinin ilk birkaç oktetini ekler; böylece nameserver gerçek kullanıcı konumunu yaklaşık olarak görebilir. Google Public DNS ve 1.1.1.1 resolver'ı ECS destekler; bazı Türk ISP recursive resolver'ları desteklemez. Bu, GeoDNS doğruluğunu ölçmeden önce hesaba katmanız gereken bir kısıtlamadır.

Coğrafi eşleştirme için nameserver, MaxMind GeoIP gibi veritabanlarından yararlanır. IP bloğunun hangi ülkeye veya bölgeye ait olduğu bu veritabanlarından çekilir. Veritabanı hatalarını sıfıra indirmek mümkün değildir; özellikle mobil operatör IP aralıkları ve ticari VPN adresleri zaman zaman yanlış ülkeye atanır. Yapılandırmanızda her zaman bir varsayılan (default) kural bulunmalıdır; eşleşme bulunamazsa bu kural devreye girer.

Farklı Ülkelere Farklı A Kaydı: Temel GeoDNS Yapısı

GeoDNS'in en sade biçiminde her coğrafi bölge için ayrı bir A kaydı tanımlanır. Örneğin cdn.example.com alan adı için Türkiye'den gelen sorgular 195.0.0.10 adresine, Almanya'dan gelenler 185.0.0.20 adresine döner. Eşleşme sağlanamayan tüm sorgular varsayılan kayda yönlenir.

TTL yönetimi bu noktada kritik hale gelir. GeoDNS kayıtları için TTL değerini yüksek tutmak, resolver'ların yanlış coğrafi kaydı önbelleğe almasına ve uzun süre saklı tutmasına neden olur. Çoğu GeoDNS operatörü bu kayıtlar için 60 ile 300 saniyelik TTL değerleri kullanır; daha düşük değerler nameserver'a gelen sorgu yükünü artırır, daha yüksek değerler ise coğrafi hataların düzeltilmesini geciktirir.

Failover ile GeoDNS birleştiğinde tablo karmaşıklaşır. Türkiye node'u devre dışı kalırsa yükü Almanya'ya mı, yoksa daha yakın bir başka node'a mı aktarırsınız? Bu soruyu yapılandırma aşamasında yanıtlamak, olaylar sırasında panikle karar vermekten çok daha güvenlidir.

Cloudflare Load Balancer ile Coğrafi Yönlendirme

Cloudflare Load Balancer, GeoDNS işlevini "geo steering" adıyla sunar. Önce bir pool oluşturulur: Türkiye için tr-pool, Almanya için de-pool. Her pool içinde bir veya birden fazla origin IP tanımlanır. Ardından bir load balancer kaydı oluşturulur ve bölgeye göre hangi pool'un kullanılacağı belirtilir.

Load Balancer: cdn.example.com
  Bölge: MENA  → tr-pool  (origin: 195.0.0.10)
  Bölge: EEUR  → de-pool  (origin: 185.0.0.20)
  Varsayılan   → de-pool

Cloudflare'in bölge haritası ülke bazında değil, kıta ve alt-bölge bazındadır: EEUR (Eastern Europe), WEUR (Western Europe), MENA (Middle East & North Africa) gibi. Türkiye için doğrudan bir "TR" seçeneği yoktur; MENA veya EEUR bölgesine dahil edilir. Bu granülarite yetmezse Cloudflare Workers ile özel coğrafi yönlendirme mantığı yazılabilir; ancak bu, standart Load Balancer yapılandırmasının ötesine geçer.

Cloudflare'in önemli avantajı health check entegrasyonudur. tr-pool sağlık kontrolünden geçemezse yük otomatik olarak fallback pool'a devredilir. Yapılandırma, Cloudflare'in global ağı üzerinden çalıştığından DNS değişiklikleri çok hızlı yayılır. Farklı DNS sağlayıcıları arasında subdomain mimarisi kurgulanırken de bu hız avantajı belirleyici bir etken olur.

AWS Route 53 Geo Routing: Politika Türleri ve Farkları

Route 53, coğrafi yönlendirme için iki ayrı politika sunar: Geolocation ve Geoproximity. İkisi arasındaki fark hem teknik hem de stratejik açıdan önemlidir.

Geolocation politikası ülke ve kıta bazında çalışır. Türkiye için ayrı bir kayıt oluşturulur, Almanya için ayrı. Eşleşme bulunamazsa devreye girecek bir varsayılan kayıt da tanımlanmalıdır; varsayılan eksikse sorgu yanıtsız kalır ve bu ciddi bir kesintiye dönüşür. Route 53 Geolocation, ülke bazında ince ayar isteyenler için Cloudflare'in bölge bazlı yapısına kıyasla daha hassas bir kontrol sağlar.

Geoproximity politikası ise kaynak koordinatlarına göre en yakın kaynağa yönlendirir ve "bias" (önyargı) parametresiyle bölge sınırları esnetilebilir. Türkiye kaydına artı değerli bir bias eklerseniz, Türkiye'ye daha fazla trafik çekersiniz, hatta komşu ülkelerden de. Bu yalnızca Route 53 Traffic Flow özelliğiyle yapılandırılabilir ve ek maliyet doğurur.

Route 53 Geolocation - cdn.example.com
  Ülke: TR       → 195.0.0.10  (TTL: 60)
  Ülke: DE       → 185.0.0.20  (TTL: 60)
  Varsayılan     → 185.0.0.20  (TTL: 60)

Route 53 health check entegrasyonu da mevcuttur. Bir kayda bağlı health check başarısız olursa Route 53 o kaydı devre dışı bırakır ve bir sonraki uygun kayda geçer. Microsoft ekosistemi üzerinde DNS yönetimi yapılandırıyorsanız, Route 53'ün çok bölgeli trafik politikalarıyla karşılaştırmalı bir değerlendirme yapmanız önerilir.

Türkiye ve Almanya Senaryosu: CDN Node Seçimi

Pratikte nasıl görünür? Bir e-ticaret sitesi İstanbul'da ve Frankfurt'ta birer CDN node'u işletiyor. Amaç ve kısıtlamaya göre iki farklı yol izlenebilir.

Yalnızca gecikme odaklıysanız, Türkiye kaynaklı sorgular İstanbul node'una, Almanya kaynaklı sorgular Frankfurt node'una gitmelidir. Bunu Route 53 Geolocation veya Cloudflare geo steering ile doğrudan uygulayabilirsiniz. İstanbul node'u çökerse fallback olarak Frankfurt devreye girer; kullanıcı daha yüksek gecikmeyle de olsa sitenize ulaşmaya devam eder.

Veri egemenliği gereksinimleri eklenince senaryo değişir. Almanya kullanıcılarının GDPR kapsamındaki verilerinin AB dışına çıkmaması gerekiyorsa, Türkiye node'una failover kabul edilemez hale gelir. Bu durumda Almanya politikasına birden fazla AB node'u eklenir ve failover yalnızca bu pool içinde gerçekleşir. İstanbul node'u ise Türkiye ve çevre bölgeler için ayrı bir pool'da tutulur.

Göz ardı edilen bir nokta, statik ve dinamik içeriğin ayrıştırılmasıdır. Statik varlıklar, yani resim, CSS ve JavaScript dosyaları, için GeoDNS son derece verimlidir; node'lar arasında tutarlılık sorunu yoktur. Dinamik içerik veya kullanıcıya özgü veri söz konusu olduğunda origin sunucusuyla iletişim kaçınılmaz olur; bu trafiği hangi node'un üstleneceği sadece coğrafi yakınlıkla değil, origin'e olan bağlantı kalitesiyle de ilgilidir.

GeoDNS Ne Zaman Ters Etki Eder?

Her coğrafi yönlendirme senaryosu kazanımla sonuçlanmaz.

İlk risk: küçük trafik hacminde aşırı karmaşıklık. Günde birkaç bin oturumu olan bir site için iki ayrı CDN node'u işletmenin maliyeti, elde edilen gecikme kazanımını aşabilir. Tek node, güçlü bir CDN önbellekleme stratejisi ve düşük TTL, çoğu durumda daha sağlıklı bir başlangıç noktasıdır.

İkinci risk: yanlış coğrafi eşleştirme. Türk ISP'leri zaman zaman IP bloklarını güncellemeden önce farklı ülke kodlarıyla listelenebilir. Bir kullanıcının yanlış node'a düşmesi ve daha yavaş bir deneyim yaşaması, GeoDNS olmaksızın tek node kullanmaktan daha kötü bir sonuç doğurabilir.

Üçüncü risk: health check olmadan uygulanan GeoDNS. Bir node devre dışı kalırsa, otomatik failover yapılandırılmamışsa tüm kullanıcı grubu erişim kaybeder. Sağlık kontrolü, GeoDNS yapılandırmasının opsiyonel değil zorunlu bir parçasıdır. DNS zone yönetiminde de benzer bir ilke geçerlidir: yönlendirme kuralları ne kadar karmaşıksa, izleme o ölçüde kritik hale gelir.

Dördüncü risk: TTL'yi atlamak. GeoDNS kayıtlarını değiştirdiğinizde, eski değer dünya genelindeki resolver önbelleklerinde TTL süresi dolana kadar yaşamaya devam eder. Bölge değişikliklerini test ederken bile düşük TTL değerleri kullanın. Bir geçişi hızlandırmak istiyorsanız, değişiklikten en az bir TTL süresi önce TTL'yi düşürün; böylece yeni değer çok daha hızlı yayılır.

Cloudflare Load Balancer ile Route 53: Hangisi Ne Zaman Tercih Edilir?

Her iki araç da GeoDNS işlevini yerine getirir; fark edilir ayrım kullanım bağlamında ortaya çıkar.

Cloudflare Load Balancer, zaten Cloudflare nameserver kullanan ve altyapının büyük bölümünü Cloudflare üzerinde yöneten ekipler için daha az sürtünmeyle kurulur. Arayüz, DNS kaydıyla yük dengeleyiciyi aynı konsolda birleştirir; ayrı bir health check altyapısı kurmaya gerek yoktur. Bölge granülaritesi kıta ve alt-bölge düzeyinde kaldığı için ülke bazında ince kontrol isteyenler kısıtlama hissedebilir.

Route 53 Geolocation, ülke düzeyinde kayıt oluşturmanıza izin verdiğinden Türkiye gibi belirli bir ülkeye özgü kural tanımlamak doğrudan mümkündür. AWS ekosistemi içinde çalışıyorsanız, EC2, CloudFront veya ELB ile entegrasyon süreci daha pürüzsüzdür. Özel nameserver yapılandırması yapıyorsanız, Route 53'ü yetkili DNS olarak kullanmak coğrafi yönlendirmeyi kendi altyapınızda tutmanızı sağlar.

Fiyatlandırma açısından Cloudflare Load Balancer aylık sabit ücretle çalışırken Route 53 sorgu başına ücretlendirir. Yüksek trafik hacminde Route 53 daha öngörülebilir bir maliyet profili sunar; düşük hacimde ise Cloudflare'in sabit ücreti avantajlı olabilir. Her ikisinde de yapılandırma değişikliklerinin maliyeti, yanlış coğrafi yönlendirmenin yol açacağı kullanıcı kaybından çok daha düşüktür.

GeoDNS, doğru uygulandığında kullanıcı deneyimini iyileştirir; ancak her DNS kararı gibi, test edilmeden ve izlenmeden uygulamaya alınmamalıdır. Bir bölge için yapılandırma yaparken her zaman varsayılan kuralı tanımlayın, TTL'yi olaylardan önce düşürün ve health check olmadan herhangi bir node'a trafik yönlendirmeyin.

Cloudflare ile Route 53 arasındaki tercih büyük ölçüde mevcut altyapınıza ve bölge granülaritesi ihtiyacınıza bağlıdır. Türkiye için ülke düzeyinde ayrı kural istiyorsanız Route 53 Geolocation doğrudan bu esnekliği sağlar. Cloudflare ekosistemi içinde kalıyorsanız, yük dengeleme, geo steering ve health check'i tek bir arayüzde birleştirmesi ciddi bir operasyonel avantajdır. Hangisini seçerseniz seçin, coğrafi yönlendirme kurallarını belgelemek ve düzenli aralıklarla gözden geçirmek, zamanla birikebilecek yapılandırma borçlarını engeller.