Bir alan adının IP adresini değiştirdiniz, nameserver'ları güncellediniz ya da yeni bir A kaydı eklediniz; ama saatler geçmesine rağmen bazı cihazlar hâlâ eski adresi görüyor. Bu durumun sorumlusu genellikle DNS propagasyonu olarak adlandırılan yayılma sürecidir. Aslında ortada gizemli bir "yayılma" değil, dünyaya dağılmış binlerce DNS önbelleğinin farklı zamanlarda tazelenmesi vardır.
Bu rehberde DNS propagasyonunun ne anlama geldiğini, neden bazen 24-48 saati bulduğunu, TTL ve önbelleklemenin bu sürecin kalbinde nasıl yer aldığını ve değişiklikleri güvenle takip etmek için hangi araçları kullanabileceğinizi ele alacağız. Ayrıca propagasyonu pratikte nasıl hızlandırabileceğinizi ve konu hakkındaki en yaygın yanlış anlamaları netleştireceğiz. DNS'in temel çalışma mantığını hatırlamak isterseniz DNS nedir yazımız iyi bir başlangıç noktasıdır.
DNS Propagasyonu Tam Olarak Nedir?#
DNS propagasyonu, bir alan adının DNS kayıtlarında yaptığınız değişikliğin, internetteki tüm çözücüler (resolver) tarafından fark edilmesi için geçen süredir. Değişikliği kendi DNS panelinizde kaydettiğiniz an aslında yetkili sunucuda anında geçerli olur. Ancak dünyanın dört bir yanındaki servis sağlayıcı ve genel DNS servisleri, performans için eski cevabı bir süre önbelleklerinde tutmaya devam eder.
Yani "propagasyon" kelimesi biraz yanıltıcıdır. Değişiklik tek bir merkezden dünyaya doğru yavaşça yayılmaz. Bunun yerine, her bir resolver kendi önbelleğindeki eski kaydın süresi dolduğunda yetkili sunucuya yeniden sorar ve o anda güncel değeri öğrenir. Bu nedenle bir cihaz değişikliği 5 dakikada görürken, başka bir ülkedeki farklı bir resolver'ı kullanan cihaz aynı değişikliği ancak bir gün sonra görebilir.
Kısacası propagasyon süresi, en yavaş önbelleğin ne zaman tazeleneceğiyle belirlenen bir süredir. Bu da bizi doğrudan TTL ve önbellekleme konusuna götürür.
TTL ve Önbellekleme: Sürenin Gerçek Kaynağı#
Propagasyon süresini anlamanın anahtarı TTL (Time To Live) değeridir. TTL, bir DNS kaydının resolver'lar tarafından ne kadar süre (saniye cinsinden) önbellekte tutulacağını belirtir. Örneğin TTL değeri 3600 olan bir A kaydı, bir kez sorgulandıktan sonra o resolver'da bir saat boyunca saklanır.
Bir örnekle netleştirelim. Diyelim ki ornek.com alan adının A kaydında şu değer tanımlı:
ornek.com. 3600 IN A 203.0.113.10
Buradaki 3600, TTL değeridir. Bir kullanıcının resolver'ı bu kaydı öğrendiğinde, tam bir saat boyunca yetkili sunucuya tekrar sormaz; hafızasındaki 203.0.113.10 cevabını kullanır. Siz bu sürede IP'yi 203.0.113.99 olarak değiştirseniz bile, o resolver kalan süre boyunca eski adresi döndürmeye devam eder.
İşte propagasyonun gerçek nedeni budur: her resolver kendi TTL sayacına göre, birbirinden bağımsız zamanlarda tazelenir. Kayıt farklı ülkelerdeki binlerce resolver'da farklı anlarda sorgulanmış olduğu için, hepsinin süresi de farklı anlarda dolar. Değişikliğin herkese ulaşması, en son sorgulanmış önbelleğin süresinin dolmasını beklemek demektir.
Zincirdeki katmanlar#
Bir sorgu genellikle tek bir önbellekten değil, birkaç katmandan geçer ve her biri ek gecikme yaratabilir:
- İşletim sistemi ve tarayıcı önbelleği: Bilgisayarınız çözdüğü adresleri kısa süreliğine kendisi de saklar.
- Yerel ağ / yönlendirici önbelleği: Ev veya ofis yönlendiriciniz bir DNS önbelleği tutabilir.
- ISP resolver önbelleği: İnternet sağlayıcınızın çözücüsü, propagasyonun en büyük gecikme kaynağıdır ve bazen TTL'e uymayarak kaydı fazladan tutabilir.
- Genel resolver önbelleği: Google (
8.8.8.8) veya Cloudflare (1.1.1.1) gibi servislerin kendi önbellekleri.
Bu katmanların her biri, değişikliğin tam olarak görünmesini kendi süresince geciktirir.
Az bilinen ama gerçek bir gecikme kaynağı da negatif önbelleklemedir. Henüz var olmayan bir kaydı (örneğin yeni ekleyeceğiniz bir alt alan adını) yanlışlıkla erken sorgularsanız, resolver "böyle bir kayıt yok" cevabını da bir süre önbelleğe alır. Bu sürenin uzunluğunu alan adının SOA kaydındaki minimum alanı belirler. Bu yüzden bir kaydı oluşturmadan önce onu sorgulamamak, sonrasında "kayıt neden görünmüyor" gecikmesini önler.
Neden 24-48 Saat Deniyor?#
"DNS değişiklikleri 24-48 saat sürer" ifadesi neredeyse bir efsane haline gelmiştir. Gerçekte pek çok değişiklik dakikalar içinde yayılır. Peki bu geniş aralık nereden geliyor?
Birkaç faktör bir araya geldiğinde süre gerçekten uzayabilir:
- Yüksek TTL değerleri: Değiştirdiğiniz kaydın TTL'i uzunsa (örneğin
86400yani 1 gün), o kaydı önbelleğe almış resolver'lar bir güne kadar eski değeri tutabilir. - ISP'lerin TTL'e uymaması: Bazı internet sağlayıcıları, sunucu yükünü azaltmak için kayıtları TTL'in belirttiğinden daha uzun süre önbellekte tutar. Bu, kontrolünüz dışında bir gecikme kaynağıdır.
- Nameserver (NS) değişimi: Sadece bir kaydı değil, alan adının yetkili sunucularını değiştiriyorsanız, süreç üst düzey uzantı (TLD) kayıtlarını da içerir ve bunların TTL'i çok daha uzundur (genellikle 24-48 saat).
- Uzantıya özgü yenileme aralıkları:
.trgibi bazı uzantılarda registry tarafındaki güncellemeler belirli aralıklarla işlenir; bu da nameserver değişiminde ek bekleme getirir.
24-48 saat, aslında bir en kötü senaryo tahminidir. Sağlayıcılar bu geniş aralığı vererek en yavaş resolver ve en uzun TTL kombinasyonunu bile kapsamayı amaçlar. Pratikte, TTL'i önceden düşürdüğünüz bir A kaydı değişikliğinin çoğu kullanıcıya yansıması yarım saati bile bulmayabilir.
Nameserver Değişimi Neden Daha Yavaştır?#
Bir alan adının A veya MX kaydını değiştirmek ile alan adının nameserver'larını (hangi sunucuların yetkili olduğunu) değiştirmek çok farklı iki işlemdir ve propagasyon açısından ikincisi belirgin biçimde yavaştır.
Tek bir kayıt değişikliğinde, sadece o kaydı önbelleğe almış resolver'ların süresini beklersiniz. Ancak nameserver değişiminde, alan adının uzantısından sorumlu TLD sunucularındaki NS kayıtları güncellenir. Bu NS kayıtlarının TTL'i genellikle çok yüksektir (24 saat veya daha fazla) ve bunu siz kontrol edemezsiniz; registry belirler.
Nameserver değişiminde en kritik nokta şudur: yeni nameserver'da tüm kayıtlarınızı geçiş öncesinde hazırlayın. Aksi halde propagasyon sürerken bazı resolver'lar eski sunucuya, bazıları yeni sunucuya sorar. Eğer yeni sunucuda A veya MX kaydınız eksikse, o resolver'ları kullanan ziyaretçiler için site kısa süreliğine erişilemez olur veya e-postalar teslim edilemez.
# Alan adının şu anda hangi nameserver'ları kullandığını gör
dig ornek.com NS +short
# Yeni nameserver'ın kaydı doğru döndürdüğünü, henüz geçiş öncesi doğrula
dig @ns1.yenisaglayici.com ornek.com A +short
Sancısız bir geçiş için kayıtları önden hazırlamak, TTL'i düşürmek ve doğru sırayı takip etmek gerekir. Bir siteyi yeni bir altyapıya taşırken bu adımların tümünü sizin adınıza planlayan site taşıma hizmetimiz, kesinti riskini en aza indirir.
Propagasyonu Nasıl Hızlandırırsınız?#
Propagasyonu tamamen "anlık" yapmak mümkün değildir, çünkü başkalarının önbelleklerini uzaktan temizleyemezsiniz. Ancak süreyi ciddi biçimde kısaltmak elinizdedir. En etkili yöntem, değişiklikten önce planlama yapmaktır.
TTL'i önceden düşürün#
Bu, en güçlü tekniktir. Sunucu taşıma, IP değişikliği veya nameserver güncellemesi planlıyorsanız, değişiklikten en az 24-48 saat önce ilgili kaydın TTL'ini düşük bir değere (örneğin 300 yani 5 dakika) çekin.
# Geçişten önce: TTL'i düşür
ornek.com. 300 IN A 203.0.113.10
Mantık şudur: eski, yüksek TTL'in tüm resolver'larda sona ermesini beklersiniz. Bir kez düşük TTL yayıldığında, resolver'lar artık kaydı yalnızca 5 dakika saklar. Böylece asıl IP değişikliğini yaptığınızda, herkes en fazla 5 dakika içinde yeni değeri öğrenir. Geçiş tamamlandıktan sonra TTL'i tekrar 3600 veya 86400 gibi normal bir değere yükseltebilirsiniz.
Geçiş sırasında ek önlemler#
- Her iki sunucuyu bir süre çalışır tutun: Eski IP'deki sunucuyu, propagasyon tamamlanana kadar (örneğin 48 saat) kapatmayın. Böylece henüz güncellenmemiş resolver'ları kullanan ziyaretçiler de siteye ulaşmaya devam eder.
- Kendi önbelleğinizi temizleyin: Yerel makinenizde eski değeri görüyorsanız, işletim sistemi önbelleğini boşaltın.
# Linux (systemd-resolved — güncel komut)
sudo resolvectl flush-caches
# Eski sistemlerde: sudo systemd-resolve --flush-caches
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows (yönetici komut istemi)
ipconfig /flushdns
Tarayıcılar da adresleri kendi içlerinde ayrı bir önbellekte tutar. İşletim sistemi önbelleğini boşalttıktan sonra bile eski değeri görüyorsanız, tarayıcınızı tamamen kapatıp yeniden açın; Chrome tabanlı tarayıcılarda chrome://net-internals/#dns sayfasından tarayıcının kendi DNS önbelleğini de temizleyebilirsiniz.
- Doğrulama için farklı resolver kullanın: Değişikliğin yayılıp yayılmadığını, henüz önbelleğe almamış bir resolver üzerinden test edin.
Propagasyonu Kontrol Etme Araçları#
Değişikliğin ne kadar yayıldığını görmek için tahmine dayanmak yerine somut araçlar kullanabilirsiniz. En güvenilirleri komut satırındadır.
dig ile kontrol#
dig (Linux ve macOS'te bulunur), DNS sorgulamanın en esnek aracıdır. Bir kaydın belirli bir resolver'da hangi değeri döndürdüğünü net biçimde gösterir:
# Google resolver'ından A kaydını sorgula
dig @8.8.8.8 ornek.com A +short
# Cloudflare resolver'ından aynı sorgu — iki cevap farklıysa henüz yayılmamış demektir
dig @1.1.1.1 ornek.com A +short
# Kaydın kalan TTL'ini gör (ANSWER SECTION'daki ikinci sütun)
dig ornek.com A
# Doğrudan yetkili sunucuyu sorgula (önbelleği atlar, gerçek güncel değeri verir)
dig @ns1.saglayici.com ornek.com A +short
# Nameserver'ları doğrula
dig ornek.com NS +short
dig çıktısının ANSWER SECTION bölümünde her kaydın yanında bir TTL değeri döner. Bir önbellekli (recursive) resolver'a sorduğunuzda bu sayı, kaydın o önbellekte süresinin dolmasına kaç saniye kaldığını gösterir; aynı sorguyu birkaç saniye arayla tekrarladığınızda değer geri sayıyorsa, resolver hâlâ eski önbelleği kullanıyor demektir. Sayacın sıfırlanıp tam TTL'e (örneğin 3600) dönmesi, resolver'ın yetkili sunucuya yeniden sorup kaydı tazelediği andır. Buna karşılık doğrudan yetkili nameserver'ı sorguladığınızda (dig @ns1.saglayici.com ...) dönen TTL her zaman yapılandırdığınız tam değerdir, çünkü orada önbellek yoktur — bu yüzden yaptığınız değişikliğin gerçekten kaydedilip kaydedilmediğini en kesin olarak yetkili sunucudan doğrularsınız.
nslookup ile kontrol#
Windows kullanıcıları, ayrı bir araç kurmadan, komut isteminde nslookup ile hızlıca sorgu atabilir:
# Varsayılan resolver ile sorgu (bilgisayarınızın kullandığı DNS)
nslookup ornek.com
# Belirli bir resolver belirterek sorgu (adresin sonuna resolver IP'si eklenir)
nslookup ornek.com 1.1.1.1
# Yalnızca nameserver kayıtlarını sorgula
nslookup -type=NS ornek.com
nslookup çıktısında sunucu adresinin altında "Non-authoritative answer" ibaresi görürseniz, cevabın yetkili sunucudan değil bir önbellekten geldiğini anlarsınız; bu tamamen normaldir ve önbelleğin devrede olduğunu gösterir. Değişikliğin gerçekten yayılıp yayılmadığını görmek için sorguyu farklı resolver IP'leriyle (örneğin 8.8.8.8 ve 1.1.1.1) tekrarlayıp cevapları karşılaştırın.
Çevrim içi propagasyon kontrol siteleri#
Dünyanın farklı bölgelerinden aynı anda sorgu atan çevrim içi araçlar (örneğin "DNS propagation checker" olarak bilinen servisler), bir alan adının farklı ülkelerdeki resolver'larda hangi değeri döndürdüğünü harita üzerinde gösterir. Bu, değişikliğin küresel olarak nerelerde yayıldığını, nerede beklediğini görmek için pratiktir. Yine de en kesin sonucu, yukarıdaki dig komutlarıyla farklı resolver'ları doğrudan sorgulayarak alırsınız.
Yaygın Yanlış Anlamalar#
DNS propagasyonu hakkında sık tekrarlanan birkaç yanlış inanç vardır. Bunları netleştirmek, gereksiz endişe ve hatalı beklentilerin önüne geçer.
"Değişiklik yavaş yayılıyorsa DNS sağlayıcım kötü çalışıyor." Genellikle yanlış. Yetkili sunucu değişikliği anında uygular; gecikme, sizin kontrolünüzde olmayan uzak resolver önbelleklerinden kaynaklanır.
- "Propagasyon her zaman 24-48 saat sürer." Hayır. Bu bir üst sınır tahminidir. Düşük TTL'li bir kayıt değişikliği çoğu zaman dakikalar içinde yayılır.
- "Kendi bilgisayarımda görüyorsam herkes görüyordur." Zorunlu değil. Sizin resolver'ınız güncellenmiş olabilir ama başka bir ISP'nin resolver'ı hâlâ eski değeri tutuyor olabilir.
- "Tarayıcıyı yenilemek propagasyonu hızlandırır." Yenileme yalnızca sizin cihazınızın önbelleğini etkiler; başkalarının resolver'larına hiçbir etkisi olmaz.
- "TTL'i şimdi düşürürsem değişiklik hemen yayılır." Yeni TTL de eski TTL süresi dolduktan sonra geçerli olur. Bu yüzden TTL düşürme işlemini geçişten önce yapmak gerekir.
Bu ayrımları bilmek, "site hâlâ eski sunucuda görünüyor" gibi durumlarda paniğe kapılmadan doğru adımı atmanızı sağlar. Alan adının kendisiyle ilgili temelleri tazelemek isterseniz alan adı nedir yazısı yardımcı olur.
Sıkça Sorulan Sorular#
DNS propagasyonu gerçekten 48 saat sürer mi?#
Nadiren. 24-48 saat, en kötü senaryoyu kapsayan bir üst sınırdır. Çoğu A veya CNAME kaydı değişikliği, özellikle TTL değeri düşükse, birkaç dakika ile birkaç saat arasında yayılır. Asıl uzun süren işlem, alan adının nameserver'larını komple değiştirmektir; çünkü bu, TTL'i yüksek olan TLD kayıtlarını da etkiler.
Propagasyon süresince sitem erişilemez mi olur?#
Doğru planlarsanız hayır. Eski sunucuyu propagasyon tamamlanana kadar çalışır tutar ve yeni sunucuda tüm kayıtları önceden hazırlarsanız, hangi resolver hangi adresi görürse görsün ziyaretçiler siteye ulaşır. Kesinti genellikle eski sunucunun erkenden kapatılması ya da yeni sunucuda eksik kayıt bulunması nedeniyle yaşanır.
TTL'i düşürmek propagasyonu neden hemen hızlandırmaz?#
Çünkü yeni, düşük TTL değeri de ancak eski TTL süresi resolver'larda dolduktan sonra devreye girer. Örneğin eski TTL 86400 (1 gün) ise, düşük TTL'in her yere yayılması bir güne kadar sürebilir. Bu nedenle TTL düşürme işlemini asıl değişiklikten en az bir gün önce yapmak gerekir.
Kendi bilgisayarımda hâlâ eski adresi görüyorum, ne yapmalıyım?#
Önce yerel DNS önbelleğinizi temizleyin (Windows'ta ipconfig /flushdns, güncel Linux'ta resolvectl flush-caches, macOS'te dscacheutil -flushcache). Ardından dig @1.1.1.1 ornek.com gibi bir komutla, kendi ISP'nizden bağımsız bir resolver üzerinden test edin. İki farklı resolver aynı yeni değeri döndürüyorsa, değişiklik büyük ölçüde yayılmış demektir. Yine de eski adresi görüyorsanız, gecikme büyük olasılıkla kendi cihazınızda değil ISP'nizin resolver önbelleğindedir ve orada süre dolana kadar beklemek gerekir.
Nameserver değiştirdim, kayıtlarım kayboldu; sorun ne?#
Nameserver değişimi, DNS yönetimini tamamen yeni sunucuya devreder. Eski sunucudaki A, MX ve TXT kayıtları otomatik olarak taşınmaz. Yeni sunucuda bu kayıtları elle oluşturmanız gerekir. Bu yüzden nameserver'ı değiştirmeden önce tüm kayıtları yeni tarafta hazırlamak en güvenli yöntemdir.
Propagasyonu tamamen anlık hale getirebilir miyim?#
Hayır. Başkalarının resolver önbelleklerini uzaktan silemeyeceğiniz için sıfır gecikme mümkün değildir. Ancak TTL'i önceden düşürerek, gecikmeyi pratikte birkaç dakikaya indirebilirsiniz. Bu, "anlık"a ulaşabileceğiniz en yakın noktadır.
Kapanış#
DNS propagasyonu, ilk bakışta belirsiz görünen ama aslında tamamen öngörülebilir bir süreçtir. Temelinde tek bir mekanizma yatar: dünyaya dağılmış resolver'ların, TTL süresi dolana kadar eski cevabı önbellekte tutması. Bu mantığı kavradığınızda, "neden hâlâ eski adres görünüyor" sorusu bir gizem olmaktan çıkar; TTL'i önceden düşürüp doğru araçlarla takip ederek geçişi neredeyse sorunsuz hale getirebilirsiniz.
Alan adınızı taşımak, IP'nizi değiştirmek veya yeni bir sunucuya geçmek istiyorsanız, hosting paketlerimiz ve VDS sunucularımız TTL yönetimini kolaylaştıran bir DNS paneliyle gelir; geçiş planlamasını kendiniz üstlenmek istemezseniz site taşıma ekibimiz propagasyon sürecini baştan sona sizin için yönetir.