GeoDNS Nedir ve Coğrafi Yönlendirme

Klasik bir DNS sunucusu, alan adınız için kim sorarsa sorsun aynı IP adresini döndürür. İstanbul'daki bir ziyaretçi de, Frankfurt'taki bir ziyaretçi de, Kaliforniya'daki bir ziyaretçi de tek bir sunucuya yönlendirilir. Eğer o sunucu Almanya'daysa, Kaliforniya'dan gelen kullanıcı her istekte okyanusu geçmek zorunda kalır ve bunun bedeli gecikme olarak faturaya yansır. İşte GeoDNS tam olarak bu problemi çözmek için tasarlanmış bir tekniktir: aynı alan adı için gelen DNS sorgusunu, sorguyu yapanın coğrafi konumuna bakarak farklı IP adreslerine yanıtlar.

Bir sistem yöneticisi gözünden anlatmak gerekirse GeoDNS, DNS katmanına eklenmiş akıllı bir trafik memurudur. Kullanıcı www.ornek.com adresini yazdığında, çözümleyici (resolver) bu adı IP'ye çevirmek için otoritatif DNS sunucusuna soru sorar. Standart DNS bu soruya sabit bir cevap verirken, GeoDNS "soruyu kim, nereden soruyor?" diye bakar ve o bölgeye en yakın sunucunun IP'sini döndürür. Böylece kullanıcı, uygulama katmanında hiçbir değişiklik yapılmadan, sadece isim çözümleme aşamasında en yakın veri merkezine yönlendirilmiş olur. Bu yazıda GeoDNS'in nasıl çalıştığını, CDN ile ilişkisini, gerçek kurulum örneklerini ve en çok göz ardı edilen konu olan konum tespitindeki hata paylarını uygulamalı biçimde ele alacağız. Temel DNS mantığını hatırlamak isterseniz DNS nedir yazısı iyi bir başlangıç noktasıdır.

GeoDNS Nasıl Çalışır#

GeoDNS'in kalbinde tek bir soru vardır: "Bu sorgu dünyanın neresinden geliyor?" Sistem, gelen isteğin kaynak IP adresini alır ve bir coğrafi veritabanında (genellikle MaxMind GeoIP2 gibi) arayarak ülke, kıta veya en yakın bölgeyi tespit eder. Ardından yönetici tarafından tanımlanmış kurallara göre o bölgeye atanmış IP'yi cevap olarak döndürür.

Kavramı somutlaştırmak için basit bir zone mantığını düşünelim. Aynı www kaydının farklı bölgeler için farklı değerler taşıdığı bir yapı kurulur:

; Avrupa'dan gelen sorgulara Frankfurt sunucusu
www.ornek.com.   IN A   5.9.10.20     ; region: EU

; Kuzey Amerika'dan gelen sorgulara New York sunucusu
www.ornek.com.   IN A   198.51.100.7  ; region: NA

; Diğer tüm bölgeler için varsayılan (İstanbul)
www.ornek.com.   IN A   185.20.30.40  ; region: default

Burada dikkat edilmesi gereken kritik nokta şudur: GeoDNS sunucusu aynı isim için birden fazla adaya sahiptir ve hangisini vereceğine sorgu anında karar verir. Bu karar mekanizması, DNS'in normal çalışma akışını bozmadan araya girer. Kullanıcı hiçbir şey fark etmez; tarayıcısı sadece bir IP alır ve ona bağlanır. Tüm zekâ, otoritatif DNS sunucusunun içinde gizlenmiştir.

Modern GeoDNS altyapıları çoğunlukla PowerDNS'in geoip backend'i, BIND'in GeoIP özelliği veya bulut sağlayıcılarının yönetilen DNS hizmetleri (Route 53 geolocation routing, Cloudflare Load Balancing, NS1 gibi) üzerinden çalışır. PowerDNS ile yapılandırılmış bir örnek şöyle görünür:

# pdns geoip backend - domains.yaml
domains:
  - domain: ornek.com
    ttl: 60
    records:
      www.ornek.com:
        - content: "%co.ornek.com"   # ülke koduna göre CNAME üret
          type: CNAME
    services:
      www.ornek.com: "www-%co.ornek.com"

Bu yapılandırmada %co yer tutucusu, sorgunun geldiği ülke koduyla (örneğin tr, de, us) değiştirilir ve böylece www-tr.ornek.com, www-de.ornek.com gibi bölgesel kayıtlara yönlendirme yapılır. Her bölgesel kayıt kendi veri merkezinin IP'sini taşır.

