DNS İzleme Araçları ve Hata Tespiti için Uygulamalı Rehber

Sharing is caring!

DNS kesintisi sandığından daha kritik

Bir sabah uyanıyorsun, siteye kimse giremiyor ama sunucu ayakta. CPU normal, veritabanı çalışıyor, ping atınca cevap geliyor. Buna rağmen kullanıcıların sadece boş bir sayfa ya da tarayıcı hatası görüyor. Çoğu senaryoda suçlu, arkada sessizce patlayan bir DNS problemi oluyor.

Böyle durumlarda panikle her yeri kurcalamak yerine, baştan doğru kurgulanmış dns izleme araçları kullanıyorsan iş oldukça rahatlıyor. Çünkü sorun üretime tam yansımadan önce gecikmeleri, hatalı kayıtları ve global kesintileri fark etme şansın oluyor. Sonuç: Daha az stres, daha az itibar kaybı ve daha az gelir kaybı.

İnternette her şey DNS ile başlıyor. Bu yüzden DNS tarafında yaşanan küçücük bir hata bile, uygulama katmanında dev bir felaket gibi görünebiliyor. O yüzden DNS görünmüyor diye hafife alan ekipler genelde en çok zorlanan ekipler oluyor.

DNS nasıl çalışıyor, nerede hata aramalısın?

DNS’i klasik “internetin telefon rehberi” benzetmesiyle anlatmak kolay, ama pratikte birkaç katman daha var. Tarayıcıya alan adını yazdığında; önce cihazındaki resolver devreye giriyor, oradan ISS’nin DNS sunucuları, oradan root ve TLD sunucuları, en sonunda da alan adının authoritative DNS’ine ulaşılıyor.

Bu yolculukta şu adımların her biri potansiyel hata noktası:

• Cihaz veya işletim sistemi DNS ayarları
• Yerel ağdaki modem veya kurumsal DNS sunucuları
• İnternet servis sağlayıcının resolver’ları
• Alan adının yetkili (authoritative) DNS sağlayıcısı
• Yanlış, eksik ya da gecikmeli DNS kayıtları

Gerçekte yaşadığın sorun “site açılmıyor” olsa da, kök sebebi anlamak için bu katmanların hangisinde problem olduğunu görmen gerekiyor. İşte burada sistematik bir yaklaşım ve doğru araç seti çok işe yarıyor.

DNS hatası nasıl bulunur sorusuna sistematik bir cevap

“DNS hatası nasıl bulunur?” diye düşünürken herkesin aklına genelde tek bir komut geliyor: ping. Fena bir başlangıç değil ama tek başına yeterli değil. Daha net bir yol haritası çizmek çok daha faydalı.

1. En temel erişim ve çözümleme kontrolleri

İlk adımda amacın, sorunun sadece sende mi yoksa globalde mi olduğunu anlamak olmalı. Bunun için:

• Farklı bir cihazdan ve farklı bir ağdan (mobil veri gibi) deneme yap
• Alan adını IP adresiyle doğrudan açmayı dene (DNS mi, uygulama mı anlamak için)
• Tarayıcıdan değil, curl veya benzeri araçlarla isteği test et

Eğer IP ile doğrudan erişiyorsun ama alan adıyla gidemiyorsan, neredeyse kesin şekilde DNS tarafına odaklanabilirsin.

2. Komut satırı ile detaylı DNS çözümleme

Komut satırı araçları, “dns hatası nasıl bulunur” sorusunun en pratik cevaplarından biri. En sık kullanılanlar:

• dig: DNS sorgularını detaylı görmene yarar
• nslookup: Hızlı ve basit sorgular için kullanışlıdır
• host: Özellikle ters çözümleme (reverse lookup) için çok pratik

Örneğin bir alan adı için hangi kayıtların döndüğünü görmek istiyorsan şöyle bir komut yeterli olabilir:

# A kaydı kontrolü
dig example.com A +trace # NS kayıtlarını gör
dig example.com NS

