DNS Propagasyon Süreci ve Sorun Giderme Rehberi

yazar

DNS değişikliklerini yaptınız, her şey tamam dersiniz… ama site hâlâ eski sunucuya gidiyor. Müşteri arıyor, patron sorguluyor, siz de “propagasyon sürüyor” diye açıklama yapıyorsunuz. Peki bu süreç tam olarak nasıl işliyor, neden bazen 5 dakika bazen 48 saat sürüyor ve en önemlisi sorun gerçekten propagasyondan mı kaynaklanıyor? Gelin her şeyi açıklayalım.

DNS Propagasyonu Nedir, Neden Olur?

DNS propagasyonu aslında biraz yanıltıcı bir terim. İnternette tek bir merkezi DNS veritabanı yok. Bunun yerine dünya genelinde binlerce recursive resolver (özyinelemeli çözümleyici) var ve bunların her biri DNS kayıtlarını kendi cache’lerinde tutuyor.

Siz bir DNS kaydını değiştirdiğinizde, bu değişiklik önce yetkili name server’ınıza yazılıyor. Ama dünyanın her yerindeki resolver’lar hâlâ eski kaydı cache’lerinde tutmaya devam ediyor. Her resolver, kaydın TTL (Time to Live) süresi dolana kadar eski değeri kullanıyor. TTL dolduğunda yetkili sunucuya tekrar soruyor ve yeni kaydı öğreniyor.

İşte bu süreç, farklı lokasyonlarda farklı sürelerde tamamlandığı için “propagasyon” diyoruz. Teknik olarak daha doğru ifade şu olurdu: “Cache yenileme süreci devam ediyor.”

TTL’nin Rolü

TTL değeri, DNS propagasyonunun ne kadar süreceğini doğrudan belirliyor. Eğer bir kaydın TTL’si 86400 (24 saat) ise ve siz kaydı değiştirdiyseniz, bazı resolver’lar 24 saate kadar eski değeri cache’den sunmaya devam edebilir.

Bu yüzden profesyonel sysadmin’lerin altın kuralı şudur: Büyük bir DNS değişikliği öncesinde TTL’yi düşürün.

Değişiklikten 24-48 saat önce TTL’yi 300 (5 dakika) yapın. Değişikliği yaptıktan sonra her şey düzgün çalışıyorsa TTL’yi tekrar yükseltin.

Propagasyon Süresini Etkileyen Faktörler

  • TTL değeri: Kaydın mevcut TTL’si ne kadar yüksekse, o kadar uzun süre eski değer cache’de kalır
  • Resolver cache politikaları: Bazı ISP resolver’ları TTL’yi görmezden gelip kendi cache politikalarını uygular (bu ayrı bir baş ağrısı konusu)
  • Negative caching: NXDOMAIN yanıtları da cache’lenir, silinmiş kayıtlar için bu ekstra sorun çıkarabilir
  • CDN ve proxy katmanları: Cloudflare gibi servisler araya girdiğinde ek cache katmanları oluşur
  • Yetkili DNS sunucularının senkronizasyonu: Bazı DNS sağlayıcılarının birden fazla yetkili sunucusu var ve bunların senkronizasyonu gecikebilir

Propagasyon Sürecini Adım Adım İzleme

dig Komutu ile Temel Kontroller

dig aracı, DNS sorun gidermenin temel silahı. Her sysadmin’in uykusunda bile kullanabilmesi lazım.

# Temel A kaydı sorgusu
dig example.com A

# Kısa çıktı için +short parametresi
dig example.com A +short

# Belirli bir DNS sunucusuna sorgu
dig @8.8.8.8 example.com A

# TTL değerini görmek için
dig example.com A +ttl

# Yetkili name server'lara doğrudan sorgu
dig @ns1.example-dns.com example.com A

Propagasyonun farklı lokasyonlarda nasıl ilerlediğini görmek için birden fazla public resolver’a sorgu atın:

# Google DNS
dig @8.8.8.8 example.com A +short

# Cloudflare DNS
dig @1.1.1.1 example.com A +short

# OpenDNS
dig @208.67.222.222 example.com A +short

# Quad9
dig @9.9.9.9 example.com A +short

Farklı resolver’lardan farklı cevaplar alıyorsanız, propagasyon hâlâ devam ediyor demektir.

Yetkili Name Server’ı Bulmak ve Doğrudan Sorgulamak

Propagasyon sorununu değil, gerçek bir yapılandırma sorununu araştırıyorsanız, önce yetkili name server’a gitmeniz lazım:

# Alan adının yetkili name server'larını bul
dig example.com NS +short

# SOA kaydını kontrol et (serial number propagasyon için kritik)
dig example.com SOA +short

