DNS Performansını Ölçmek ve İyileştirmek: Anycast, Çoklu DNS Sağlayıcı ve Health Check Mimarisi

DNS Performansını Neden Ciddiye Almalısınız?

Web siteniz veya API’niz ne kadar iyi optimize edilmiş olursa olsun, ziyaretçinin tarayıcısının ilk yaptığı şey her zaman DNS sorgusudur. Sunucu tarafında saniyeler kazandıran optimizasyonlar yapıp, DNS tarafında onlarca milisaniyeyi çöpe atmak çok sık gördüğümüz bir durum. DCHost ekibi olarak kapasite planlama ve mimari tasarım toplantılarında artık DNS’i, TTFB ve veritabanı performansı kadar kritik bir girdi olarak ele alıyoruz. Çünkü özellikle çok bölgeli trafik alan, e‑ticaret yapan veya SLA’si yüksek projelerde DNS tarafındaki her küçük iyileştirme, gerçek para ve itibar olarak geri dönüyor.

Bu yazıda, DNS performansını nasıl doğru ölçeceğinizi, ortaya çıkan veriyi nasıl okuyacağınızı ve ardından Anycast, çoklu DNS sağlayıcı ve health check tabanlı otomatik failover mimarileriyle bu performansı nasıl seviyeye atlayacağınızı adım adım anlatacağız. Amaç; teorik bir sunum değil, doğrudan uygulanabilir bir yol haritası vermek. Çoğu örneği DCHost altyapısında ve müşterilerimizde gördüğümüz gerçek senaryolardan yola çıkarak aktaracağız.

DNS Performansını Ölçerken Hangi Metriklere Bakmalısınız?

DNS performansını konuşurken tek bir “sorgu süresi” metriğine bakmak genellikle yanıltıcıdır. Sağlıklı bir analiz için en azından aşağıdaki başlıkları birlikte değerlendirmeniz gerekir:

• Çözümleme gecikmesi (query latency): Kullanıcının kullandığı resolver’dan authoritative nameserver’ınıza gidiş‑geliş süresi.
• İlk sorgu vs. cache’den gelen sorgu: Soğuk (uncached) ve sıcak (cached) sorgu sürelerinin ayrıştırılması.
• Hata oranı: SERVFAIL, NXDOMAIN, REFUSED gibi hataların oranı ve dağılımı.
• Bölgesel gecikme farkları: Türkiye’den, Avrupa’dan, Amerika’dan ve mümkünse Asya’dan gelen sorguların karşılaştırılması.
• TTL etkisi: Çok düşük veya çok yüksek TTL değerlerinin cache davranışına gerçek etkisi.
• Kararlılık (jitter): Ortalama değerler kadar, zaman içindeki dalgalanmaların da izlenmesi.

TTL özelinde daha önce ayrıntılı bir rehber hazırlamıştık. DNS tarafında değişiklik yapmadan önce ve sonra etkisini anlamak için DNS TTL değerlerini stratejik şekilde ayarlama rehberimize göz atmanız faydalı olacaktır.

İlk Adım: Baz Ölçüm (Baseline) Oluşturmak

Herhangi bir iyileştirmeye başlamadan önce, mevcut durumunuzu en az 7–14 gün boyunca ölçüp bir “baz değer” çıkarın. Sadece tek bir test aracının ekran görüntüsüyle karar vermek, bizi sahada çok kez yanlış yönlendirdi. Aşağıdaki yaklaşım işinizi kolaylaştırır:

• Farklı lokasyonlardan (en az Türkiye, Avrupa, Amerika) DNS sorgu sürelerini toplayın.
• Günün farklı saatlerinde ölçüm alın; sadece ofis saatlerine bakmayın.
• Farklı ISP’ler üzerinden (örneğin kurumsal ofis, ev interneti, mobil bağlantı) test yapın.
• Alan adınızın A/AAAA, MX ve kritik CNAME kayıtları için ölçüm sonuçlarını ayrı ayrı kaydedin.

Bu baz değer, Anycast’e geçtikten veya çoklu DNS sağlayıcı yapısı kurduktan sonra topladığınız yeni metriklerle karşılaştırma yapmanızı sağlayacak. DCHost’ta mimari değişiklik projelerinde, bu baz‑ölçüm aşamasını atlamayı neredeyse yasak kabul ediyoruz; aksi halde yapılan iyileştirmenin gerçekten işe yarayıp yaramadığını objektif olarak görmek imkansızlaşıyor.

