DNS değişiklikleri yansımıyor mu? Propagation sürecini net yönetin

DNS değişikliklerinin hemen görünmemesi, çoğu zaman “yanlış yaptım” hissi yaratır. Oysa sorun genellikle DNS’in nasıl çalıştığından kaynaklanır: kayıt güncellenir, fakat çözümleyiciler (resolver) ve işletim sistemleri/uygulamalar eski bilgiyi belirli süre tutar. Bu rehberde TTL mantığını, propagation (yayılma) sürecinin neden uzadığını ve doğru kontrol adımlarıyla “hangi noktada takıldığını” net şekilde öğreneceksiniz.

Bugün (02.07.2026) itibarıyla en sık görülen DNS kaynaklı arızalar: A/AAAA/ CNAME kayıtlarının beklenen yerde değişmemesi, yanlış isim sunucularının (nameserver) güncellenmesi ve önbellek sürelerinin (cache/TTL) tamamlanmadan test edilmesidir. Aşağıdaki adımları sırayla uygulayın; test sonuçlarına göre aksiyon alın.

Propagation gecikmesi “hız problemi” değil, “önbellek davranışı” problemidir

Propagation, DNS kayıtlarının tüm dünyaya yayılması değil; resolver denilen sistemlerin yeni yanıtı sorgulayabilmesidir. Bir çözümleyici, sorgu yaptıktan sonra yanıtı belirli süre saklar. Bu süre genellikle “TTL” (Time To Live) değeridir.

TTL neden kritik?

DNS kaydı için belirlenen TTL değeri, bir çözümleyicinin aynı sorguya tekrar gitmeden önce yanıtı kaç saniye saklayacağını belirler. Örnek: - TTL 3600 ise: Bazı kullanıcılar 1 saat boyunca eski IP’yi görebilir. - TTL 60 ise: Çoğu senaryoda değişim 1 dakikaya daha yakın zamanlarda görünür.

TTL düşürmeden değişiklik yapmak, özellikle büyük trafiğe sahip alan adlarında “sorun düzeldi ama hâlâ eski çalışıyor” durumunu uzatır.

Güncelleme yaptınız ama neden yansımıyor? En sık 7 neden

Aşağıdaki liste, DNS değişikliğinde arızayı en sık yakalayan noktaları içerir. Her madde, “hemen denetlenecek” somut bir kontrol önerir.

1) Nameserver (NS) yanlış/eksik güncellendi - Alan adı sağlayıcısında (domain paneli) doğru isim sunucuları seçilmediğinde, yapılan DNS kayıt değişiklikleri etkisiz kalır.

2) Kayıt yanlış türde/yanlış host adında düzenlendi - Örn: www.example.com için A kaydı güncellediniz ama gerçek ihtiyacı example.com kök kayıt (apex) ise yalnızca www düzelir.

3) CNAME varken A/AAAA çakışması - Bazı senaryolarda aynı host adı altında hem CNAME hem A/AAAA bulunamaz/istenmez. Cloud tabanlı proxy’ler de (varsa) yanıltıcı sonuç üretebilir.

4) TTL yüksek ve testler erken yapılıyor - TTL uzunken yapılan doğrulama “yanlış çıktı” gibi görünür.

5) Resolver farklılığı (Google/Cloudflare/ISP DNS) - Bazı kullanıcılar değişimi hızlı görür, bazıları geç görür. Çünkü kullandıkları resolver farklı önbellek durumundadır.

6) Tarayıcı/OS önbelleği devreye girmiş olabilir - DNS cache işletim sistemi seviyesinde de tutulur. Tarayıcı tek başına kaynak olsa da çoğu durumda OS cache’i etkilidir.

7) DNSSEC imzası veya yanlış zincir (chain) sorunu - Doğru görünmeyen imzalar veya zincirde kopukluk varsa resolverlar yeni yanıtı reddedebilir.

Propagation sürecini “ölçün”: Doğru test sıralaması

Aşağıdaki kontrol sırası, sorunun “nerede” olduğunu hızlıca ayırır. Her adımın amacı farklıdır: authoritative (yetkili) sunucu mu, yoksa resolver önbelleği mi.

1) Yetkili DNS sunucusunda (authoritative) kayıt gerçekten güncel mi?

İlk test hedefi: alan adınızın yetkili nameserver’ları üzerinden kayıtların gerçekten değiştiğini görmek.

• A/AAAA/CNAME kaydını kontrol edin.
• Doğru host (ör. @ apex mi, www mi) kontrol edin.
• İlgili TTL değerini de gözden geçirin.

Yetkili taraf güncelse, sıra resolverların güncellemeyi ne kadar süredir beklettiğini ölçmeye gelir.

2) Farklı resolverlardan aynı sorguyu deneyin

Aşağıdaki prensip: Tek bir servis sonucu “kesin” değildir. En az iki farklı resolver ile bakın.

• Örn: Yerel/ISP DNS, Google DNS (8.8.8.8), Cloudflare DNS (1.1.1.1)

Sorgu aynı anda farklı sonuç veriyorsa bu durum, önbelleklerin farklı sürelerde dolduğunu gösterir.

3) Global görünümü doğrulayın (CDN/proxy varsa ek adım)

Web önünde CDN/proxy kullanılıyorsa (ör. trafik yönetimi katmanı), DNS değişikliği web davranışına gecikmeli yansıyabilir. Bu durumda DNS testiyle birlikte web katmanının (HTTP) hangi IP’ye yönlendirdiğini de test edin.