# Yetkili sunucuya doğrudan sor (+norecurse ile)
dig @ns1.example-dns.com example.com A +norecurse

SOA kaydındaki serial number çok önemli. Birincil ve ikincil name server’ların aynı serial’ı göstermesi gerekiyor. Farklıysa zone transfer sorunu var demektir.

nslookup ile Windows Ortamında Kontrol

Windows yöneticileri için nslookup hâlâ geçerli bir araç:

# Temel sorgu
nslookup example.com

# Belirli server kullanarak
nslookup example.com 8.8.8.8

# Interaktif mod - birden fazla sorgu için
nslookup
> set type=MX
> example.com
> server 1.1.1.1
> example.com
> exit

host Komutu ile Hızlı Kontrol

# A kaydı
host example.com

# MX kaydı
host -t MX example.com

# Tüm kayıtlar
host -a example.com

# Belirli name server kullanarak
host example.com 8.8.8.8

Gerçek Dünya Senaryo 1: Site Migration Sonrası Sorun Giderme

Diyelim ki bir web sitesini yeni sunucuya taşıdınız. Eski IP: 192.168.1.100, yeni IP: 10.20.30.40. DNS’i güncellediniz ama bazı kullanıcılar hâlâ eski siteye gidiyor.

İlk yapmanız gereken şey, yetkili sunucunun doğru cevap verdiğini teyit etmek:

#!/bin/bash
# dns_migration_check.sh
# DNS migration sonrası propagasyon kontrol scripti

DOMAIN="example.com"
NEW_IP="10.20.30.40"
OLD_IP="192.168.1.100"

echo "=== DNS Propagasyon Kontrol Raporu ==="
echo "Domain: $DOMAIN"
echo "Beklenen IP: $NEW_IP"
echo ""

RESOLVERS=("8.8.8.8" "8.8.4.4" "1.1.1.1" "1.0.0.1" "208.67.222.222" "9.9.9.9")
RESOLVER_NAMES=("Google Primary" "Google Secondary" "Cloudflare Primary" "Cloudflare Secondary" "OpenDNS Primary" "Quad9")

for i in "${!RESOLVERS[@]}"; do
    RESULT=$(dig @${RESOLVERS[$i]} $DOMAIN A +short 2>/dev/null | head -1)
    
    if [ "$RESULT" == "$NEW_IP" ]; then
        STATUS="✓ PROPAGANDI"
    elif [ "$RESULT" == "$OLD_IP" ]; then
        STATUS="✗ ESKI IP"
    else
        STATUS="? FARKLI: $RESULT"
    fi
    
    echo "${RESOLVER_NAMES[$i]} (${RESOLVERS[$i]}): $STATUS"
done

Gerçek Dünya Senaryo 2: Email Teslim Sorunu ve MX Kaydı Kontrolü

E-posta gelmiyor şikayeti aldınız. DNS’e bakmanız lazım:

# MX kayıtlarını kontrol et
dig example.com MX +short

# MX kayıtlarının A kayıtlarını kontrol et
# Örneğin MX kaydı mail.example.com'a işaret ediyorsa
dig mail.example.com A +short

# SPF kaydını kontrol et
dig example.com TXT +short | grep "v=spf"

# DKIM kaydını kontrol et (default._domainkey selector için)
dig default._domainkey.example.com TXT +short

# DMARC kaydını kontrol et
dig _dmarc.example.com TXT +short

E-posta sorunlarında sıkça gördüğüm durum şu: MX kaydı doğru ama SPF kaydı eski IP’yi gösteriyor. Özellikle sunucu taşıma sonrası SPF kaydını güncellemeyi unutan sysadmin sayısı az değil.

Gerçek Dünya Senaryo 3: Negatif Cache Tuzağı

Bir kaydı yanlış yapılandırdınız, sonra düzelttiniz ama hâlâ sorun var. Bu büyük ihtimalle negative cache problemi.

DNS sunucusu bir kaydı bulamadığında NXDOMAIN yanıtı döner ve bu da cache’lenir. SOA kaydındaki “minimum TTL” veya “negative TTL” değeri bu cache süresini belirler.

# Negative cache durumunu kontrol et
# SOA minimum TTL değerine bakın
dig example.com SOA

# Çıktıda şöyle bir satır görürsünüz:
# example.com. 3600 IN SOA ns1.example.com. admin.example.com. 2024010101 3600 900 604800 300
# Son değer (300) negative TTL'dir

# Cache'i bypass ederek yetkili sunucuya sor
dig @ns1.example-dns.com subdomain.example.com A +norecurse