DNS Performansını Test Edebileceğiniz Pratik Araçlar

Çok karmaşık SaaS’lara girmeden önce, terminal ve basit izleme araçlarıyla oldukça iyi bir resim çıkarabilirsiniz.

Komut Satırı Araçları: dig, kdig, drill

En temel ve güvenilir ölçüm, doğrudan authoritative nameserver’ınızla konuşan araçlarla yapılır:

• dig example.com A: Varsayılan resolver üzerinden genel bir sorgu süresi verir.
• dig @NS-SUNUCUNUZ example.com A: Doğrudan authoritative sunucuya giderek altyapınızın gerçek gecikmesini görürsünüz.
• +trace parametresi ile kök sunucudan itibaren zinciri izleyebilir, hangi adımda gecikme oluştuğunu görebilirsiniz.

Benzer şekilde kdig veya drill de detaylı zamanlama bilgileri verir. Buradaki amaç, resolver cache etkisini dışarıda bırakıp, DNS altyapınızın “ham” performansını görebilmek.

Bölgesel Testler ve RIPE Atlas Benzeri Ölçümler

Eğer projeniz farklı ülkelerden ciddi trafik alıyorsa, tek noktadan ölçüm yapmak genellikle yetersiz kalır. Farklı bölgelerde çalışan prob’larla (örneğin RIPE Atlas benzeri ağlar üzerinden) şu sorulara yanıt ararsınız:

• Türkiye’de 15 ms olan sorgu süresi, ABD’den bakıldığında 120 ms’ye mi çıkıyor?
• Avrupa’daki belli bir ISP, authoritative DNS’inize anlık rota problemleriyle mi ulaşıyor?
• Anycast’e geçtiğinizde, en uzak bölgedeki kullanıcılar için gecikme ne kadar azalıyor?

Bu metrikler, sadece DNS mimarinizi değil, genel network stratejinizi de gözden geçirmenizi sağlar. Sunucu ve network performansını daha geniş perspektifte ele almak isterseniz, TTFB, network ve gerçek benchmark odaklı teknik karşılaştırma rehberimize de göz atabilirsiniz.

Sürekli İzleme: Bir Kerelik Test Yeterli Değil

DNS performansı sabit bir değer değildir; network dalgalanmaları, BGP değişiklikleri, DDoS atakları ve bakım çalışmalarıyla sürekli oynar. Bu yüzden:

• Birkaç dakikada bir çalışan basit DNS sorgu health check’leri kurun.
• Hem çözümleme süresini hem de hata kodlarını loglayın.
• “Spikes” (kısa süreli sıçramalar) ile sürekli yavaşlıkları grafikte ayırt edin.

DCHost’ta yüksek SLA hedefi olan müşteriler için, DNS gecikmesini de dahil eden merkezi izleme ve alarm senaryoları kuruyoruz. Detaylı bir izleme mimarisi kurmak istiyorsanız, merkezi izleme ve alarm mimarisi rehberimizde benzer yaklaşımları sunucu tarafı için de anlattık; benzer prensipler DNS için de geçerli.

Anycast DNS ile Gecikmeyi Azaltmak ve Dayanıklılığı Artırmak

Anycast DNS’in özünü tek cümlede şöyle özetleyebiliriz: Aynı IP adresini dünya genelinde birden fazla DNS sunucusuna yayar, kullanıcının en yakın sunucuya yönlenmesini sağlarsınız.

Unicast mimaride, ns1.example.com için tek bir IP adresi ve tek bir fiziksel lokasyon vardır. Kullanıcı nerede olursa olsun, tüm sorgular o noktaya gider. Anycast’te ise aynı IP adresi, örneğin İstanbul, Frankfurt ve Amsterdam’daki DNS sunucularınızda eş zamanlı olarak anons edilir; BGP yönlendirme protokolü trafik yolunu otomatik olarak en “yakın” olana çeker.

Anycast DNS’in Somut Avantajları

