HOŞGELDİNİZ

Alan adı (domain) yönetirken en çok kafa karıştıran konulardan biri DNS Propagation (Yayılım) sürecidir. “DNS kaydını değiştirdim ama site hâlâ eski IP’ye gidiyor”, “Mail çalışmıyor”, “Bende açılıyor ama başkasında açılmıyor” gibi senaryoların arkasında çoğu zaman DNS yayılımı ve önbellek (cache) davranışı vardır. Özellikle taşıma (migration), nameserver değişimi, CDN geçişi veya e-posta servislerini (MX) güncelleme sırasında DNS Propagation (Yayılım) kavramını doğru anlamak; gereksiz panik, yanlış müdahale ve uzun kesinti riskini azaltır.

Bu rehber Datalife.Dev içerik standardına göre hazırlanmıştır. Burada “Nedir?”, “Nasıl yapılır?”, “En iyi yöntem hangisi?”, “2026 güncel yöntem var mı?” ve “Hata alırsam ne yapmalıyım?” sorularını uygulamaya dönük biçimde yanıtlayacağız. Link paylaşmadan; kontrol listeleri, tablolar ve pratik adımlarla ilerleyeceğiz. 🧭

DNS Propagation (Yayılım) Nedir?

DNS yayılımı, DNS kayıtlarında yaptığınız değişikliğin internet üzerindeki farklı DNS sunucularına ve ara önbelleklere “yayılıp” kullanıcıların tamamı tarafından tutarlı şekilde görülmeye başlaması sürecidir. Burada kritik detay şudur:

• DNS tek bir merkezi veri tabanı değildir.

• İnternet üzerinde farklı resolver’lar (çözümleyiciler), ISP DNS’leri, kurumsal DNS’ler ve cihaz/uygulama cache’leri bulunur.

• Bu katmanlar, performans için sonuçları belli süreyle önbelleğe alır.

Yani siz bir A kaydını güncelleseniz bile bazı kullanıcılar hâlâ eski IP’yi görebilir; çünkü onların bulunduğu ağdaki resolver, “eski cevabı” TTL süresi boyunca saklıyor olabilir.

DNS Yayılımında Rol Oynayan Ana Bileşenler

• Authoritative DNS (Yetkili DNS): Alan adınızın “doğru” kayıtlarını tutan sistem.

• Recursive Resolver (Çözümleyici): Kullanıcı adına DNS sorgusu yapan ve sonucu cache’leyen sistem (ISP, Google DNS, Cloudflare DNS, kurumsal DNS vb.).

• TTL (Time To Live): Resolver’ın cevabı ne kadar süre cache’te tutacağını belirleyen süre.

• Yerel Cache: İşletim sistemi, tarayıcı veya uygulama düzeyinde tutulan geçici kayıtlar.

İpucu: DNS yayılımı çoğunlukla “DNS’in yavaşlığı” değil, “cache’in bilinçli davranışı”dır.

DNS Propagation Ne Kadar Sürer?

Bu sorunun tek bir sabit cevabı yoktur; ancak pratikte süreyi belirleyen ana faktör TTL ve kullanılan resolver/caching politikalarıdır. Yaygın gözlemler:

• Kayıt değişikliği (A/AAAA/CNAME/MX) + düşük TTL: Dakikalar – birkaç saat

• Yüksek TTL ile yapılan değişiklikler: Saatler – 24 saat

• Nameserver (NS) değişimi: Genellikle daha uzun ve değişken (24–48 saat tipik senaryo)

TTL’e Göre Yaklaşık Süre Tablosu

Dikkat: Bazı resolver’lar TTL’e tam uymayabilir; minimum cache süresi uygulayanlar veya agresif cache yapan kurumsal ağlar görülebilir. Bu yüzden “TTL kadar sürer” demek yerine “TTL ana belirleyicidir” demek daha doğru olur.

DNS Yayılımını Ne Hızlandırır, Ne Yavaşlatır?

Hızlandıran Etkenler ✅

• Değişiklikten önce TTL’i düşürmek

• Kayıtları tek seferde planlı şekilde güncellemek

• CDN/hosting geçişini “kademeli” yapmak (IP geçişi yerine CNAME/CDN gibi)

• Testleri farklı ağlardan yapmak (mobil veri, farklı ISP)

Yavaşlatan Etkenler ❌

• TTL’i yüksek bırakıp ani değişiklik yapmak

• Birden fazla kez kayıt değiştirip resolver cache’lerini “çalkalamak”

• Nameserver değiştirdikten sonra tekrar eskiye dönmek (karmaşa yaratır)

• Yerel cihazlarda DNS cache temizliği yapılmaması (özellikle Windows/macOS)

Sık hata: “Olmadı” deyip A kaydını 5 kez değiştirerek sorun çözmeye çalışmak. Bu, yayılım sürecini daha belirsiz hale getirebilir.

Nasıl Yapılır? DNS Değişikliklerini Doğru Planlama (Adım Adım)