Eğer yetkili sunucu doğru cevabı veriyorsa ama resolver hâlâ NXDOMAIN diyorsa, negative cache’in dolmasını beklemeniz gerekiyor. Ya da müşterilere farklı bir DNS sunucusu kullanmalarını söyleyebilirsiniz (bu geçici çözüm işe yarıyor ama kökten çözüm değil).

DNS Önbelleğini Temizleme

Bazen sorun global propagasyondan değil, yerel cache’den kaynaklanıyor. İşte farklı sistemlerde cache temizleme yöntemleri:

# Linux - systemd-resolved kullanıyorsa
sudo systemd-resolve --flush-caches
sudo systemd-resolve --statistics

# Linux - nscd kullanıyorsa
sudo nscd -i hosts
sudo service nscd restart

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows (PowerShell veya CMD)
ipconfig /flushdns

Linux’ta hangi resolver’ın kullanıldığını anlamak için:

# systemd-resolved mi yoksa başka bir şey mi?
systemctl status systemd-resolved

# Kullanılan DNS sunucularını göster
resolvectl status

# /etc/resolv.conf içeriği
cat /etc/resolv.conf

# Aktif DNS bağlantısını test et
resolvectl query example.com

Propagasyonu İzlemek için Otomatik Script

Büyük bir DNS değişikliği yapıyorsanız ve propagasyonu sürekli takip etmek istiyorsanız, şöyle bir script işinizi görür:

#!/bin/bash
# dns_propagation_monitor.sh
# Kullanim: ./dns_propagation_monitor.sh example.com A 10.20.30.40

DOMAIN="$1"
RECORD_TYPE="${2:-A}"
EXPECTED="$3"
INTERVAL=60

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

RESOLVERS=(
    "8.8.8.8:Google"
    "1.1.1.1:Cloudflare"
    "208.67.222.222:OpenDNS"
    "9.9.9.9:Quad9"
    "4.2.2.2:Level3"
)

echo "DNS propagasyon izleme basladi: $DOMAIN ($RECORD_TYPE)"
echo "Kontrol araligi: ${INTERVAL}s"
echo "----------------------------------------"

