DNS Değişiklikleri Neden Yansımıyor? Propagation Süreci Rehberi

DNS (Domain Name System) değişiklikleri yapınca alan adınızın yeni IP’ye bağlanmasını beklersiniz; ancak çoğu kullanıcı “yansımıyor” hissini yaşar. Bu durum genellikle hatalı kayıt veya yanlış değişiklikten değil, DNS propagation (yayılım) sürecinin doğasından kaynaklanır. Bu rehberde; TTL kavramı, hangi DNS kayıtlarının nasıl güncellendiği, cache katmanları ve kontrol yöntemleriyle süreci netleştireceksiniz.

Propagation nedir, neden hemen görünmez?

Propagation, DNS verilerinin internet üzerindeki tüm ilgili sunuculara kademeli olarak yayılmasıdır. DNS hiyerarşisi; kayıt otoriteleri (authoritative DNS), çözümleyiciler (recursive resolver) ve nihayet tarayıcınız/cihazınızın önbelleği (cache) üzerinden çalışır.

Bu sistemde “değişiklik yaptım” demek, tek noktada bitmez. DNS sunucuları, aldıkları yanıtları belirli süre boyunca saklar. Bu süre dolmadan başka bir değişiklik görünmez. İşte bu yüzden bazı kullanıcılar değişikliği hemen görürken, bazıları saatlerce eski IP’yi kullanmaya devam eder.

DNS cache nerelerde tutulur?

En yaygın cache kaynakları şunlardır:

Recursive resolver cache: ISS’nin veya kullandığınız genel çözümleyicinin (ör. 1.1.1.1, 8.8.8.8) kayıtları saklaması.
Tarayıcı ve işletim sistemi cache’i: Cihazınızın DNS yanıtlarını bir süre saklaması.
CDN/WAF veya güvenlik katmanı: Bazı servisler kendi içinde DNS’ten beslenen ek cache katmanları kullanır.
Uygulama düzeyi cache: Özellikle sunucu uygulamaları (ör. proxy/uygulama servisleri) DNS’i kendi içinde daha uzun süre tutabilir.

Bu yüzden “propagation gecikti” dediğimiz şey çoğu zaman gerçekten gecikme değil; farklı katmanların farklı zamanlarda yenilenmesidir.

TTL (Time To Live) güncelleme sürecinin ana belirleyicisidir

Propagation süresini pratikte belirleyen en kritik parametre TTL’dir. TTL, DNS kaydının ne kadar süreyle cache’te tutulacağını söyleyen değerdir (saniye cinsinden).

Örnek mantık: - TTL 3600 (1 saat) ise, bir resolver bu kaydı aldıktan sonra en az 1 saat yeni sorgu yapmadan cache’ten yanıt dönebilir. - TTL 300 (5 dakika) olduğunda yayılım daha hızlı olur.

TTL’yi yanlış okumak en sık yapılan hatadır

Kullanıcılar çoğunlukla şu varsayımı yapar: “Değişikliği yaptım, hemen her yerde görünür.” TTL bu varsayımı bozar. Değişiklik authoritative tarafa yazılsa bile, cache dolana kadar eski yanıt devam eder.

TTL düşürme planı: Hangi adım ne zaman yapılmalı?

Net bir strateji şudur:

Taşınmadan/kr kurulum değişikliğinden en az 24-48 saat önce TTL’i düşürün.
Değişikliği yaptıktan sonra TTL düşük kaldığı için propagation hızlanır.
Değişiklik oturunca TTL’i tekrar makul seviyeye yükseltin.

Bu yaklaşım, özellikle VDS/VPS veya web hosting IP değişiklerinde fayda sağlar.

Not: Bazı kayıt türlerinde TTL davranışı servis/sağlayıcı tarafında farklılık gösterebilir; ancak genel prensip aynı kalır.

Kayıt türlerine göre bekleme süresi ve kontrol noktaları

DNS değişiklikleri tek bir kayıtla bitmez. Etki; yaptığınız kayıt türüne, zincirdeki öğelere ve resolver davranışına göre değişir.