• Daha düşük gecikme: Kullanıcıların büyük bölümü coğrafi olarak en yakındaki POP’a (Point of Presence) düşer.
• Daha yüksek dayanıklılık: Bir POP tamamen devre dışı kalsa bile, aynı IP’yi anons eden diğer POP’lar sorguları cevaplamaya devam eder.
• DDoS dağıtımı: Saldırı trafiği tek noktaya yığılmak yerine, birden fazla POP’a dağılır; absorbe etmesi daha kolay olur.
• Basit konfigürasyon: Uygulamalarınız tarafında tek bir nameserver IP’si kullanırsınız; Anycast karmaşıklığı tamamen ağ katmanında kalır.

DCHost tarafında kurumsal DNS altyapımızı tasarlarken, Türkiye ve Avrupa’daki ziyaretçiler için gecikmeyi minimize edecek şekilde Anycast destekli nameserver’lar kullanıyoruz. Böylece aynı DNS IP’si, farklı veri merkezlerimizde çalışan redundant sunucular tarafından cevaplanıyor.

Anycast Kullanırken Dikkat Edilmesi Gerekenler

Anycast her derde deva değil; doğru planlanmazsa yeni problemler üretebilir:

• BGP ve network uzmanlığı: Anycast, BGP yönlendirmesine dayanır. Yanlış anonslar, trafik döngüleri veya beklenmedik route’lar ciddi sorun çıkarabilir.
• Monitoring karmaşıklığı: Her POP’u ayrı ayrı izleyip, sorun yaşayan POP’u hızla devre dışı bırakacak otomasyon (veya network operasyon süreci) kurmanız gerekir.
• Veri tutarlılığı: Anycast DNS sunucularınızın tamamında aynı zone verisinin anlık olarak senkronize olduğundan emin olmalısınız.

Bu noktada, Anycast DNS ve otomatik failover mimarisini detaylandırdığımız yazıya göz atmanız, konseptleri kafanızda oturtmak için oldukça faydalı olacaktır.

Çoklu DNS Sağlayıcı Mimarisi: Vendor Lock-in’e Karşı Sigorta

Tek bir DNS sağlayıcısına bağlı kalmak; kısa kesintiler, panel sorunları veya hukuki/regülasyon kaynaklı problemler yaşandığında büyük risk oluşturur. DCHost olarak özellikle kritik projelerde, çoklu DNS sağlayıcı (multi‑provider DNS) modelini ciddi şekilde öneriyoruz.

Çoklu Sağlayıcı DNS Nedir?

Basitçe söylemek gerekirse, aynı domain için birden fazla bağımsız DNS altyapısı çalıştırırsınız. Örneğin:

• ns1/ns2 bir sağlayıcıda,
• ns3/ns4 farklı bir sağlayıcıda bulunur.

Alan adınızın NS kayıtları bu dört sunucuyu da gösterir. Resolver’lar rastgele veya performansa göre bu sunuculardan birine istek gönderir. Bir sağlayıcı tamamen devre dışı kalsa bile, diğer sağlayıcı sorguları cevaplamaya devam eder.

Bu yaklaşım, sadece performans değil, vendor lock‑in riskini azaltma açısından da çok değerlidir. Konuyu daha geniş çerçevede ele aldığımız hosting ve domain’de vendor lock‑in riskini azaltma rehberimize mutlaka göz atmanızı öneririz.

Aktif/Aktif ve Aktif/Pasif Modeller

Çoklu DNS sağlayıcı kurarken iki ana model vardır:

• Aktif/Aktif: Tüm sağlayıcılarda aynı anda sorgu cevaplanır. Avantajı, yük ve riskin dağıtılmasıdır. Dezavantajı, zone senkronizasyonunun daha karmaşık hale gelmesidir.
• Aktif/Pasif: Bir sağlayıcı ana, diğeri sadece yedektir. Genelde NS kayıtları ağırlıklandırılarak (veya farklı otomasyonlarla) trafiğin çoğu ana sağlayıcıya yönlendirilir. Sorun anında yedek devreye girer.

DCHost olarak, orta ve büyük projelerde genellikle aktif/aktif yapıyı tercih ediyoruz; böylece hem performans hem de dayanıklılık kazanılıyor. Ancak daha basit senaryolarda aktif/pasif model de gayet yeterli olabiliyor.

Zone Yönetimi ve Otomasyon (octoDNS vb.)