Bu bölüm, özellikle site taşıma ve e-posta değişimlerinde daha az kesinti için kullanılır. Bu yaklaşım Datalife.Dev içerik standardına göre “risk azaltma” odaklıdır.

1) Değişiklikten 24–48 Saat Önce TTL’i Düşür

Amaç: Resolver’ların eski cevabı uzun süre tutmasını engellemek.

Önerilen değerler:

• Web (A/AAAA/CNAME): 300 sn veya 600 sn

• Mail (MX, SPF, DKIM, DMARC): 300–900 sn (mail tarafında dikkatli olun)

Dikkat: Bazı DNS panellerinde TTL düşürme, ilgili kaydın yeniden kaydedilmesini gerektirir. Planlı yapın.

2) Eski ve Yeni Sistemi Paralel Hazırla

• Yeni sunucuda site çalışıyor olmalı

• SSL sertifikası ve gerekli yapılandırmalar tamamlanmalı

• Mail geçişi ise: yeni mail kutuları, yönlendirmeler, anti-spam ayarları hazır olmalı

3) Önce “Güvenli” Kayıtları Güncelle, Sonra Kritik Kayıtlar

Örnek sıralama:

1. Doğrulama kayıtları (TXT)

2. CDN/alt alan adları (CNAME)

3. Web yönlendirmeleri (A/AAAA)

4. Mail (MX) (en kritik, takip gerektirir)

4) Değişiklik Sonrası İzleme Yap ve TTL’i Geri Yükselt

Geçiş sorunsuzsa TTL’i tekrar 3600 sn gibi daha “normal” seviyeye yükseltmek, resolver yükünü azaltır.

DNS Propagation Nasıl Kontrol Edilir? (2026 Güncel Yöntem)

2026’da da temel mantık değişmiyor: authoritative cevabı ve resolver cevabını ayrı ayrı doğrulamak gerekir. En güvenilir yaklaşım, farklı resolver’lardan aynı kaydı sorgulayıp sonuçları karşılaştırmaktır.

Yöntem 1: Farklı Ağlardan Kontrol (En Basit)

• Ev interneti (ISP-1)

• Mobil veri (ISP-2)

• Ofis ağı / VPN (kurumsal resolver)

• Farklı şehir/ülke çıkışlı test (VPN)

Bu yöntem, “herkeste aynı mı?” sorusuna hızlı yanıt verir.

Yöntem 2: Komut Satırı ile Sorgulama (Pratik ve Net)

Aşağıdakiler teknik ekipler için hızlı teşhis sağlar:

• nslookup ile A, MX, TXT kontrolü

• dig ile daha detaylı çıktı (özellikle TTL ve yetkili cevap)

İpucu: Test ederken aynı kaydı farklı resolver’lara sorup karşılaştırın. Örneğin bir sorguyu “ISP DNS” ile, bir sorguyu “genel resolver” ile yapmak farkı ortaya çıkarır.

Yöntem 3: Kayıt Türüne Göre Kontrol Kriterleri

A / AAAA:

• IP doğru mu?

• TTL beklenen seviyede mi?

CNAME:

• Doğru hedefe mi işaret ediyor?

• Zincirleme CNAME var mı? (gereksiz uzaması gecikme yaratabilir)

MX:

• Öncelik değerleri doğru mu?

• Eski sağlayıcıya giden MX kaldı mı?

TXT (SPF/DKIM/DMARC):

• Boşluk/tırnak hatası var mı?

• Birden fazla SPF kaydı var mı?

En İyi Yöntem Hangisi? (Web, Mail ve Migration İçin)

DNS değişikliği “tek tip” değildir. En iyi yöntem, değişiklik türüne göre seçilir.

Web Sitesi Taşıma İçin Önerilen Yaklaşım

• Önce TTL düşür (300–600)

• Yeni sunucuyu hazırla ve test et

• A/AAAA değiştir

• Yayılımı izlerken eski sunucuyu kapatma

• Stabil olunca TTL’i geri yükselt

Neden?
Her kullanıcı aynı anda yeni IP’ye düşmez. Eski sunucunun bir süre daha çalışması, “yarım açılma” sorunlarını azaltır.

Mail Taşıma İçin Önerilen Yaklaşım

• TTL’i düşür (ama kontrolü artır)

• MX değişimini planlı saatlerde yap (düşük trafik)

• SPF/DKIM/DMARC kayıtlarını önceden hazırla

• Geçiş sonrası 24–48 saat mail akışını izle

Dikkat: Mail tarafında “geçiş oldu sanıp” eski sunucuyu erken kapatmak, kaybolan e-posta riskini artırabilir.

Nameserver Değişimi İçin Önerilen Yaklaşım

• Yeni DNS sağlayıcısında tüm kayıtları birebir oluştur

• NS değişiminden önce doğrula (özellikle MX ve TXT)

• NS değişimi sonrası 24–48 saat çakışma olabileceğini hesaba kat

• Gerekirse eski DNS sağlayıcısını bir süre açık tut

Yaygın Hatalar ve Çözüm Rehberi (Hata Alırsam Ne Yapmalıyım?)

