GSLB kararınız bulutta veriliyorsa, zone veriniz ve trafik kararınız kurum dışına taşınmış demektir.
Birçok kurum global trafik yönlendirme için dış DNS ve GSLB servislerine bağımlı çalışır. Bu model pratik görünür; ancak zone içeriği, query logları, geo kararları ve trafik yönlendirme politikaları kurum dışındaki bir platformda tutulur. Finans, kamu, sağlık ve regülasyon hassasiyeti olan yapılarda bu durum veri egemenliği açısından ciddi soru işaretleri doğurur.
GSLB karar katmanının dış servis olması operasyonel süreklilik riski de yaratır. Dış sağlayıcıda yaşanan kesinti, yapılandırma problemi veya API erişim sorunu kurumun DC failover ve DNS yanıt politikasını doğrudan etkileyebilir. Uygulamalarınız ayakta olsa bile trafik doğru DC'ye yönlenmeyebilir.
Authoritative DNS ile sağlık kontrolü ayrı ürünler olarak kurulduğunda başka bir kopukluk oluşur. Health-check sistemi DC'nin sağlıksız olduğunu görür, fakat DNS sistemi bu sonucu otomatik yansıtmazsa araya script, manuel runbook veya ayrı otomasyon gerekir. Incident anında bu köprü en zayıf halka haline gelir.
Doğru yaklaşım, authoritative DNS, health-check scenario, DC failover ve topology routing kararlarını aynı lokal platformda birleştirmektir. DNS yanıtı, gerçek DC sağlığına ve trafik politikasına göre cihaz üzerinde yeniden üretilmeli; query verisi ve zone içeriği kurum kontrolünde kalmalıdır.
TR7 Lokal GSLB bu modeli sunar: authoritative DNS ve GSLB karar motorunu aynı platformda çalıştırır, veri dışarı çıkmadan DC failover ve coğrafi yönlendirme sağlar.
Yaklaşımımız
TR7, lokal GSLB mimarisini authoritative DNS, dış bulutsuz karar modeli, sağlık senaryosu ve çoklu DC öncelik zinciriyle kurar.
Authoritative DNS ve GSLB tek karar motorunda birleşir
TR7, zone yönetimi ile GSLB kararını ayrı sistemlere bölmez. DNS kaydı, DC sağlığı, topology kuralı ve yanıt üretimi aynı yönetim modeli içinde çalışır.
Zone, query ve geo karar verisi kurum içinde kalır
GeoIP veritabanları lokal çalışır ve DNS sorgu bağlamı karar almak için dış servise gönderilmez. Bu yaklaşım veri yerleşikliği ve egemenlik beklentisi olan kurumlarda önemli avantaj sağlar.
Sağlık senaryosu DNS yanıtını otomatik şekillendirir
DC veya kayıt sağlıksız hale geldiğinde ilgili IP'ler DNS yanıtından otomatik düşebilir. Böylece health-check sonucu ile DNS yanıtı arasında manuel script köprüsü gerekmez.
Multi-DC priority chain felaket ve yedekleme akışlarını yönetir
Her record birden fazla DC kaydı taşıyabilir ve öncelik sırasına göre değerlendirilebilir. Primary, secondary, tertiary veya DR zincirleri tek kayıt modeliyle yönetilir.
Yetenekler
Lokal GSLB, DNS kayıt yönetimini DC sağlığı, topology routing, DNSSEC ve lokal istatistiklerle birlikte sunar.
Authoritative DNS backend lokal kayıt ve karar üretimi sağlar
TR7, authoritative DNS katmanını lokal çalışan kayıt veritabanı ve karar mantığıyla birlikte kullanır. Zone verisi kurum içinde tutulur ve DNS yanıtı lokal platform tarafından üretilir. Bu yapı dış DNS servis bağımlılığını azaltır. Kurum, GSLB politikasını kendi cihazlarında işletir.
35 DNS record tipi geniş zone yönetimi kapsamı sunar
TR7; A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSSEC ilişkili kayıtlar ve diğer gelişmiş record tipleri dahil geniş DNS kayıt kapsamını destekler. Bu, yalnızca basit A kaydı yönlendirmesi değil, tam zone yönetimi için gerekli esnekliği sağlar. Farklı servis ve güvenlik ihtiyaçları aynı DNS yönetim modeline alınabilir. Kurum DNS mimarisini tek noktadan daha tutarlı yönetir.
EDNS Client Subnet coğrafi kararı resolver yerine client subnet'e yaklaştırır
TR7, EDNS Client Subnet bilgisini kullanarak coğrafi kararları yalnızca resolver IP'sine göre vermekten kaçınabilir. Gerçek istemci subnet bilgisi üzerinden DC veya kayıt seçimi yapılabilir. Bu, public resolver kullanan kullanıcıların yanlış bölgeye yönlenme riskini azaltır. Global erişim senaryolarında daha doğru trafik dağıtımı sağlar.
Topology rules ülke, şehir, kıta, ASN ve CIDR kararlarını destekler
TR7 topology kuralları network/CIDR, ülke, şehir, kıta ve ASN boyutlarında DNS yanıtı seçebilir. Her kural pozitif veya negatif koşul olarak yazılabilir. Bu sayede aynı domain farklı coğrafi veya ağ bağlamlarında farklı IP listeleri döndürebilir. Geo routing yalnızca ülke bazlı basit ayrımdan daha hassas hale gelir.
DC priority chain primary ve backup davranışını kayıt seviyesinde yönetir
Her record, DC sırasını içeren recordConfig yapısıyla yönetilebilir. Primary DC sağlıksız olduğunda secondary veya tertiary DC kayıtları devreye alınabilir. Bu model tek kayıt içinde çoklu DC öncelik zinciri kurmayı sağlar. Operatör her domain veya record için farklı süreklilik stratejisi uygulayabilir.
backupBehavior modları passive DC ve stale data riskini kontrol eder
noResponse modu pasif DC'nin normal durumda yanıt vermemesini sağlar. onlyNew modu ise güncel olmayan veya uzun süre kapalı kalmış DC'nin eski veriyle yanıt üretmesini engellemek için kullanılabilir. Bu davranış, yalnızca ayakta olan değil, doğru durumda olan DC'nin DNS yanıtına girmesini hedefler. Failover ve failback süreçlerinde veri tutarlılığı korunur.
Recursive forwarder kurum içi ve dış çözümlemeyi birlikte yönetir
TR7, authoritative DNS yanında recursive forwarder sürecini de çalıştırabilir. Kendi zone'ları lokal authoritative katmana yönlendirilirken, dış domain çözümlemeleri forwarder üzerinden yönetilebilir. domainBasedForwarding ile belirli domainler farklı çözümleme yollarına alınabilir. Bu, kurum içi DNS ve GSLB kararını aynı cihaz ailesinde toplamaya yardımcı olur.
DNSSEC desteği zone bütünlüğünü ve doğrulanabilirliği güçlendirir
TR7 DNSSEC desteğiyle imzalı zone yönetimi sunabilir. NSEC/NSEC3, DNSSEC key cache ve zone signing süreçleriyle DNS yanıtlarının doğrulanabilirliği artırılır. Domain bazında DNSSEC açma veya kapama kararı verilebilir. Bu yapı, kritik domainlerin bütünlük güvenliğini güçlendirir.
AXFR ve IXFR desteği primary secondary DNS mimarisini sürdürür
TR7, primary ve secondary DNS rollerinde zone transfer davranışlarını destekleyebilir. AXFR ve IXFR ile kayıtlar farklı DNS düğümleri arasında taşınabilir. Bu, mevcut kurumsal DNS mimarisine entegrasyonu kolaylaştırır. Lokal GSLB kurulumu, var olan DNS operasyon modelini tamamen terk etmeyi gerektirmez.
Maintenance mode planlı DC bakımını DNS seviyesinde yönetir
Her DC için maintenance mode uygulanabilir. Planlı bakım sırasında DC sağlıklı olsa bile DNS yanıtından çıkarılabilir ve trafik diğer DC'ye yönlendirilebilir. Bakım tamamlandığında normal sağlık senaryosu yeniden devreye alınır. Bu model manuel zone değişikliği yapmadan kontrollü cutover sağlar.
Dinamik DNS update kayıt otomasyonunu destekler
TR7, dinamik DNS update davranışını destekleyerek kayıtların otomasyon sistemleri tarafından güncellenmesine izin verebilir. Bu özellik değişken altyapı, otomatik servis yayınlama veya geçici kayıt ihtiyaçları için değerlidir. Kayıt güncellemeleri GTM karar yapısıyla birlikte değerlendirilebilir. Operasyon ekipleri manuel DNS işlemlerini azaltabilir.
Lokal istatistik ve record counter sorgu görünürlüğünü kurum içinde tutar
TR7, DNS query, cache, rcode, qtype, latency, memory ve uptime gibi istatistikleri toplayabilir. Per-record query count ile hangi kaydın ne kadar sorgu aldığı izlenebilir. Bu veri dış sağlayıcı platformuna gitmeden lokal raporlama ve kapasite planlamasında kullanılabilir. DNS yalnızca yanıt üreten değil, ölçülebilen bir trafik katmanı haline gelir.
Operasyonel derinlik
Lokal GSLB operasyonu; port ayrımları, cache TTL, threading, SOA, istatistik toplama, state dosyaları ve master seçim davranışıyla birlikte işletilir.
İç port ayrımı
TR7 GTM bileşenleri authoritative DNS, API, forwarder inner ve forwarder API süreçleri için ayrı port aralıkları kullanabilir. Bu ayrım servislerin birbirine karışmadan izlenmesini ve yönetilmesini kolaylaştırır. Operasyon ekipleri her bileşenin erişim ve health durumunu ayrı takip edebilir.
Cache TTL davranışı
Query cache, negative query cache, DNSSEC key cache ve zone cache refresh süreleri ana cacheTtl değerinden türetilebilir. Bu yapı performans ile tazelik arasında denge kurar. Daha kısa TTL daha hızlı değişim, daha uzun TTL daha düşük sorgu yükü sağlar.
İş parçacığı ayarı
Signing, distributor, receiver ve retrieval süreçleri CPU çekirdek sayısına göre ölçeklenebilir. Bu yaklaşım yoğun DNS trafiğinde paralel işlem kapasitesini artırır. Threading ayarları donanım kapasitesi ve query profiline göre planlanmalıdır.
Varsayılan SOA davranışı
Yeni zone'lar için varsayılan SOA yapısı refresh, retry, expire ve TTL değerleriyle birlikte oluşturulabilir. Bu değerler DNS operasyonunun temel zamanlama davranışını belirler. Kurumsal gereksinimlere göre SOA değerleri ayrıca gözden geçirilmelidir.
İstatistik toplama hattı
DNS istatistikleri API üzerinden okunup RRD veya benzeri zaman serisi yapısına aktarılabilir. qtype, rcode, cache hit/miss, UDP/TCP sorguları, latency ve bellek kullanımı gibi metrikler izlenir. Bu veriler kapasite planlama ve olay inceleme için kullanılır.
Diskte state persistence
DC bilgisi, lokal health state, scenario state, dynamic config ve zone dynamic config dosya seviyesinde saklanabilir. Restart sonrasında GTM önceki değerlendirme bağlamını geri yükleyebilir. Bu, geçici servis yeniden başlatmalarında gereksiz DNS dalgalanmasını azaltır.
Hangi senaryolarda kullanılır
Finans kurumunda üç DC süreklilik zinciri
Finans kurumları primary, secondary ve tertiary DC zinciri kurabilir. Internet ve erişim health-check senaryoları sağlıksız DC'yi DNS yanıtından çıkararak trafiği yedek DC'ye yönlendirir.
Kamu kurumunda veri dışarı çıkmadan GSLB işletimi
Kamu kurumları zone içeriğini, query loglarını ve geo karar verisini dış DNS servislerine taşımadan GTM çalıştırabilir. Lokal GSLB veri egemenliği ve denetim beklentilerini destekler.
Sağlık sisteminde servis sağlığına bağlı DNS yanıtı
Hastane bilgi sistemleri ve kritik sağlık servisleri health-check scenario ile izlenebilir. Sağlıksız endpoint DNS yanıtından otomatik çıkarılarak manuel müdahale ihtiyacı azaltılır.
Operatör ortamında çoklu DC ve geo yönlendirme
Telekom ekipleri farklı DC veya PoP noktalarını coğrafi ve ağ temelli topology kurallarıyla seçebilir. Client subnet, ülke, ASN veya CIDR bilgisi DNS yanıt kararına dahil edilir.
E-ticarette blue green DNS geçişi
E-ticaret ekipleri weighted kayıt davranışıyla trafiğin küçük bir bölümünü yeni IP grubuna alabilir. Test başarılı oldukça ağırlık artırılarak geçiş kontrollü şekilde tamamlanır.
HA cluster içinde lokal GTM sürekliliği
GTM düğümleri HA cluster içinde master ve yedek rolüyle çalışabilir. Master düşerse yedek düğüm rolü devralarak DNS yanıt üretiminin sürekliliğini korur.
Sık sorulanlar
Lokal GSLB ile SaaS DNS arasındaki temel fark nedir?
Sağlıksız bir DC DNS yanıtından nasıl düşer?
Topology kuralları ne kadar ayrıntılı çalışabilir?
DNSSEC yapılandırması domain bazında yönetilebilir mi?
Mevcut DNS mimarisine entegrasyon nasıl sağlanır?
DNS istatistikleri ve sorgu verisi nerede tutulur?
GSLB kararını kendi veri merkezinize alın
Authoritative DNS, DC failover, coğrafi yönlendirme ve health-check scenario — hepsi kurumun kendi cihazlarında. Kendi altyapınıza uygun bir kurulumu birlikte inceleyelim.