Çoklu sağlayıcı yapısında en kritik konu, DNS kayıt senkronizasyonudur. Farklı panellerde elle değişiklik yapmak kaçınılmaz olarak hata ve tutarsızlık üretir. Bu yüzden konfigürasyonu kod gibi ele almak çok daha sağlıklı:

• DNS kayıtlarınızı bir YAML/JSON repo içinde tanımlarsınız.
• CI/CD pipeline’ı, bu tanımı her sağlayıcının API’sine push eder.
• Değişiklikler otomatik olarak tüm sağlayıcılara aynı anda yayılır.

Bu modele yönelik kapsamlı bir rehberi, çoklu sağlayıcı DNS ve octoDNS kullanımı üzerine hazırladığımız yazıda bulabilirsiniz. Orada zero‑downtime geçiş ve dayanıklılık tarafını ayrıca detaylandırdık.

DNSSEC, CAA ve Diğer Gelişmiş Kayıtlar

Çoklu sağlayıcı mimarisinde unutulmaması gereken iki hassas başlık daha var:

• DNSSEC: İki sağlayıcının da DNSSEC desteği uyumlu olmalı; KSK/ZSK anahtar yönetimi ve DS kayıt güncellemeleri dikkatle tasarlanmalıdır.
• CAA kayıtları: Hangi sertifika otoritelerinin domain’iniz için sertifika üretebileceğini belirleyen CAA kayıtları, tüm sağlayıcılarınızda aynı olmalıdır. Aksi halde bazı istekler DNS üzerinden farklı cevaplar görebilir ve beklenmedik hatalar oluşur.

DCHost’ta SSL otomasyonu yaparken, CAA kayıtlarını da sürecin bir parçası olarak ele alıyor, çoklu DNS sağlayıcı senaryolarında bu kayıtların tutarlı kalmasını özellikle denetliyoruz.

Health Check ve DNS Tabanlı Otomatik Failover Mimarisi

DNS’i sadece “adres defteri” gibi görmek artık güncel bir bakış açısı değil. Doğru kurgulanmış bir health check ve otomatik failover mimarisiyle, DNS katmanı aktif bir trafik yöneticisine dönüşebilir.

Health Check Nedir, Ne Ölçmelidir?

DNS health check’leri basitçe şu soruyu sorar: “Bu kayıt üzerinden işaret ettiğim hedef gerçekten sağlıklı mı?” Ama sadece ICMP ping veya TCP port açık mı testiyle yetinmek genellikle yetersizdir. DCHost olarak aşağıdaki katmanlarda health check kurgulamayı tercih ediyoruz:

• L3/L4: IP’ye ping atmak, TCP portunun (80/443 vb.) açık olduğunu doğrulamak.
• L7: Belirli bir URL’e HTTP(S) isteği atıp, hem durum kodunu hem de cevap içeriğini kontrol etmek (örneğin “/health” endpoint’i).
• Uygulama mantığı: Örneğin e‑ticaret sitesinde sepet veya ödeme akışına özel sentetik testler yapmak.

Bu health check sonuçlarına göre DNS kayıtlarınız dinamik olarak güncellenebilir. Bir node çökerse, o node’a işaret eden A/AAAA kayıtları devre dışı kalır; trafiğiniz otomatik olarak ayakta kalan node’lara akar.

DNS Failover’ın Temel Prensipleri

DNS failover kurgularken şu noktalar kritik önem taşır:

• TTL Değerleri: Çok yüksek TTL, failover’ı yavaşlatır; çok düşük TTL, resolver ve authoritative yükünü gereksiz yere artırır. Kritik kayıtlar için orta seviyede (örneğin 30–120 saniye) TTL’ler genellikle iyi bir dengedir.
• Health check sıklığı: Çok sık kontrol, gereksiz yük ve yanlış pozitiflere; çok seyrek kontrol, geç failover’a neden olur. Tipik olarak 10–30 saniyelik aralıklar iyi çalışır.
• Flapping önleme: Bir node’un kısa süreli gidip gelmesinde hemen failover yapmamak için “consecutive failures” ve “recovery threshold” mekanizmaları kurun.

TTL ve yayılım süresi konusunu daha önce detaylı ele aldığımız zero‑downtime taşıma ve TTL stratejileri rehberimiz, DNS failover tasarlarken mutlaka okunması gereken tamamlayıcı bir içerik.

