DNS Önbellekleme: TTL ve Negative Caching Rehberi

Bir sabah işe geldiniz, DNS değişikliklerinizi gece yaptınız ama bazı kullanıcılar hala eski IP adresine ulaşıyor. Destek taleplerine bakıyorsunuz, herkes “site açılmıyor” diyor ama siz kendi makinenizden gayet güzel açılıyor. İşte bu klasik senaryo, DNS önbelleklemenin tam ortasında yaşanan bir durum. Bu yazıda DNS önbelleklemenin nasıl çalıştığını, TTL değerlerinin ne anlama geldiğini ve negatif önbelleklemenin neden önemli olduğunu gerçek dünya senaryolarıyla ele alacağız.

DNS Önbellekleme Nedir ve Neden Var?

DNS sorguları her yapıldığında hiyerarşik bir süreçten geçer. İstemci önce yerel DNS çözümleyicisine sorar, o da bilmiyorsa kök sunuculara, oradan yetkili sunuculara kadar gider. Bu süreç her sorgu için tekrarlansa internet altyapısı inanılmaz bir yük altında kalır ve kullanıcılar her sayfa yüklemesinde ciddi gecikmeler yaşar.

DNS önbellekleme, bu soruna çözüm olarak geliştirildi. Bir DNS yanıtı alındığında, bu yanıt belirli bir süre için yerel olarak saklanır. Aynı sorgu tekrar geldiğinde, önbellekteki yanıt döndürülür ve ağ üzerinden yeni bir sorgu yapılmaz. Bu hem hızı artırır hem de DNS altyapısı üzerindeki yükü ciddi ölçüde azaltır.

Önbellekleme birkaç farklı katmanda gerçekleşir:

İşletim sistemi önbelleği: Windows ve Linux sistemlerinde yerel DNS önbelleği
Tarayıcı önbelleği: Chrome, Firefox gibi tarayıcılar kendi DNS önbelleklerine sahip
Recursive resolver önbelleği: ISP veya kurumsal DNS sunucularındaki önbellek
Uygulama düzeyinde önbellekleme: Bazı uygulamalar kendi DNS önbelleklerini yönetir

TTL (Time To Live) Değerinin Anatomisi

TTL, bir DNS kaydının önbellekte ne kadar süre tutulacağını saniye cinsinden belirtir. Yetkili DNS sunucusundan gelen yanıtta TTL değeri bulunur ve bu değer her geçen saniyeyle birlikte azalır. Değer sıfıra düştüğünde kayıt önbellekten silinir ve bir sonraki sorguda yeni bir istisna yapılır.

Bir DNS kaydına bakalım:

# dig komutuyla TTL değerini görüntüleme
dig A example.com

# Çıktının ilgili kısmı şöyle görünür:
# ;; ANSWER SECTION:
# example.com.    3600    IN    A    93.184.216.34
# Burada 3600 saniye = 1 saat TTL değeri

TTL değerinin azaldığını görmek için aynı sorguyu birkaç kez çalıştırın:

# TTL'nin azaldığını görmek için art arda sorgulayın
for i in {1..3}; do
  echo "Sorgu $i:"
  dig A example.com | grep "ANSWER SECTION" -A 1
  sleep 5
done

Her sorguda TTL değerinin 5 azaldığını göreceksiniz çünkü recursive resolver önbelleğindeki değer gerçek zamanlı olarak düşüyor.

TTL Değeri Seçimi: Pratik Yaklaşım

TTL değeri seçimi bir denge oyunudur. Düşük TTL değerleri değişikliklerin hızlı yayılmasını sağlar ama DNS sunucularına daha fazla yük bindirir. Yüksek TTL değerleri önbelleği verimli kullanır ama değişiklikler yavaş yayılır.

Genel pratik öneriler şu şekilde:

300 saniye (5 dakika): Aktif geliştirme aşamasındaki projeler veya yakın zamanda değişiklik planladığınız kayıtlar için
3600 saniye (1 saat): Genel kullanım için makul bir değer
86400 saniye (1 gün): Nadiren değişen, kararlı üretim kayıtları için
MX kayıtları: Genellikle 3600-14400 arası tutun, mail akışı kritik
NS kayıtları: Değiştirilmeden önce mutlaka düşürün

Kritik bir geçiş öncesinde TTL’yi düşürme stratejisi şu şekilde uygulanır:

# Mevcut TTL değerini kontrol edin
dig SOA yourdomain.com +short

# Zone dosyasında TTL değerini değiştirmek için
# /etc/bind/db.yourdomain.com dosyasını düzenleyin
# Geçişten 48 saat önce TTL'yi 300'e düşürün
# Geçişi yapın, her şey yolunda gidince TTL'yi tekrar yükseltin

BIND ile TTL Yapılandırması

BIND kullanan bir yetkili DNS sunucusunda TTL değerlerini nasıl yönettiğimize bakalım:

# /etc/bind/db.example.com - Zone dosyası örneği
$TTL 86400      ; Varsayılan TTL: 1 gün
$ORIGIN example.com.

@       IN  SOA ns1.example.com. admin.example.com. (
                2024010101  ; Serial
                3600        ; Refresh
                900         ; Retry
                604800      ; Expire
                300 )       ; Negative Cache TTL (NCTTL)

; NS kayıtları - varsayılan TTL kullanır (86400)
@       IN  NS  ns1.example.com.
@       IN  NS  ns2.example.com.

; A kayıtları
@       IN  A   192.168.1.10
www     IN  A   192.168.1.10

; Düşük TTL'li kayıt - sık değişen sunucu
api     300 IN  A   192.168.1.20    ; Sadece bu kayıt 5 dakika TTL

; MX kayıtları
@       1800 IN MX  10 mail.example.com.

SOA kaydının sonundaki değere dikkat edin, o Negative Cache TTL değeridir ve ayrı bir konuyu ele alır.

Negatif Önbellekleme (Negative Caching)

Negatif önbellekleme, var olmayan DNS sorgularının sonuçlarının önbelleğe alınmasıdır. Birisinin nonexistent.example.com için sorgu yaptığında ve bu isim mevcut olmadığında, DNS sunucusu NXDOMAIN (Non-Existent Domain) yanıtı döndürür. Bu “yokluk” bilgisi de önbelleğe alınır.

Bu neden önemli? Düşünün ki bir saldırgan veya botnet, var olmayan bir milyarlarca subdomain için sorgu yapıyor. Negatif önbellekleme olmadan her sorgu tüm DNS hiyerarşisini dolaşır ve yetkili sunucularınızı çökertir.

# NXDOMAIN yanıtını test etme
dig A nonexistent.example.com

# Çıktıda şunu görürsünüz:
# status: NXDOMAIN
# ;; AUTHORITY SECTION:
# example.com.    300    IN    SOA    ns1.example.com. ...
# Buradaki 300, SOA'daki negative TTL değeridir

NXDOMAIN ve NOERROR Farkı

İki farklı “negatif” durum var ve bunları ayırt etmek önemli:

NXDOMAIN: Alan adının kendisi mevcut değil. NODATA.example.com diye bir kayıt yok.
NODATA (NOERROR): Alan adı mevcut ama sorduğunuz kayıt türü yok. example.com var ama AAAA kaydı yok gibi.

# NXDOMAIN örneği - alan adı mevcut değil
dig A totallynonexistent123456.com

# NODATA örneği - alan adı var ama AAAA kaydı yok
dig AAAA example.com
# Durum: NOERROR ama ANSWER SECTION boş

SOA Kaydındaki Negative TTL

RFC 2308 ile tanımlanan bu mekanizma, negatif yanıtların ne kadar süre önbellekte kalacağını SOA kaydındaki son parametre belirler. Daha önce bu değer $TTL direktifinden alınırdı ama RFC 2308 sonrasında SOA’daki değer geçerlidir.

# SOA kaydını detaylı inceleyelim
dig SOA example.com

# Çıktı:
# example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
#     2024010101  ; Serial
#     3600        ; Refresh - secondary sunucuların kontrol sıklığı
#     900         ; Retry - refresh başarısız olursa tekrar denemesi
#     604800      ; Expire - secondary yetkisini ne zaman kaybeder
#     300         ; Minimum TTL / Negative Cache TTL
# )

Bu son değer olan 300 saniye, NXDOMAIN ve NODATA yanıtlarının önbellekte maksimum ne kadar kalacağını gösterir. Resolver’lar bu değeri aşamaz ama daha düşük bir değer uygulayabilirler.

Linux Üzerinde DNS Önbellek Yönetimi

Modern Linux sistemlerde DNS önbellekleme genellikle systemd-resolved tarafından yönetilir:

# systemd-resolved durumunu kontrol etme
systemctl status systemd-resolved