GeoDNS ile Standart DNS Arasındaki Fark#

Aradaki farkı net görebilmek için iki yaklaşımı yan yana koymak faydalı olur. Standart DNS bir telefon rehberi gibidir: isim sorarsınız, tek numara alırsınız. GeoDNS ise "hangi şehirdesiniz?" diye sorup size o şehrin bayisinin numarasını veren akıllı bir santral gibidir.

Bu tablodan çıkan sonuç açıktır: GeoDNS, standart DNS'in yerini almaz; onun üzerine bir zekâ katmanı ekler. Aynı zone içinde bazı kayıtlar geo tabanlı, bazıları klasik olabilir. Örneğin mail.ornek.com her zaman aynı posta sunucusuna gitmeliyken, www.ornek.com bölgesel dağıtımdan yararlanabilir. Bu esneklik, GeoDNS'i büyük ölçekli servisler için vazgeçilmez kılar.

GeoDNS ve CDN İlişkisi#

En sık karıştırılan konulardan biri GeoDNS ile CDN'in ilişkisidir. Bu ikisi rakip değil, çoğu zaman aynı takımın oyuncularıdır. CDN (İçerik Dağıtım Ağı), dünyanın farklı noktalarına yerleştirilmiş kenar (edge) sunucularından oluşur ve statik içeriği kullanıcıya en yakın noktadan sunar. Peki kullanıcı hangi edge sunucuya yönlendirilir? İşte burada devreye ya GeoDNS ya da onun daha gelişmiş akrabası Anycast girer.

Pratikte iki yaygın senaryo vardır. Birincisinde CDN, dağıtım için Anycast kullanır; yani tüm edge sunucular aynı IP'yi paylaşır ve internetin yönlendirme (BGP) katmanı, paketi en yakın sunucuya taşır. İkincisinde ise CDN, kullanıcıya bölgeye göre farklı bir edge IP'si döndürmek için GeoDNS kullanır. Cloudflare gibi büyük sağlayıcılar ağırlıklı olarak Anycast temellidir, ancak birçok geleneksel CDN ve yönetilen DNS servisi GeoDNS mantığını tercih eder. Bir CDN kurmayı planlıyorsanız Cloudflare DNS ve CDN yapılandırması yazısındaki adımlar bu ilişkiyi daha da netleştirecektir.

Kendi altyapınızı yönetiyorsanız GeoDNS'i bir CDN olmadan da kullanabilirsiniz. Örneğin İstanbul ve Frankfurt'ta iki ayrı sunucunuz varsa, GeoDNS ile Türkiye trafiğini İstanbul'a, Avrupa trafiğini Frankfurt'a yönlendirebilirsiniz. Bu, tam teşekküllü bir CDN'e kıyasla daha basit ve maliyeti kontrol edilebilir bir çözümdür. Sunucu altyapınızı VDS veya sanal sunucu seçenekleriyle farklı lokasyonlarda kurgulayarak bu mimariyi hayata geçirebilirsiniz.

Gecikmeyi Azaltma ve Yük Dağıtma#

GeoDNS'in getirdiği iki temel kazanım vardır: gecikmeyi (latency) azaltmak ve yükü dağıtmak. Gecikme, verinin kullanıcı ile sunucu arasında gidip gelmesi için geçen süredir ve mesafeyle doğru orantılıdır. Işık hızı fizik yasasıdır; İstanbul'dan Kaliforniya'ya bir paketin gidip dönmesi teorik olarak bile onlarca milisaniye sürer. GeoDNS, kullanıcıyı coğrafi olarak en yakın sunucuya bağlayarak bu turu kısaltır.

Aradaki farkı test etmek için basit araçlar yeterlidir. Bir kullanıcının iki farklı sunucuya olan gecikmesini ping ile ölçebilirsiniz:

# Türkiye'deki bir istemciden ölçüm
ping -c 4 istanbul.ornek.com
# rtt min/avg/max = 8.2/9.1/10.4 ms

ping -c 4 frankfurt.ornek.com
# rtt min/avg/max = 42.6/44.0/47.1 ms

Bu örnekte yerel kullanıcı için İstanbul sunucusu neredeyse beş kat daha hızlıdır. GeoDNS olmadan bu kullanıcı belki de Frankfurt'a yönlendirilecek ve her sayfa yüklemesinde bu farkı ödeyecekti. TLS el sıkışması, API çağrıları ve her HTTP isteği bu gecikmeyi katlar; dolayısıyla toplam sayfa açılış süresine etkisi tek bir ping değerinin çok ötesindedir.