Anycast + Health Check + Çoklu Sağlayıcı: Üç Katmanlı Dayanıklılık

Olgun bir DNS mimarisinde, bu üç yaklaşımı birlikte görmeyi seviyoruz:

1. Anycast: Kullanıcıyı en yakın DNS POP’una getirip gecikmeyi düşürür.
2. Health check tabanlı failover: Aynı sağlayıcı içindeki farklı origin IP’ler arasında otomatik geçiş yapar.
3. Çoklu DNS sağlayıcı: Sağlayıcı tarafında yaşanacak geniş çaplı kesintilere karşı sigorta görevi görür.

Böyle bir kurgu sayesinde, tek bir veri merkezinin, tek bir sağlayıcının veya tek bir DNS POP’unun problemi, son kullanıcı açısından çoğu zaman fark edilmeyen kısa dalgalanmalar olarak kalır. DCHost tarafında yüksek SLA isteyen müşteriler için bu üç katmanı birlikte düşünerek tasarım yapıyoruz.

Küçük ve Orta Ölçekli Projeler İçin Örnek Mimari

“Bunların hepsi güzel ama benim sitem orta ölçekli, gerçekten hepsine ihtiyacım var mı?” sorusunu çok duyuyoruz. Cevap: Her şeyi bir gecede kurmak zorunda değilsiniz; kademeli gitmek hem daha güvenli hem de bütçe dostu.

Aşama 1: Mevcut DNS’inizi Ölçün ve TTL’leri İyileştirin

• Önce mevcut DNS sağlayıcınızla detaylı bir performans ölçümü yapın.
• Kritik A/AAAA, MX ve API alt alan adları için TTL’leri gözden geçirin.
• Yakın gelecekte DNS tabanlı geçiş veya failover planlıyorsanız, bu kayıtların TTL değerlerini kademeli olarak düşürün.

Bu aşamada, DNS yayılım süresi nasıl hızlandırılır yazımızda anlattığımız pratikler de işinize yarayacaktır.

Aşama 2: Anycast Destekli DNS’e Geçiş

İkinci aşamada hedef, tek sağlayıcı da olsa Anycast destekli, bölgesel POP’ları olan bir DNS mimarisine geçmek. Bu sayede:

• Türkiye ve yakın bölgelerde sorgu süreleriniz düşer.
• Tek veri merkezi arızası, DNS tarafında tam kesinti anlamına gelmez.

DCHost altyapısında, Türkiye odaklı ama aynı zamanda Avrupa’dan da trafik alan projeler için, Anycast DNS ile gecikmeyi ciddi oranda düşürdüğümüz çok sayıda senaryo gördük. Özellikle mobil trafik oranı yüksek sitelerde etkisi net şekilde hissediliyor.

Aşama 3: Health Check ve Basit Failover

Bu aşamada hala tek DNS sağlayıcı kullanıyor olabilirsiniz; sorun değil. Ancak DNS sağlayıcınızın sunduğu health check + failover özellikleri varsa, en azından iki origin IP arasında geçiş yapacak basit bir kurgu kurabilirsiniz:

• Birincil web sunucunuz DCHost üzerinde bir VPS veya dedicated sunucu olsun.
• İkincil sunucuyu daha hafif kaynaklarla, sadece acil durumlarda devreye girecek şekilde planlayın.
• DNS kayıtlarınızı, health check başarısız olduğunda otomatik olarak ikincil IP’ye işaret edecek şekilde yapılandırın.

Burada TTL değerlerini, failover hızını ve veri senkronizasyonunu dikkatle test etmeniz şart. Biz DCHost tarafında bu geçişleri planlarken staging ortamlarında defalarca prova yapmadan canlıya almıyoruz.

Aşama 4: Çoklu Sağlayıcı DNS ile Son Katmanı Eklemek

Son aşamada, Anycast + health check kurgunuzu ikinci bir DNS sağlayıcı ile çoğaltırsınız. Bunu yaparken:

• Tüm DNS kayıtlarınızı kod olarak yöneten bir repo oluşturun (örneğin octoDNS).
• CI/CD üzerinden her iki sağlayıcının API’lerini besleyin.
• Her iki sağlayıcıda da aynı health check ve failover mantığını inşa edin.