# Mevcut DNS önbellek istatistiklerini görüntüleme
resolvectl statistics

# DNS önbelleğini temizleme
sudo resolvectl flush-caches

# Temizleme sonrası istatistikleri tekrar kontrol edin
resolvectl statistics

Bazı sistemlerde nscd (Name Service Cache Daemon) kullanılıyor olabilir:

# nscd önbelleğini temizleme
sudo nscd -i hosts

# nscd servisini yeniden başlatma
sudo systemctl restart nscd

# nscd istatistiklerini görüntüleme
nscd --statistics

Dnsmasq kullanan sistemler için:

# dnsmasq önbelleğini temizleme (SIGHUP sinyali gönder)
sudo pkill -HUP dnsmasq

# Ya da servis yeniden başlatma
sudo systemctl restart dnsmasq

# dnsmasq log dosyasını takip etme - önbellek aktivitesini görmek için
sudo tail -f /var/log/dnsmasq.log

Windows Üzerinde DNS Önbellek Yönetimi

Windows tarafında da benzer durumlar yaşanıyor:

# Windows DNS önbelleğini görüntüleme (PowerShell veya CMD)
ipconfig /displaydns

# DNS önbelleğini temizleme
ipconfig /flushdns

# Belirli bir kaydı önbellekte arama
ipconfig /displaydns | findstr "example.com"

Windows DNS Client servisi bazen inatçı olabiliyor:

# DNS Client servisini yeniden başlatma
net stop dnscache
net start dnscache

# PowerShell ile daha temiz bir yol
Restart-Service -Name Dnscache

Gerçek Dünya Senaryosu: Web Sunucu Göçü

Diyelim ki webapp.example.com‘u eski sunucudan yeni sunucuya taşıyacaksınız. Yanlış TTL yönetimi hem downtime hem de kafa karışıklığı yaratır. İşte adım adım doğru yaklaşım:

# 1. ADIM: Mevcut TTL değerini öğrenin
dig A webapp.example.com +noall +answer

# 2. ADIM: Geçişten 48-72 saat önce TTL'yi düşürün
# Zone dosyasında:
# webapp    86400  IN  A  192.168.1.10   # Eski değer
# webapp    300    IN  A  192.168.1.10   # Yeni TTL, IP aynı

# 3. ADIM: TTL düşüşünün yayıldığını doğrulayın
# Farklı yerlerden sorgu yapın
dig A webapp.example.com @8.8.8.8
dig A webapp.example.com @1.1.1.1
dig A webapp.example.com @9.9.9.9

# 4. ADIM: Eski TTL kadar bekleyin (örnekte 86400 saniye = 1 gün)
# Artık tüm önbelleklerde TTL 300 saniye

# 5. ADIM: IP adresini değiştirin
# webapp    300    IN  A  192.168.1.20   # Yeni IP

# 6. ADIM: Propagasyonu izleyin
watch -n 30 "dig A webapp.example.com @8.8.8.8 +short"

# 7. ADIM: Her şey yolunda gidince TTL'yi tekrar artırın
# webapp    3600   IN  A  192.168.1.20

Propagasyon Sorunlarını Teşhis Etme

Bir kullanıcı eski IP’ye bağlanıyor ama siz yeni IP’yi görüyorsanız, sorunun nerede olduğunu bulmak gerekiyor:

# Kullanıcının DNS sunucusunu öğrenin ve doğrudan sorgulayın
# Örneğin kullanıcı 8.8.8.8 kullanıyorsa:
dig A example.com @8.8.8.8 +noall +answer

# Birden fazla public resolver'ı karşılaştırın
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo -n "Resolver $resolver: "
  dig A example.com @$resolver +short
done

# TTL'nin ne kadar kaldığını kontrol edin
dig A example.com @8.8.8.8 | grep -A2 "ANSWER SECTION"

# Yetkili sunucudan doğrudan sorgu yapın (önbellek bypass)
# Önce NS kayıtlarını bulun
dig NS example.com +short

# Sonra yetkili sunucuya doğrudan sorun
dig A example.com @ns1.example.com +noall +answer

Önbellekleme Davranışını Test Etme

Bir script ile önbellekleme davranışını izleyebilirsiniz:

#!/bin/bash
# dns_ttl_monitor.sh - DNS TTL değişimini izle

DOMAIN=$1
RESOLVER=${2:-8.8.8.8}