Bu sorgular sayesinde, alan adının gerçekten doğru IP’ye mi gittiğini, yetkili DNS sunucularının kimler olduğunu ve propagasyonun nerede takıldığını anlayabilirsin.

3. Farklı lokasyonlardan DNS durumu kontrolü

Bir başka kritik nokta da şu: Senin bulunduğun yerde DNS düzgün çalışıyor olabilir, ama başka bir ülkede sorun yaşanıyor olabilir. Globalde hizmet veriyorsan bu, fark edilmesi zor bir tuzak.

Bunu yakalamak için tarayıcı tabanlı pek çok servis var. Farklı ülkelerdeki resolver’lar üzerinden alan adının çözülüp çözülmediğini, hangi IP’ye gittiğini ve ne kadar sürede yanıt aldığını gösteriyorlar. Kısacası, dünya turuna çıkmadan dünya çapındaki DNS durumunu görebiliyorsun.

4. DNS sağlayıcının paneli ve log’lar

DNS sağlayıcının panelini pasif bir ayar ekranı gibi görmemek lazım. Birçok modern sağlayıcı, sorgu sayıları, hata oranları, gecikme süreleri ve hatta saldırı benzeri anomalileri grafiklerle gösteriyor.

Bizim ekipte genelde sorun çıktığında ilk baktığımız yer şu metrikler oluyor:

• Son saatlerdeki toplam DNS sorgusu grafiği
• NXDOMAIN, SERVFAIL gibi hata kodlarının oranları
• Belirli bir kayda (örneğin API alt alan adı) gelen sorgu patlamaları

Bu grafikleri düzenli takip edersen, DNS tarafında yavaş yavaş biriken problemleri daha patlamadan yakalama şansın olur.

DNS izleme araçları ile görünmeyeni görünür yapmak

El yordamıyla ara ara dig çalıştırmak, sorun çıktığında hayat kurtarabilir. Ama 7/24 çalışan sistemler için bu yaklaşım yetersiz kalıyor. Gözünün görmediği, elinin değmediği saatlerde de kontrollerin otomatik devam etmesi gerekiyor. Tam bu noktada sürekli çalışan dns izleme araçları devreye giriyor.

İyi tasarlanmış bir DNS izleme senaryosu sana şunları sağlar:

• DNS yanıt süresindeki ani artışları fark etme
• Farklı bölgelerden gelen sorgu gecikmelerini kıyaslama
• Belirli kayıtların (örneğin mail veya API) aniden kaybolmasını yakalama
• Yanlış IP’ye giden ya da silinmiş kayıtları tespit etme

Bunların hepsini manuel kontrol etmek imkansız. Ancak doğru aracı bir kere kurduğunda, arka planda devamlı olarak senin yerine kontrol yapan küçük robotlar olduğunu düşünebilirsin.

Bulut tabanlı yönetilen DNS izleme araçları

Bulut tabanlı çözümler, özellikle ekibi küçük olan ya da hızlı ilerlemek isteyenler için süper pratik. Bu tip servislerin ortak avantajları şöyle özetlenebilir:

• Birden fazla lokasyondan düzenli DNS sorgusu yaparlar
• DNS yanıt kodlarını (NOERROR, NXDOMAIN, SERVFAIL vb.) sürekli takip ederler
• Belirlediğin eşiğin üzerine çıkıldığında e-posta, SMS veya Slack ile uyarı gönderirler
• Geçmişe dönük grafik ve raporlarla trendleri görmeni sağlarlar

Yani sadece “şu anda bir problem var mı” değil, “son 30 gündür DNS performansım nasıl gidiyor” sorusuna da cevap alırsın. Bu da özellikle dns kesinti takibi yaparken kök sebepleri araştırmak için çok değerli.

Açık kaynak ve komut satırı odaklı izleme çözümleri

Daha kontrolcüysen veya maliyeti düşük tutmak istiyorsan, açık kaynak çözümlerle de gayet sağlam bir DNS izleme altyapısı kurabilirsin. Örneğin:

• Mevcut bir monitoring sistemi (Prometheus, Zabbix, Icinga gibi) kullanıp DNS sorgularını metrik olarak toplamak
• Basit bash script’leri ile düzenli dig sorguları çalıştırıp sonuçları log’lamak
• Grafana gibi bir araçla bu metrikleri görselleştirmek

Kısacası, elinde zaten bir gözlem ve uyarı sistemi varsa, DNS’i bu sisteme ekstra bir “hedef” olarak ekleyebilirsin. Ekstra bir platform öğrenmek zorunda kalmazsın.

DNS kesinti takibi için kritik stratejiler

DNS’i sadece “çalışıyor mu, çalışmıyor mu” diye takip etmek yeterli değil. Asıl önemli olan, kesintinin şekline ve kullanıcıya etkisine göre doğru metrikleri izlemek. dns kesinti takibi yaparken işine yarayacak birkaç stratejiyi toparlayalım.

Sürekli çalışan sentetik DNS testleri

Sentetik test, gerçek kullanıcıdan gelmeyen ama gerçek bir kullanıcı davranışını taklit eden istektir. DNS özelinde bu, belirlediğin aralıklarla alan adına sorgu atıp sonucu kaydetmek anlamına geliyor.

Sürekli çalışan sentetik testlerle şunları izlemen mümkün:

• Belirli alt alan adlarının (örneğin api.example.com) her zaman çözülüp çözülmediği
• Yanıt süresinin belli bir sınırın üzerine çıkıp çıkmadığı
• Yanıtın beklediğin IP adreslerine gidip gitmediği

Böylece bir gün ansızın kayıtların silinmesi, yanlış IP’ye yönlenmesi veya bazı resolver’ların aşırı yavaşlaması gibi senaryoları çok erken fark edebilirsin.

Hem dış hem iç DNS katmanını izlemek

Birçok ekip sadece alan adının dış DNS kayıtlarını izlemekle yetiniyor. Oysa kurumsal ağlarda iç DNS katmanı da en az dışarıdaki kadar kritik.

Örneğin ofis içindeki cihazların şirket içi servisleri bulabilmesi için kullanılan internal DNS sunucuların da takibi şart. Buradaki bir kesinti, dış kullanıcıların değil ama tüm ekibin aynı anda durmasına neden olabilir.

Bu yüzden dns kesinti takibi yaparken mutlaka şu ayrımı koru:

• Dış kullanıcıların kullandığı authoritative DNS ve public kayıtlar
• Şirket içi uygulamaların kullandığı internal DNS altyapısı

İki tarafta da ayrı ayrı metrik ve uyarı tanımlamak, hangi katmanda problem çıktığını çok daha hızlı anlamanı sağlar.

TTL ve propagasyon davranışını anlamak

TTL, yani “time to live” değeri DNS dünyasında ince ayar gibidir. TTL’yi çok yüksek tutarsan değişikliklerin internet genelinde yayılması uzun sürer; çok düşük tutarsan ise resolver’lar sürekli sorgu atar, yük artar.

İyi bir dns izleme stratejisi, TTL davranışını da hesaba katar. Örneğin büyük bir değişiklikten önce TTL’leri planlı şekilde düşürüp, değişiklik sonrası tekrar yükseltmek yaygın bir taktiktir. Bunu izleme panellerinde anlık sorgu sayısı ve cache isabet oranlarına bakarak doğrulayabilirsin.

Kendi basit DNS izleme kurgunu kurmak

Profesyonel bir platforma bütçe ayırmadan da iş görecek bir temel kurgu oluşturulabilir. Küçük projelerde ya da kişisel deney ortamlarında biz genelde şu tarz bir setup öneriyoruz.

1. Temel komutlarla düzenli kontrol

Önce çekirdekten başlayalım. Basit bir sunucuda ya da VPS üzerinde aşağıdaki gibi bir cron job ile düzenli DNS kontrolü yapabilirsin:

# 5 dakikada bir DNS kontrolü yapan basit örnek
*/5 * * * * /usr/local/bin/check_dns.sh

check_dns.sh dosyasının içeriği de şöyle olabilir:

#!/usr/bin/env bash
DOMAIN="example.com"
EXPECTED_IP="203.0.113.10" RESULT_IP=$(dig +short "$DOMAIN" A | head -n 1) if [ "$RESULT_IP" != "$EXPECTED_IP" ]; then echo "$(date) DNS kaydı beklenenden farklı: $RESULT_IP" >> /var/log/dns_check.log
fi

Bu, en basit haliyle bile seni beklenmedik kayıt değişikliklerine karşı uyarabilir. Üzerine mail ya da chat entegrasyonu ekleyerek işin uyarı kısmını da otomatikleştirebilirsin.

2. Var olan monitoring sistemine DNS eklemek

Zaten bir izleme altyapın varsa, örneğin Prometheus veya Zabbix gibi, DNS sorgularını da bu ortama eklemek çok mantıklı. Genelde yapılabilecekler şöyle:

• Belirli aralıklarla çalışan DNS probe’ları tanımlamak
• Yanıt süresi, hata oranı ve yanıt kodu için metrik toplamak
• Belirlediğin eşikleri aşınca alarm ürettirmek

Avantajı şu: Tüm altyapı metriklerin tek bir yerde toplanır. Uygulama hatası mı, ağ problemi mi, yoksa DNS mi? Hepsini tek bir dashboard üzerinden karşılaştırabilirsin.

3. Web tabanlı DNS izleme panelleri

Eğer komut satırıyla uğraşmak istemiyorsan, tamamen web üzerinden yönetilen paneller de kullanabilirsin. Bu panellerde genelde:

• Alan adını ekleyip otomatik keşif yaptırırsın
• Seni kritik görülen kayıtlar için önerilen testlere yönlendirir
• Farklı noktalardan gelen sorgu sonuçlarını görsel olarak karşılaştırırsın

Bazı araçlar, DNS kayıtlarında değişiklik olduğunda geçmişle kıyaslama da yapıyor. Örneğin birisi yanlışlıkla A kaydını sildiğinde ya da IP’yi farklı bir adrese çektiğinde, “şu anda ne değişti” sorusunu dakikalar içinde cevaplayabiliyorsun.

Gerçek hayattan birkaç DNS hata senaryosu

Teoriyi bırakıp biraz gerçek dünyaya bakalım. DNS tarafında ekiplerin sık yaşadığı tipik senaryolar, iyi bir izleme kurgusunun neden önemli olduğunu daha net gösteriyor.

Yanlış ortama yönlenen alan adı

Yeni bir staging ortamı açıldığını düşün. Birisi yanlışlıkla production alan adının A kaydını staging IP’sine çekiyor. Uygulama ayakta, sunucu yanıt veriyor ama kullanıcılar bambaşka bir veritabanına bağlanıyor.

Böyle bir durumda dns izleme araçları, yanıtın beklenenden farklı bir IP’ye gittiğini fark edip uyarı üretebilir. Bu uyarı birkaç dakika içinde gelir ve muhtemelen saatlerce sürecek bir karmaşayı engellersin.

Yavaşlayan resolver ve bölgesel kesintiler

Bazen de sorun senin DNS sağlayıcında değil, belirli bir ISS tarafında olabilir. Örneğin belirli bir ülkedeki kullanıcılar için DNS yanıtları aniden 2-3 saniyeye çıkabilir.

Tek bir lokasyondan test yapan bir kontrol bu problemi asla görmez. Ama dağıtık çalışan dns izleme araçları, farklı noktalardan topladığı metriklerle sana net bir tablo sunar: “Türkiye çıkışlı sorgularda gecikme var, Almanya tarafı normal” gibi.

Yanlış TTL yüzünden geciken değişiklikler