İkinci kazanç olan yük dağıtma ise özellikle trafik yoğun servisler için hayati önem taşır. Tüm dünya trafiğini tek bir sunucuya yığmak yerine, GeoDNS her bölgeyi kendi sunucusuna dağıtır. Bir bölge çökerse veya bakıma girerse, sağlık kontrolü (health check) yapan gelişmiş GeoDNS servisleri o bölgeyi devre dışı bırakıp trafiği en yakın sağlam sunucuya kaydırabilir. Bu, hem performans hem de dayanıklılık anlamına gelir. Yüksek erişilebilirlik hedefliyorsanız GeoDNS'i düzenli yedekleme stratejisiyle birlikte kurgulamak, bir felaket senaryosunda kayıpları en aza indirir.

Konum Tespitinin Sınırları ve Yanlış Eşleşmeler#

Şimdi çoğu rehberin atladığı ama pratikte en çok baş ağrıtan konuya geldik. GeoDNS, kullanıcının konumunu doğrudan bilmez. Bildiği tek şey, kendisine soruyu soran DNS çözümleyicisinin IP adresidir. Ve burada kritik bir varsayım gizlidir: çözümleyicinin, kullanıcıya yakın olduğu varsayılır. Çoğu zaman bu doğrudur, çünkü kullanıcılar internet servis sağlayıcılarının yerel DNS sunucularını kullanır. Ancak bu varsayım her zaman geçerli değildir.

Klasik örnek, kamuya açık DNS servisleridir. Bir kullanıcı Türkiye'den geliyor ama Google Public DNS (8.8.8.8) veya Cloudflare (1.1.1.1) kullanıyorsa, GeoDNS sunucusu çözümleyicinin çıkış IP'sini görür. Eğer bu IP o an ABD'deki bir düğüme aitse, GeoDNS kullanıcıyı yanlışlıkla ABD sunucusuna yönlendirebilir. Sonuç: Türkiye'deki kullanıcı, kendi ülkesindeki sunucu yerine okyanus ötesine bağlanır ve tam da önlemeye çalıştığınız gecikmeyi yaşar.

Bu soruna karşı geliştirilen çözüm EDNS Client Subnet (ECS) uzantısıdır. ECS ile çözümleyici, sorguya kullanıcının IP alt ağının bir kısmını da ekler. Böylece GeoDNS, çözümleyicinin değil, gerçek kullanıcının konumuna göre karar verebilir. Bir kaydın ECS destekli olup olmadığını dig ile test edebilirsiniz:

# ECS ile Türkiye alt ağını taklit ederek sorgu
dig @ns1.ornek.com www.ornek.com +subnet=185.20.30.0/24

# Yanıtta gelen bölüm ECS desteğini gösterir:
# ; CLIENT-SUBNET: 185.20.30.0/24/24
# www.ornek.com.  60  IN  A  185.20.30.40   ; İstanbul - doğru eşleşme

Yine de ECS her sağlayıcıda desteklenmez ve gizlilik nedeniyle bazı çözümleyiciler kullanıcı alt ağını kırpar veya hiç göndermez. Dikkat edilecek diğer sınırlar da vardır: mobil operatörler trafiği beklenmedik şehirlerden çıkarabilir, kurumsal VPN'ler kullanıcıyı tamamen başka bir ülkedeymiş gibi gösterebilir ve GeoIP veritabanları her zaman güncel değildir; yeni tahsis edilmiş IP blokları yanlış ülkeye atanmış olabilir. Bu yüzden GeoDNS'i kurarken mutlaka bir varsayılan (fallback) bölge tanımlanmalıdır; konum tespit edilemeyen veya yanlış eşleşen her sorgu makul bir merkezi sunucuya düşmelidir. Aşağıdaki tablo bu yanlış eşleşme kaynaklarını özetler:

Pratik Kurulum Örneği#

Teoriyi bir kenara bırakıp somut bir kuruluma bakalım. Diyelim ki elinizde İstanbul ve Frankfurt'ta çalışan iki nginx sunucusu var ve gelen trafiği coğrafi olarak ayırmak istiyorsunuz. GeoDNS katmanı yönlendirmeyi DNS'te yapar; ancak her iki sunucunun da kendi bölgesel içeriğini doğru sunması için nginx tarafında da küçük bir yapılandırma faydalıdır. nginx'in geo modülü, gelen isteğin IP'sine göre bir değişken atayabilir:

# nginx.conf - bölgesel etiketleme
geo $client_region {
    default        other;
    185.20.0.0/16  tr;
    5.9.0.0/16     eu;
}