A ve AAAA kayıtları (IP bağlantısı)

A kayıtları IPv4 adresine yönlendirir.
AAAA kayıtları IPv6 adresine yönlendirir.

Bir sistem IPv4 kullanıyorsa A kaydındaki TTL belirleyicidir. IPv6 aktifse AAAA kaydı da görünürlük sağlar. Bazı kullanıcılar değişikliği “hiç olmamış” sanır; aslında AAAA eski kalmıştır veya tersi.

CNAME (alias) ve zincirler

CNAME bir domaini başka bir domain adına bağlar.
CNAME zincirinde bir halka güncellenmezse beklediğiniz etki gecikebilir.

Örneğin www.example.com bir CNAME ile example-hosting.com’a gidiyorsa, asıl etki CNAME’in doğru hedefe bağlanması ve hedefin A/AAAA kayıtlarının güncel olmasıyla gelir.

NS kayıtları ve registrar/dns paneli ayrımı

NS kayıtları hangi nameserver’ların yetkili olduğunu belirler.
NS değişiklikleri genellikle daha “zor” fark edilir; çünkü bu değişiklik yetki katmanını etkiler.

NS değişikliğinde propagation, TTL’den bağımsız bir “yetki geçişi” mantığıyla hissedilebilir. Bu yüzden NS taşıması yaparken daha uzun plan yapmak gerekir.

MX, TXT (SPF/DKIM) ve doğrulama gecikmeleri

Web siteniz bağlanmış görünse bile e-posta servisleri (MX) veya kimlik doğrulama metin kayıtları (TXT) eski veriyi kullanabilir.

MX: E-postalar gelmeyebilir veya gecikebilir.
SPF/DKIM/DMARC (TXT): Posta güvenilirliği etkilenebilir.

Bu nedenle “sadece web açılmıyor” sanılan durum, aslında farklı kayıt türlerinde gecikme olabilir.

“Yansımıyor” derken hangi senaryo daha olası?

Aşağıdaki durumları tek tek elemek propagation sorununu hızlı ayırır.

Senaryo 1: Authoritative taraf güncel, ama resolver cache eski

Bu durumda authoritative sorgusu doğru görünürken, bazı online testler eski IP gösterebilir.

Doğrulama yaklaşımı: - Authoritative cevap dönen kontrol aracını kullanın. - TTL’nin kısa olup olmadığını gözlemleyin.

Senaryo 2: Yanlış kayıt türü güncellendi

Örneğin alan adında web için A kaydı gerekirken siz CNAME güncellediniz veya AAAA atlandı.

Kontrol: - Hedefin gerçekten IPv4 mü IPv6 mı kullandığını doğrulayın. - Hosting panelinizin beklediği kayıt türünü birebir kullanın.

Senaryo 3: Yanlış nameserver (NS) veya yanlış DNS paneli

Bazı kullanıcılar domainin bağlı olduğu DNS sağlayıcısını karıştırır. Domainin registrar panelinde görünen NS’ler farklı olabilir.

Kontrol: - Domain tarafında (registrar) görünen NS ile DNS sağlayıcınızın verdiği nameserver’ların eşleştiğini teyit edin.

Senaryo 4: CDN/WAF veya güvenlik katmanı DNS’i ayrıca cache’liyor

Cloud tabanlı servisler, DNS yanıtlarını daha uzun süre saklayabilir veya kendi cache yenileme kuralına sahip olabilir.

Kontrol: - CDN/WAF panelinde “purge cache”/yenileme seçeneği varsa kullanın. - Cihaz DNS cache’ini temizleyin (aşağıda yöntem var).

Kontrol etmek için pratik yöntemler

Propagation sürecini yönetmenin en önemli kısmı, “beklemek” değil “kanıt toplamak”tır. Aşağıdaki kontrolleri sırayla yapın.

1) DNS sorgusu: TTL ve authoritative cevabı görün