Bir başka klasik hata da TTL değerlerini rastgele bırakmak. Değişiklik yapmadan hemen önce veya sonra TTL’yi düşürmediğin bir senaryoda, bazı kullanıcılar eski IP’yi, bazıları yeni IP’yi görür. Karmaşa kaçınılmaz olur.

İyi tasarlanmış dns kesinti takibi, değişikliklerden sonra bile DNS yanıtlarını karşılaştırmaya devam eder. Böylece propagasyonun gerçekten tamamlanıp tamamlanmadığını objektif olarak görebilirsin.

DNS izleme kurgunu güçlendirmek için pratik ipuçları

Artık temel fikirler oturduysa, birkaç küçük ama etkisi büyük öneriyle resmi tamamlayalım.

DNS kayıtlarını dokümante et ve versiyonla

Kimin hangi kaydı, ne zaman, neden değiştirdiği belli değilse, izleme sonuçlarını yorumlamak da zorlaşır. Özellikle büyük ekiplerde, DNS kayıtlarını bir tür “altyapı kodu” gibi düşünüp versiyon kontrolüne almak çok işe yarar.

Biz genelde kritik kayıtlar için şu disiplini öneriyoruz:

• Değişiklik isteğini kısa bir kayıtla açıklamak
• Uygulamadan önce ve sonra DNS izleme sonuçlarını karşılaştırmak
• Gerekirse kolay rollback yapabilecek bir yapı kurmak

Alert yorgunluğunu engelle

Her küçük sapmada onlarca uyarı geliyorsa, bir süre sonra kimse bildirimlere bakmamaya başlar. Bu da asıl büyük kriz geldiğinde fark edilmemesi anlamına gelir.

Bu yüzden dns izleme araçları için alarm eşiklerini akıllıca ayarlamak kritik. Örneğin:

• Tek bir hata yerine, belirli bir zaman aralığında art arda gelen hataları baz almak
• Önemsiz alt alan adları için daha yumuşak eşikler tanımlamak
• Gerçek müşteri etkisiyle korele olmayan uyarıları azaltmak

DNS’i diğer metriklerle birlikte yorumla

DNS metriklerini tek başına izlemek güzel ama yeterli değil. Uygulama hataları, HTTP yanıt süreleri, veri tabanı gecikmeleri, hepsi aynı resmin parçaları.

İdeal olan, DNS dahil tüm gözlemlenebilirlik verilerini tek bir yerde toplayıp, “Bu dakikada hem DNS hataları hem de HTTP 5xx artmış” gibi korelasyonları görebilmek. Böylece gerçekten kök sebebi bulma şansın artar.

Şimdi sen ne yapabilirsin?

DNS tarafı çoğu zaman “bir kere ayarla, unut” muamelesi görüyor. Ama işler büyüdükçe bu yaklaşım fena çarpmaya başlıyor. Tek bir yanlış kayıt, tek bir yavaş resolver ya da tek bir plansız değişiklik, bütün akışı kilitleyebiliyor.

İlk adım olarak, kullandığın alan adları için bugün hemen basit bir kontrol yapabilirsin: Hangi kayıtlara gerçekten bağımlısın, TTL değerlerin mantıklı mı, globalde çözülme durumun nasıl görünüyor? Ardından küçükten başlayarak birkaç temel dns izleme aracı kurup, en kritik kayıtların sürekli izlendiğinden emin ol.

Bir sonraki adımda ise dns kesinti takibi ve hata tespiti süreçlerini ekip standartlarına dönüştürmek çok değerli. Bir kez bu kültürü oturttuğunda, DNS senin için görünmeyen bir risk olmaktan çıkıp, kontrol altında tuttuğun bir bileşen haline geliyor.

Kısacası, işi şansa bırakmak yerine dns izleme araçları ile oyunun kontrolünü eline al. Küçük bir başlangıç bile, bir gün seni çok büyük bir krizden kurtarabilir.