server {
    listen 443 ssl;
    server_name www.ornek.com;

    add_header X-Served-Region $client_region always;

    location / {
        root /var/www/$client_region;
        try_files $uri $uri/ /index.html;
    }
}

Buradaki X-Served-Region başlığı, kullanıcının hangi bölge olarak değerlendirildiğini tarayıcının geliştirici araçlarından görmenizi sağlar; hata ayıklarken paha biçilmezdir. GeoDNS yönlendirmesini doğrulamak için farklı lokasyonlardan sorgu yapmak gerekir. Elinizde birden fazla lokasyon yoksa çevrim içi DNS test araçları veya bulut üzerindeki geçici sunucular işinizi görür. Bir sağlık kontrolü betiği ile her bölgenin ayakta olduğunu periyodik olarak doğrulayabilirsiniz:

#!/usr/bin/env bash
# geo-healthcheck.sh
for region in istanbul frankfurt; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
         --max-time 5 "https://${region}.ornek.com/health")
  if [ "$code" != "200" ]; then
    echo "UYARI: ${region} bolgesi yanit vermiyor (HTTP ${code})"
  fi
done

Kendi sunucularınızın kurulumu ve bakımıyla uğraşmak istemiyorsanız, bu tür çok bölgeli mimarileri sunucu yönetimi hizmetiyle bir ekibe devredebilir, kendiniz yalnızca içeriğe odaklanabilirsiniz.

GeoDNS Ne Zaman Gerekli, Ne Zaman Gereksiz#

GeoDNS güçlü bir araçtır ama her projeye lazım değildir. Ölçek ve hedef kitlenin coğrafi dağılımı en belirleyici faktörlerdir. Ziyaretçilerinizin neredeyse tamamı Türkiye'deyse ve tek bir Türkiye lokasyonunda sunucunuz varsa, GeoDNS size hiçbir kazanç sağlamaz; sadece gereksiz karmaşıklık ekler. Bu durumda tek bölgeli sağlam bir hosting veya WordPress hosting paketi çok daha mantıklıdır.

GeoDNS'in gerçekten parladığı senaryolar ise şunlardır: birden fazla kıtada kayda değer bir kullanıcı kitleniz varsa, farklı ülkelerde ayrı ayrı sunucularınız (veya edge noktalarınız) varsa, gecikme uygulamanızın deneyimini doğrudan etkiliyorsa (gerçek zamanlı uygulamalar, oyunlar, video) ve yasal veri yerelleştirme gereklilikleri belirli trafiği belirli ülkelerde tutmanızı zorunlu kılıyorsa. Bu koşulların hiçbiri geçerli değilse, GeoDNS'in bakım maliyeti getirdiği faydayı aşabilir. Karar verirken kendinize dürüstçe "birden fazla bölgede gerçekten sunucum var mı?" sorusunu sorun; GeoDNS var olmayan sunucuları icat etmez, sadece var olanlar arasında akıllıca seçim yapar. Küçük ve orta ölçekli çoğu site için, bir CDN'in önüne konan Anycast tabanlı bir çözüm, kendi GeoDNS'inizi yönetmekten hem daha kolay hem daha güvenilirdir.

Sıkça Sorulan Sorular#

GeoDNS ile CDN aynı şey mi?#

Hayır, ikisi farklı katmanlarda çalışır ama sık sık birlikte kullanılır. GeoDNS bir DNS tekniğidir ve yalnızca isim çözümleme aşamasında kullanıcıya konumuna göre farklı IP döndürür. CDN ise dünyaya yayılmış edge sunuculardan oluşan bir içerik dağıtım ağıdır. Bir CDN, kullanıcıyı en yakın edge sunucuya yönlendirmek için ya GeoDNS'ten ya da Anycast yönlendirmeden faydalanır; yani GeoDNS çoğu zaman CDN'in altında çalışan bir bileşendir.

GeoDNS kullanmak için kaç sunucuya ihtiyacım var?#

En az iki farklı lokasyonda sunucunuz olması gerekir, aksi halde yönlendirecek bir alternatif yoktur. Tek bir sunucunuz varsa GeoDNS hiçbir işe yaramaz; çünkü her sorguya zaten aynı IP'yi döndürmek zorunda kalır. Mantıklı bir kullanım için hedef kitlenizin yoğun olduğu bölgelerde birer sunucu bulundurup GeoDNS ile trafiği bunlar arasında dağıtmanız beklenir. Farklı lokasyonlarda sunucu kurmak için VDS veya sanal sunucu çözümlerini değerlendirebilirsiniz.