if [ -z "$DOMAIN" ]; then
    echo "Kullanim: $0 <domain> [resolver]"
    exit 1
fi

echo "Domain: $DOMAIN, Resolver: $RESOLVER"
echo "Sorgu zamanı | TTL | IP Adresi"
echo "-----------------------------------"

while true; do
    RESULT=$(dig A "$DOMAIN" @"$RESOLVER" +noall +answer 2>/dev/null)
    TTL=$(echo "$RESULT" | awk '{print $2}' | head -1)
    IP=$(echo "$RESULT" | awk '{print $5}' | head -1)
    TIMESTAMP=$(date '+%H:%M:%S')

    echo "$TIMESTAMP | TTL: ${TTL:-N/A} | IP: ${IP:-NXDOMAIN}"

    sleep 10
done

Bu scripti çalıştırın ve önbelleğin nasıl tükendiğini gözlemleyin:

chmod +x dns_ttl_monitor.sh
./dns_ttl_monitor.sh example.com 8.8.8.8

Negative Caching’in Aşırı Agresif Olması

Bazen negative caching sizi beklenmedik bir duruma düşürebilir. Örneğin bir subdomain için yanlış NXDOMAIN yanıtı önbelleğe alındıysa, o subdomain’i oluşturmanıza rağmen kullanıcılar hala “bulunamadı” hatası alabilir.

# Negatif önbelleği test etme
# Önce mevcut olmayan bir kayıt sorgulayın
dig A newsubdomain.example.com @8.8.8.8

# Şimdi bu kaydı DNS'e ekleyin
# Zone dosyasına: newsubdomain IN A 192.168.1.30

# Yetkili sunucudan doğru yanıt geldiğini doğrulayın
dig A newsubdomain.example.com @ns1.example.com +short

# Ama resolver hala NXDOMAIN döndürüyor olabilir
dig A newsubdomain.example.com @8.8.8.8

# Çözüm: Negative TTL kadar beklemek veya kullanıcıları
# lokal DNS önbelleğini temizlemeye yönlendirmek

Bu durumla karşılaşmamak için SOA’daki negative TTL değerini makul tutun. 300 saniye (5 dakika) çoğu senaryoda iyi bir denge noktasıdır.

DNS Önbellekleme ile İlgili Güvenlik Notları

DNS önbellekleme bazı güvenlik açıklarıyla da ilişkilidir:

DNS Cache Poisoning: Önbelleğe sahte kayıtlar eklenerek kullanıcılar kötü amaçlı sitelere yönlendirilebilir. DNSSEC bu saldırıya karşı temel savunmadır.

Negative Cache’in Kötüye Kullanımı: Saldırganlar kasıtlı olarak büyük miktarda NXDOMAIN sorgusu yaparak negative cache’i doldurup meşru sorgular için önbellekte yer kalmadığında yetkili sunuculara aşırı yük bindirmeye çalışabilir.

# DNSSEC doğrulamasını kontrol etme
dig A example.com +dnssec

# Resolver'ın DNSSEC destekleyip desteklemediğini test etme
dig signingtest.dnssec-tools.org

# Eğer AD (Authenticated Data) flag'i görüyorsanız DNSSEC aktif

Sonuç

DNS önbellekleme, internetin bu kadar hızlı ve ölçeklenebilir çalışmasını sağlayan sessiz kahramanlardandır. TTL değerlerini doğru ayarlamak, yalnızca “önbellek ne kadar süre geçerli olsun” sorusunu yanıtlamak değil, aynı zamanda değişiklik yönetimi, failover süreci ve kullanıcı deneyimini doğrudan etkileyen bir mimari karardır.

Geçiş öncesinde TTL’yi düşürmeyi alışkanlık haline getirin, SOA’daki negative TTL değerini aşırı büyük tutmaktan kaçının ve propagasyon sorunlarını teşhis ederken her zaman “hangi resolver kullanılıyor” sorusunu sorun. DNS değişikliklerinizin her yerde yayıldığını doğrulamak için birden fazla public resolver’ı test araçlarınıza dahil edin.

Başta anlattığım senaryo gibi durumlarla karşılaştığınızda artık paniklemek yerine TTL değerini kontrol edip “kaç saniye kaldı” diye bakacaksınız. Ve muhtemelen cevap “biraz daha bekle” olacak.

DNS Önbellekleme Nasıl Çalışır: TTL ve Negative Caching