Online araçlar TTL değerini raporlayabilir. TTL kısa görünüyorsa cache’in yenilenmesi daha hızlı olur.

2) Farklı çözümleyicilerle test yapın

Aynı anda birden fazla DNS resolver ile sorgu çalıştırmak, resolver cache farkını gösterir.

Örnek mantık: - Bir testte 1.1.1.1 sonuç doğruysa, diğerinde yanlış çıkabilir. - Bu, propagation sürüyor anlamına gelir.

3) Bilgisayar/telefon tarafı cache’i temizleyin

Cihazınızın kendi DNS cache’i eski yanıtı tutabilir.

Windows (PowerShell/CMD) için tipik yaklaşım: - ipconfig /flushdns

macOS (örnek): - Sistem sürümüne göre dscacheutil -flushcache ve killall -HUP mDNSResponder komutları gerekir.

Linux (örnek sistem çözümleyiciye göre değişir): - systemd-resolved kullanıyorsanız ilgili flush adımları gerekir.

Cihazınızın işletim sistemine göre komutlar değişebildiği için, kullandığınız sürüme uygun adımı izleyin. Ama amaç tek: kendi cache’inizi devre dışı bırakmak.

Ne kadar beklemelisiniz? Net zaman aralığı nasıl çıkarılır?

DNS propagation için tek bir sayı vermek çoğu zaman doğru değildir; çünkü TTL, cache katmanları ve kayıt türü devreye girer. Yine de pratik bir bekleme penceresi şöyle kurulabilir:

TTL’e dayalı bekleme hesabı

TTL değeriniz 300 saniye ise: çoğu resolver için birkaç tur sorgu ile güncellenme hızlanır.
TTL 3600 ise: “en az 1 saat” gerçekçi bir alt sınır olur.

Çok katmanlı cache’lerde bir kullanıcı için bekleme süresi TTL’den birkaç kez TTL kadar uzayabilir. Bu nedenle kritik değişiklik öncesinde TTL düşürmek, bekleme süresini kontrol altına alır.

NS taşımasında daha uzun plan

NS değişiklikleri etkisini kademeli gösterir ve uygulama/servis bazlı cache gecikebilir. Bu yüzden NS değişikliği yapıldığında daha geniş zaman penceresiyle (gün mertebesi yerine saat mertebesi) plan yapmak gerekir. En kritik adım: değişiklikten önce TTL düşürme ve doğru nameserver eşleşmesini kontrol etmektir.

Hosting taşıma ile ilişkili en tipik örnek

VPS/VDS, web hosting veya dedicated sunucu IP’si değiştiğinde süreç genelde şu şekilde ilerler:

Hosting panelinde yeni IP/endpoint tanımlanır.
DNS panelinde A kaydı güncellenir.
TTL kısa değilse eski IP bir süre daha görünür.

Kritik nokta şudur: Sitenin bağlanması gecikiyorsa, bu “sunucu kapalı” değil “DNS yayılımı devam ediyor” olabilir. Sunucunun gerçekten çalıştığını ayrı test edin (ör. yeni IP’ye doğrudan erişim).

Sonuç: Aksiyon planı (beklemek yerine kontrol ve zamanlama)

DNS değişiklikleri yansımıyormuş gibi görünüyorsa önce TTL ve kayıt türü üzerinden ilerleyin. Yapmanız gereken net sırayla şöyledir: (1) Authoritative cevap doğru mu kontrol edin, (2) A/AAAA ve gerekiyorsa CNAME zincirini kontrol edin, (3) registrar’daki NS ile DNS panelinizin NS’lerini eşleştirin, (4) cihaz DNS cache’ini temizleyin, (5) gerekiyorsa CDN/WAF cache yenilemesini uygulayın. Taşınma öncesinde 24-48 saat TTL düşürme planını uyguladığınızda beklenmeyen gecikmeler ciddi ölçüde azalır. Şimdi değişikliğinizi yapın değil, önce doğru kayıt türünü ve TTL stratejisini doğrulayın; ardından propagation penceresi içinde bekleyin.