Google DNS kullanan ziyaretçiler yanlış sunucuya mı gider?#

Bu risk gerçektir ancak modern altyapılarla büyük ölçüde azaltılabilir. GeoDNS, kullanıcının değil, sorguyu ileten çözümleyicinin IP'sini gördüğü için genel DNS servisleri (8.8.8.8 gibi) bazen yanlış eşleşmeye yol açabilir. Bu sorunu çözmek için EDNS Client Subnet uzantısını destekleyen bir DNS sağlayıcısı kullanılır; bu uzantı gerçek kullanıcının alt ağını sorguya ekleyerek doğru bölge seçimini sağlar. Yine de her ihtimale karşı bir varsayılan bölge tanımlamak şarttır.

GeoDNS SEO'yu etkiler mi?#

Doğru kurulduğunda GeoDNS SEO'ya zarar vermez, hatta hız kazancıyla dolaylı fayda sağlar. Arama motoru botları da coğrafi olarak bir yerden gelir ve GeoDNS onlara da en yakın sunucuyu döndürür; önemli olan tüm bölgelerde aynı içeriğin sunulması ve gizleme (cloaking) yapılmamasıdır. Farklı bölgelere farklı diller sunuyorsanız hreflang etiketleri ile bunu açıkça belirtmeniz gerekir. Sayfa hızı bir sıralama faktörü olduğundan, gecikmeyi düşüren GeoDNS aslında SEO'ya olumlu katkı yapar.

GeoDNS ile yük dengeleme (load balancing) arasındaki fark nedir?#

İkisi farklı amaçlara hizmet eder ama örtüşebilir. Klasik yük dengeleme, genellikle tek bir veri merkezindeki sunucular arasında trafiği eşit dağıtmaya odaklanır ve amacı kapasiteyi verimli kullanmaktır. GeoDNS ise trafiği önce coğrafi olarak ayırır; amacı gecikmeyi azaltmaktır. Gelişmiş GeoDNS servisleri sağlık kontrolü ve ağırlıklandırma ile bölgesel bir yük dengeleme katmanı da sunabilir, ancak her bölgenin içindeki sunucu havuzunu dengelemek için yine yerel bir load balancer gerekir.

Kendi GeoDNS sunucumu kurmalı mıyım yoksa yönetilen bir servis mi kullanmalıyım?#

Çoğu proje için yönetilen bir servis daha akıllıca bir tercihtir. Kendi GeoDNS'inizi PowerDNS veya BIND ile kurmak size tam kontrol verir ama GeoIP veritabanını güncel tutmak, otoritatif sunucuları farklı lokasyonlarda dağıtmak ve sağlık kontrollerini yönetmek sürekli emek ister. Cloudflare, Route 53 veya benzeri yönetilen çözümler bu yükü üstlenir ve genellikle daha geniş bir sunucu ağına sahiptir. Yalnızca çok özel gereksinimleriniz veya tam kontrol ihtiyacınız varsa kendi altyapınızı kurmak mantıklı olur.

Kapanış#

GeoDNS, karmaşık görünen ama temelde basit bir fikre dayanan güçlü bir performans aracıdır: kullanıcıya en yakın kapıyı açmak. Doğru senaryoda kullanıldığında gecikmeyi ciddi biçimde düşürür, trafiği dengeler ve bir bölge çöktüğünde bile hizmetin ayakta kalmasını sağlar. Ancak konum tespitinin çözümleyici IP'sine dayandığını, dolayısıyla yanlış eşleşmelerin mümkün olduğunu asla unutmayın; her kurulumda EDNS Client Subnet desteği ve sağlam bir varsayılan bölge, bu tekniğin sigortasıdır. Küçük ölçekli, tek bölgeli projeler için ise GeoDNS'in getirdiği karmaşıklık çoğu zaman gereksizdir.

Clou.TR olarak hem tek bölgeli hızlı hosting paketlerinden çok bölgeli VDS ve sanal sunucu çözümlerine kadar geniş bir yelpaze sunuyoruz. Coğrafi olarak dağıtılmış bir mimari kurmayı ya da mevcut altyapınızı hızlandırmayı düşünüyorsanız, sunucu yönetimi ekibimiz doğru GeoDNS ve CDN kurgusunu sizin adınıza planlayıp hayata geçirebilir. Alan adınızın DNS ayarlarından tam yönetimli sunucu mimarisine kadar her adımda yanınızdayız; projenize en uygun çözümü birlikte belirlemek için ürün sayfalarımıza göz atabilirsiniz.