PROPAGATED=0
TOTAL=${#RESOLVERS[@]}

while true; do
    PROPAGATED=0
    TIMESTAMP=$(date '+%H:%M:%S')
    echo ""
    echo "[$TIMESTAMP] Kontrol ediliyor..."
    
    for resolver_info in "${RESOLVERS[@]}"; do
        RESOLVER=$(echo $resolver_info | cut -d: -f1)
        NAME=$(echo $resolver_info | cut -d: -f2)
        
        RESULT=$(dig @$RESOLVER $DOMAIN $RECORD_TYPE +short +time=3 2>/dev/null | head -1)
        
        if [ -n "$EXPECTED" ]; then
            if [ "$RESULT" == "$EXPECTED" ]; then
                echo "  [OK] $NAME: $RESULT"
                ((PROPAGATED++))
            else
                echo "  [--] $NAME: ${RESULT:-'(bos)'}"
            fi
        else
            echo "  $NAME: ${RESULT:-'(bos)'}"
        fi
    done
    
    if [ -n "$EXPECTED" ] && [ "$PROPAGATED" -eq "$TOTAL" ]; then
        echo ""
        echo "Tum resolver'larda propagasyon tamamlandi!"
        break
    fi
    
    echo "Ilerleme: $PROPAGATED/$TOTAL resolver propagandi"
    sleep $INTERVAL
done

DNSSEC Sorunları ve Kontrol

DNSSEC aktif olan domain’lerde propagasyon sorunları daha karmaşık hale gelebilir. Yanlış yapılandırılmış DNSSEC, tüm domain’i erişilemez yapabilir.

# DNSSEC doğrulama kontrolü
dig example.com A +dnssec

# DS kaydını kontrol et (parent zone'da)
dig example.com DS

# DNSKEY kaydını kontrol et
dig example.com DNSKEY

# DNSSEC zincirini doğrula
delv example.com A

# Detaylı DNSSEC hata analizi
dig example.com A +dnssec +cd
# +cd (checking disabled) ile DNSSEC doğrulamayı devre dışı bırakırsınız
# Eğer +cd ile çalışıyor ama +cd olmadan çalışmıyorsa, DNSSEC sorunu var

DNSSEC’te en sık karşılaştığım sorun: Domain registry’de DS kaydını güncelledikten sonra eski DNSKEY’lerin cache’den temizlenmesini beklemeden yeni key’lere geçiş yapmak. Bu durumda DNSSEC doğrulaması başarısız oluyor ve SERVFAIL hatası alıyorsunuz.

Bölgesel Propagasyon Testi

Kendi konumunuzdan testler yaparsınız ama sorun başka lokasyonda devam edebilir. Bu durumda çevrimiçi araçlar kullanmak gerekiyor. Komut satırından da bunu simüle edebilirsiniz:

# Traceroute ile DNS sunucusuna giden yolu gör
traceroute 8.8.8.8

# Belirli bir sunucunun DNS cevabını zaman damgasıyla kaydet
for server in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo -n "$server -> "
    dig @$server example.com A +short +time=2 2>/dev/null || echo "TIMEOUT"
done

# Whois ile domain registrar bilgilerini kontrol et
whois example.com | grep -E "Name Server|Registrar|Updated"

Popüler online araçlar da kullanabilirsiniz: dnschecker.org, whatsmydns.net, dnsspy.io gibi siteler dünya genelinde farklı lokasyonlardan DNS sorgusu atıyor. Sorun giderme sırasında bu araçları bookmark’layın.

Yaygın Propagasyon Sorunları ve Çözümleri

Sorun: Bazı kullanıcılar eski siteyi görüyor, bazıları yeniyi

Bu klasik propagasyon durumu. Yapabileceğiniz şeyler:

  • Yetkili DNS’in doğru cevap verdiğini teyit edin
  • TTL değerlerini kontrol edin
  • Kullanıcılara geçici olarak 1.1.1.1 veya 8.8.8.8 kullanmalarını önerin
  • Her iki sunucuda da aynı içerik olduğundan emin olun (bu arada eski sunucuyu kapatmayın)

Sorun: Siz değişikliği görüyorsunuz ama başkası görmüyor

  • Yerel DNS cache’inizi temizleyin ve tekrar test edin
  • Tarayıcı cache’ini de temizleyin (DNS cache ile karıştırılıyor çoğu zaman)
  • dig +norecurse ile yetkili sunucuya doğrudan sorun

Sorun: 48 saat geçti ama hâlâ propagasyon tamamlanmadı

Bu noktada artık propagasyondan değil, başka bir sorundan şüphelenin:

  • Yetkili DNS sunucusunun kaydı doğru gösterip göstermediğini kontrol edin
  • Birden fazla yetkili sunucu varsa hepsinin senkronize olduğunu doğrulayın
  • ISP DNS’lerinin özel caching politikası olup olmadığını araştırın
  • DNSSEC sorunu olup olmadığını kontrol edin

zone Transfer ve Birden Fazla Name Server Senkronizasyonu

Kendi DNS sunucunuzu yönetiyorsanız, birincil ve ikincil sunucular arasındaki senkronizasyonu kontrol etmeniz gerekebilir:

# Zone transfer test et (izin verilen bir sunucudan)
dig @ns1.example.com example.com AXFR

# SOA serial'ı karşılaştır
dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

# BIND için zone dosyasını reload et
sudo rndc reload example.com

# Tüm zone'ları reload
sudo rndc reload

# Zone transfer durumunu kontrol et (BIND)
sudo rndc zonestatus example.com

İkincil sunucu birincilden zone transfer yapamıyorsa:

  • Firewall kurallarını kontrol edin (TCP 53 açık olmalı, zone transfer için)
  • BIND’da allow-transfer direktifini kontrol edin
  • Serial number’ın ikincil sunucuda birincilden küçük olduğunu doğrulayın

Sonuç

DNS propagasyonu, sysadmin hayatının kaçınılmaz bir parçası. Ama “propagasyon sürüyor” demek artık yeterli olmamalı, çünkü çoğu zaman sorun propagasyondan değil, yanlış yapılandırmadan veya gözden kaçan bir detaydan kaynaklanıyor.

Altın kuralları tekrar özetleyelim: Büyük değişiklikler öncesi TTL’yi düşürün, değişiklik sonrası önce yetkili sunucudan doğrulayın, farklı resolver’lara sorgu atarak gerçek propagasyon durumunu izleyin ve iki sunucu durumunda birini kapanmadan önce her ikisinde de içerik çalıştığından emin olun.

dig komutunu iyi öğrenin. Gerçekten iyi. DNS sorunlarının büyük çoğunluğu birkaç dig komutuyla teşhis edilebilir. Kalan kısım da sabır ve sistematik eliminasyon gerektiriyor.

DNS, internetin telefon rehberi diyorlar. Bir telefon rehberini güncellerken binlerce baskının dağıtılmasını beklediğinizi düşünün. Ama en azından bu rehberin ne zaman güncelleneceğini tahmin edebilir ve buna göre hazırlık yapabilirsiniz. TTL’yi kontrol altında tuttuğunuz sürece, bu süre sizin elinizde.

Yorum yapın