Aşağıdaki sorunlar, saha tarafında en sık karşılaşılanlardır.

1) “Bende Açılıyor, Başkasında Açılmıyor”

Muhtemel nedenler:

• Farklı resolver’lar farklı cache tutuyor

• Bazı cihazlar DNS’i daha agresif cache’liyor

• CDN/Proxy davranışı farklı

Ne yapılması önerilir:

• Aynı domaini farklı ağlardan test edin

• Cihaz/işletim sistemi DNS cache temizliği yapın

• TTL’i kontrol edin (yüksekse bekleme normal olabilir)

Sık hata: Tek bir cihazdan test edip “yayılım bitti” sanmak.

2) Yanlış IP’ye Gidiyor (Eski Sunucuya)

Muhtemel nedenler:

• A kaydı doğru güncellenmemiş

• Yanlış DNS panelinde değişiklik yapılmış (nameserver başka yerde)

• Birden fazla A kaydı var ve istemci farklı kayıt seçiyor

Çözüm kontrol listesi:

• Domain’in hangi nameserver’ları kullandığını doğrulayın

• Değişikliği doğru DNS sağlayıcı panelinden yaptığınızdan emin olun

• Aynı isim için birden fazla A kaydı varsa amacınıza uygun mu kontrol edin

3) Mail Gitmiyor / Mail Gelmiyor (MX Problemi)

Muhtemel nedenler:

• MX kaydı yanlış hedefe gidiyor

• Öncelik (priority) ters

• SPF/DKIM/DMARC uyuşmazlığı nedeniyle reddedilme

Ne yapılması önerilir:

• MX kayıtlarını ve önceliklerini tekrar kontrol edin

• SPF kaydının tek ve doğru olduğundan emin olun

• DKIM/DMARC kayıtlarının ilgili alan adı altında doğru yayımlandığını doğrulayın

Dikkat: SPF için birden fazla TXT kaydı “SPF” şeklinde yazıldıysa, doğrulama başarısız olabilir. Tek kayıt altında birleştirmek gerekebilir.

4) DNS Değişti Ama SSL Hatası Başladı

Muhtemel nedenler:

• Yeni sunucuda sertifika yok/yanlış

• CDN arkasında “origin sertifikası” uyumsuz

• Yanlış host header / yanlış vhost

Çözüm:

• Yeni sunucuda domain için doğru sertifikanın yüklü olduğunu kontrol edin

• CDN varsa origin yapılandırmasını doğrulayın

• Alt alan adlarında (www) sertifika kapsamını kontrol edin

Teknik Mini Bloklar: Hızlı Teşhis İçin

⚠️ Dikkat: DNS Değişikliklerini Peş Peşe Yapmayın

Aynı kaydı arka arkaya güncellemek, farklı resolver’ların farklı sürümleri cache’lemesine neden olabilir. “Tek değişiklik + izleme” yaklaşımı genellikle daha sağlıklıdır.

💡 İpucu: Geçiş Saatini Planlayın

Özellikle e-ticaret veya yoğun trafik alan sitelerde, DNS değişikliklerini düşük trafik saatlerinde yapmak kesinti riskini azaltır.

🧯 Sık hata: Nameserver Değiştirdikten Sonra Kayıtları Unutmak

Yeni DNS sağlayıcısına tüm kayıtlar (A, CNAME, MX, TXT) taşınmadıysa site açılır ama mail bozulabilir (veya tersi).

Uygulamaya Hazır Kontrol Listeleri ✅

Web Site Taşıma Checklist

• TTL 24–48 saat önceden 300–600 sn’e düşürüldü

• Yeni sunucuda site çalışıyor ve test edildi

• SSL sertifikası hazır

• A/AAAA güncellendi

• Eski sunucu en az 24 saat açık bırakıldı

• Yayılım farklı ağlardan kontrol edildi

• Her şey stabil → TTL 3600 sn’e yükseltildi

Mail Taşıma Checklist

• Yeni mail servisinde hesaplar hazır

• SPF/DKIM/DMARC kayıtları önceden planlandı

• TTL düşürüldü

• MX öncelikleri doğru girildi

• Geçiş sonrası mail akışı izleniyor

• Eski mail sistemi hemen kapatılmadı

Bu rehber Datalife.Dev içerik standardına göre pratik işletim hatalarını azaltacak şekilde tasarlandı.

Sonuç

DNS Propagation (Yayılım), çoğu zaman “değişiklik yapılmadı” hissi uyandırsa da gerçekte internetin performans için kullandığı cache mekanizmasının doğal sonucudur. Süreci yönetilebilir hale getiren ana unsur; TTL’i doğru planlamak, değişikliği tek seferde uygulamak, farklı resolver ve ağlardan tutarlı doğrulama yapmak ve geçiş boyunca eski sistemi erken kapatmamak olur. Bu yaklaşım sayesinde web ve mail geçişlerinde daha az kesinti, daha az belirsizlik ve daha hızlı toparlanma elde edilebilir.