TTL ayarlaması: DNS kesintisini minimize etmenin net yolu

DNS değişikliği yapmadan önce doğru hazırlık yapılırsa propagation daha öngörülebilir olur.

Değişiklik öncesi TTL nasıl yönetilir?

Hedef yaklaşım: 1. Değişiklikten 24-48 saat önce TTL’yi düşürün. 2. Kritik kayıtları (A/AAAA, gerekirse CNAME) planlayın. 3. Değişiklik anında testleri TTL’nin yeni değerine göre zamanlayın.

Net öneri (genel): - TTL 3600 ise, 24-48 saat önce 300–600 saniyeye çekmek pratikte hızlı geri dönüş sağlar. - TTL’i düşürmek “herkes hemen değişir” garantisi vermez; ama gecikmenin üst sınırını düşürür.

Hangi kayıt türü ne kadar “bekler”? Uygulama etkisi

Farklı DNS kayıtları aynı anda güncellense bile etki farklı hissedilebilir.

A/AAAA kayıtları

• En sık kullanılanlardır.
• IP değişimi olduğunda bazı kullanıcılar eski IP’ye yönlenmeye devam edebilir.

CNAME kayıtları

• CNAME zinciri uzadıkça resolver davranışı farklılaşabilir.
• Bazı sistemler CNAME zincirini daha uzun süre önbelleğe alır.

NS ve SOA değişiklikleri

• Nameserver ve yetki zinciri değişiklikleri daha hassastır.
• DNSSEC kullanıyorsanız ek kontrol gerekir.

“Eski IP’ye gidiyor” sorunu için hızlı ayrıştırma matrisi

Aşağıdaki tablo, test sonucuna göre aksiyon almanızı sağlar.

Yerel testlerde takılmayı engelleyin: OS ve tarayıcı cache

Kullanıcı tarafında test yaparken yanlış sonuca sebep olabilen iki alan vardır: işletim sistemi DNS cache’i ve uygulama önbelleği.

Tarayıcı tek başına yeterli değil

Tarayıcı cache’i bir miktar etkileyebilir ancak DNS çözümlemesi çoğunlukla OS seviyesinde gerçekleşir. Özellikle Windows/Linux/macOS’ta DNS cache süreleri kullanıcı testini yanıltır.

Net test yaklaşımı

• Farklı cihaz/operatör ile test edin.
• Mümkünse farklı resolver ile (ör. farklı DNS sunucusu kullanarak) doğrulayın.
• Aynı cihazda test ederken DNS cache temizlemeden tekrar etmeyin.

DNS değişikliğiyle birlikte HTTPS tarafı da kontrol edilmelidir

DNS düzgün olsa bile HTTPS tarafında sorun devam edebilir. Bu iki sebepten olur:

1) Sertifika (certificate) alan adıyla uyumsuzdur - Yeni yönlenen domain farklı SAN/alfaname kapsamı gerektirebilir.

2) Reverse proxy/uygulama host bazlı çalışır - Yeni IP’ye doğru yönelse bile web sunucusu yanlış host’u bekliyorsa sayfa yüklenmez.

Pratik kontrol listesi

• Yeni IP’ye yönlenen istekte HTTP 200/301 geliyor mu?
• Hangi host header (HTTP Host) ile uygulama çalışıyor?
• TLS sertifikası doğru domain’i kapsıyor mu?

Net karar: Ne zaman “beklemeye” devam, ne zaman “müdahale” etmelisiniz?

Aşağıdaki kural seti, gereksiz müdahaleyi azaltır.

Bekleme gerektiğini gösteren durumlar

• Yetkili DNS’te kayıt doğru.
• Farklı resolver’larda kademeli farklı sonuçlar görülüyor.
• TTL değeri makul (ör. 300–600 saniye) ve testler TTL’den hemen sonra yapılmıyor.

Bu durumda yapılacak en doğru şey: TTL’nin yeni değerine göre zaman tanımak ve farklı resolver ile tekrar ölçmektir.

Müdahale gerektiğini gösteren durumlar

• Yetkili DNS’te kayıt yanlış veya hiç güncellenmemiş.
• Aynı host için çakışan kayıtlar var (CNAME + A gibi).
• Apex ("@") güncellenmediği için kök alan eski çalışıyor.
• DNSSEC zinciri hatalı sinyal veriyor.

Bu durumlarda beklemek değil; paneldeki kayıtları doğru host ve doğru kayıt türüyle düzeltmek gerekir.

Sonuç: DNS propagation’ta doğru strateji ölçmek ve TTL’i yönetmektir

DNS değişiklikleri yansımıyor gibi göründüğünde ilk adım “panikle paneli tekrar tekrar güncellemek” değil, yetkili DNS’te kayıtların gerçekten güncellenip güncellenmediğini doğrulamaktır. Ardından farklı resolver’larla ölçüm yapın; TTL değerinin üst sınırına göre hareket edin. Eğer authoritative taraf doğru değilse, sorunun kaynağı panel/kayıt tasarımıdır; bu durumda kayıt türü ve host (apex vs subdomain) kontrolüyle hızlı düzeltme yapın.

Aksiyon önerisi: Değişiklikten önce TTL’yi düşürmeyi planlayın, değişiklik anında yetkili DNS’te doğrulayın ve testleri en az iki farklı resolver ile zamanlayın. Böylece propagation sürecini belirsizlik yerine ölçülebilir bir takvime bağlarsınız.