Böylece DNS tarafında olgun, test edilmiş ve otomasyona dayalı bir mimari elde etmiş olursunuz. Çoklu sağlayıcı tarafındaki detayları tekrar hatırlamak için, yukarıda bahsettiğimiz octoDNS ile çoklu sağlayıcı DNS rehberine geri dönebilirsiniz.

DCHost Perspektifinden Uygulanabilir Yol Haritası (30–60–90 Gün)

Teoride her şey güzel; peki pratikte bu dönüşümü nasıl zamana yayabilirsiniz? DCHost’ta müşterilerimizle çalışırken sık kullandığımız 30–60–90 günlük bir çerçeveyi özetleyelim.

İlk 30 Gün: Ölçüm, Envanter ve Hızlı Kazanımlar

• Mevcut DNS sağlayıcınız, NS kayıtlarınız ve TTL değerlerinizin envanterini çıkarıyoruz.
• Farklı bölgelerden DNS sorgu gecikmesi ve hata oranlarını ölçüp baz değer oluşturuyoruz.
• Kritik kayıtlar için çok yüksek TTL’leri aşağı çekip, hızlı kazanım sağlayacak düzenlemeler yapıyoruz.

60 Gün İçinde: Anycast ve Health Check Pilotları

• Anycast destekli DNS’e geçiş veya mevcut Anycast altyapınızın performans testini planlıyoruz.
• Seçili bir alt alan adında (örneğin beta.example.com) health check + failover pilotu kurguluyoruz.
• Bu pilot üzerinden hem performans hem de kararlılık verisi toplayıp optimizasyon yapıyoruz.

90 Gün İçinde: Çoklu Sağlayıcıya Hazırlık ve Otomasyon

• DNS kayıtlarınızı kod olarak yönetmek için depo ve pipeline tasarlıyoruz.
• İkinci bir DNS sağlayıcı için NS planı, zone senkronizasyonu ve failover senaryolarını birlikte yazıyoruz.
• Canlı geçişi, TTL stratejileriyle destekleyip zero‑downtime yaklaşımıyla gerçekleştiriyoruz.

Bu sürecin tamamında asıl hedef; karmaşık, insan hatasına açık panel operasyonlarından uzaklaşıp, test edilebilir ve geri alınabilir (rollback’li) bir DNS mimarisi kurmak. Zaten DNS ve domain taşıma kontrol listesi yazımızda da benzer bir yaklaşımı barındırma geçişleri için anlatmıştık; DNS performansı ve dayanıklılığı da aynı zihniyetle ele alınmalı.

Özet ve Sonuç: DNS’i Artık Altyapının Merkezine Çekme Zamanı

DNS, uzun yıllar boyunca “bir kez ayarlayıp unuttuğumuz” bir bileşen olarak görüldü. Ancak günümüzün çok bölgeli, yüksek trafik alan ve kesintiye toleransı düşük projelerinde, DNS’in performans ve dayanıklılık üzerindeki etkisi doğrudan hissediliyor. DCHost’ta sahada gördüğümüz tablo net: DNS tarafında yapılan iyileştirmeler, çoğu zaman uygulama optimizasyonlarından bile daha hızlı geri dönüş sağlıyor.

Bu yazıda DNS performansını nasıl ölçeceğinizi, Anycast ile gecikmeyi nasıl azaltacağınızı, çoklu DNS sağlayıcı ile vendor lock‑in ve altyapı risklerini nasıl düşürebileceğinizi ve health check tabanlı otomatik failover mimarisiyle gerçek anlamda yüksek erişilebilirlik elde edebileceğinizi anlattık. Şimdi sırada, kendi alan adlarınız ve projeleriniz için bu adımları planlamak var.

Eğer DNS mimarinizi gözden geçirmek, Anycast veya çoklu sağlayıcıya geçiş planı yapmak ya da health check tabanlı failover kurgusunu birlikte tasarlamak isterseniz, DCHost ekibi olarak buradayız. Mevcut domain, hosting, VPS, dedicated sunucu veya colocation altyapınızı bozmadan, kademeli ve test edilebilir bir yol haritası çıkaralım; DNS’i gerçekten hak ettiği yere, altyapınızın merkezine birlikte çekelim.