DNS Yayılım Süresi Nedir, Neden 24 Saat Sürer ve Nasıl Hızlandırılır?

Alan adınızı yeni bir sunucuya taşıdığınızda, A kaydını güncellediğinizde ya da e‑posta altyapınızı başka bir servise yönlendirdiğinizde ilk karşınıza çıkan soru genelde aynıdır: “DNS yayılımı ne zaman bitecek, neden hâlâ eski sunucuya gidiyor?” Bu belirsizlik, özellikle canlıya geçiş anlarında hem teknik ekipleri hem de iş tarafını gereksiz strese sokar.

Bu yazıda sahada en çok karşılaştığımız soruları temel alarak DNS yayılım süresini adım adım netleştireceğiz. “24 saat sürer” klişesinin nereden geldiğini, gerçekte ne anlama geldiğini, hangi değişikliğin yaklaşık ne kadar sürede tüm dünyaya yayıldığını ve bu süreyi pratikte nasıl ciddi şekilde kısaltabileceğinizi konuşacağız. TTL stratejilerinden yerel önbellek temizlemeye, nameserver değişikliklerinden kesintisiz taşıma senaryolarına kadar tüm kritik başlıkları tek yerde toparlayacağız.

DCHost altyapısında günlük operasyonlarımızda onlarca DNS değişikliğini planlıyoruz; makaleyi de tam bu pratik tecrübeyle yazıyoruz. Amacımız, “DNS yayılım süresi” kavramını gözünüzde büyüten sis perdesini kaldırmak ve sonraki taşıma ya da yayın süreçlerinizi çok daha sakin ve kontrollü yönetmenizi sağlamak.

DNS yayılım süresi nedir?

DNS yayılım süresi, DNS kayıtlarınızda yaptığınız bir değişikliğin internet üzerindeki tüm DNS önbelleklerine yansıyıp “herkes için geçerli” hale gelmesine kadar geçen zamandır. Örneğin:

• Alan adınızın A kaydını değiştirirsiniz (IP değişimi),
• MX kayıtlarını güncelleyip e‑posta trafiğini yeni bir sunucuya yönlendirirsiniz,
• Alan adınızın nameserver (NS) adreslerini değiştirirsiniz.

Bu değişiklikler teknik olarak yetkili DNS sunucunuzda anında kaydolur; ancak dünya üzerindeki milyonlarca DNS çözümleyicinin (resolver) eski bilgiyi önbelleklerinde tuttuğunu unutmayın. İşte bu önbelleklerin tek tek güncellenmesi sürecine pratikte “DNS yayılımı” diyoruz.

DNS kayıt türleriyle ilgili temel bilgilere hâkim değilseniz, önce DNS kayıt türleri rehberi yazımıza göz atmanız faydalı olur. Ayrıca yeni bir alan adını ilk kez sunucuya bağlama aşamasındaysanız, alan adını hosting hesabına bağlama adımlarını anlattığımız detaylı rehber bu yazıyla birlikte okununca tablo iyice netleşir.

DNS nasıl çalışır? Yayılımı etkileyen katmanlar

DNS yayılımını anlamanın en pratik yolu, DNS çözümleme sürecini katman katman düşünmekten geçer. Bir kullanıcı tarayıcıya alan adınızı yazdığında şu adımların bir kısmı ya da tamamı devreye girer:

1. Tarayıcı önbelleği: Tarayıcı daha önce bu alan adına gitti ise, kısa süreli bir DNS önbelleği tutuyor olabilir.
2. İşletim sistemi önbelleği: Windows, macOS ve Linux, DNS sonuçlarını belirli bir süre kendi içinde cache’ler.
3. Modem / router önbelleği: Bazı modemler, sık kullanılan alan adlarını önbelleğe alır.
4. İSS ya da kullandığınız DNS hizmetinin recursive resolver’ı: İnternete çıktığınız yerdeki DNS sunucusu (örneğin internet sağlayıcınızın DNS’i) cevapları belli bir süre saklar.
5. Yetkili (authoritative) DNS sunucusu: Alan adınız için “doğru cevabı” tutan asıl kaynaktır. DCHost üzerindeki DNS yönetim ekranlarınız, işte bu yetkili sunuculara kayıt yazar.

Pratikte “yayılım”, bu zincirin orta ve üst katmanlarındaki önbelleklerin (özellikle de İSS DNS sunucularının) eski kaydı bırakıp yeni cevabı almaya başlamasıdır. Siz yetkili DNS üzerinde kaydı değiştirdiğiniz anda teknik olarak doğru cevap tek bir yerde hazırdır; geri kalan her şey önbellek süresiyle ilgilidir.

DNS’in bu katmanlı yapısının, hosting ve DNS tarafında nasıl bütünleştiğini daha geniş bir çerçevede görmek isterseniz, domain, DNS, sunucu ve SSL’in birlikte nasıl çalıştığını anlattığımız rehber size iyi bir arka plan sunar.

Neden herkes “24 saat sürer” diyor? Gerçekte ne kadar sürer?

“DNS yayılımı 24 saat sürer” cümlesi aslında teknik bir zorunluluktan değil, yıllar içinde oluşmuş muhafazakâr bir beklenti yönetimi cümlesinden doğuyor. Temel belirleyici, her DNS kaydının üzerinde tanımlı olan TTL (Time To Live) değeridir.

TTL, bir DNS cevabının önbellekte en fazla kaç saniye tutulabileceğini söyler. Örneğin TTL değeri 3600 ise, recursive resolver teoride cevabı 1 saat saklayabilir. Yeni kayıt gelse bile, bu 1 saat dolana kadar eski cevabı döndürmeye devam edebilir.

Dolayısıyla DNS yayılım süresini belirleyen ana faktörler şunlardır:

• İlgili kaydın TTL değeri (örneğin 300 saniye, 3600 saniye, 86400 saniye vb.),
• Bu kaydın ne zaman kimler tarafından çözülüp önbelleğe alındığı,
• İSS’lerin ve bazı DNS sunucularının TTL’e birebir uyup uymamaları (bazıları minimum TTL uygular, bazıları TTL’den uzun süre cache’ler).

Uygulamada sık gördüğümüz tipik TTL değerleri şöyledir:

• 300 sn (5 dk): Canlı taşıma, deneme ortamları, hızlı değişmesi gereken kayıtlar.
• 1800–3600 sn (30–60 dk): Çoğu web sitesi için makul varsayılan.
• 14400–86400 sn (4–24 saat): Daha az değişen, oturmuş prod ortamlar.

Bu yüzden “24 saat sürer” ifadesi, aslında TTL’i 86400 saniye (24 saat) olan kayıtlar için, en kötü senaryoda kullanılan bir yuvarlamadır. Gerçekte çoğu modern DNS yapılandırmasında:

• A/AAAA kayıtları için değişiklikler 5–60 dakika içinde büyük oranda yayılır,
• MX ve TXT gibi kayıtlar genelde 1–4 saat içinde büyük çoğunluğa ulaşır,
• Nameserver değişiklikleri ise TLD önbellekleri devreye girdiği için 4–24 saat arasında dalgalanabilir.

Ancak her zaman bazı İSS’lerin veya eski cihazların önbellekleri uzun süre ısrarla eski kaydı tutabilir. Bu yüzden kritik geçişlerde 24 saati tamamen gözden çıkarmak yerine, planlamanızı “çoğunluk hızlı, azınlık yavaş” mantığıyla yapmanız en sağlıklısıdır.

Hangi DNS değişiklikleri ne kadar sürede yayılır?

DNS yayılım süresi değişikliğin türüne göre de farklılık gösterir. Sahada gördüğümüz ortalama senaryoları kabaca şöyle özetleyebiliriz (doğru TTL ve düzgün yapılandırma varsayımıyla):

A / AAAA kaydı değişikliği (IP adresi değişimi)

Web sitenizi yeni bir sunucuya taşıdığınızda en sık yaptığınız işlem, alan adınızın A (IPv4) ya da AAAA (IPv6) kaydını değiştirmektir. Bu durumda:

• Yayılım süresi büyük oranda kaydın TTL’ine eşittir. TTL 300 ise, pratikte 5–30 dakika içinde çoğu yerde yenilenir.
• Eski IP’ye giden azınlık kullanıcılar olabilir; bu yüzden taşıma döneminde eski sunucuyu tamamen kapatmadan önce birkaç saat beklemek akıllıcadır.
• Yüksek trafikli sitelerde kesintisiz geçiş için genelde TTL’yi önceden düşürüp sonra cutover yapmak en sağlam stratejidir (aşağıda detaylandıracağız).

MX kaydı değişikliği (e‑posta altyapısı)

MX kayıtları, e‑postalarınızın hangi sunucuya teslim edileceğini belirler. MX değişimleri, web trafiği kadar görünür olmayabilir ama yanlış planlandığında ciddi e‑posta kayıplarına yol açabilir.

• Yayılım süresi yine büyük ölçüde TTL’e bağlıdır; çoğu senaryoda 1–4 saat içinde büyük çoğunluk yeni MX’e döner.
• Eski MX sunucunuz bir süre daha ayakta kalmalı ve mümkünse yeni sisteme forward etmelidir.
• Taşıma sırasında bazı gönderici sunucular eski MX’i kullanmaya devam edebilir; bu yüzden “kaybolan e‑posta var mı?” sorusunun cevabı, geçiş mimarisine bağlıdır.

E‑posta altyapı geçişlerinde DNS yayılımını doğru yönetmek için, alan adı taşırken e‑posta kesintisini önleme rehberi ve e‑posta altyapısını taşırken kesinti yaşamamak için hazırladığımız yazı ile birlikte bu makaleyi okumanızı özellikle öneririz.

Nameserver (NS) değişikliği

Alan adınızı farklı bir DNS sağlayıcısına ya da yeni bir hosting firmasına geçirirken genelde nameserver’ları değiştirirsiniz. Bu, daha derin bir değişikliktir; çünkü TLD (örneğin .com, .net, .org) seviyesinde tutulan “bu alan adı için yetkili DNS şunlardır” bilgisini güncellemiş olursunuz.

• TLD tarafında TTL’ler devreye girdiği için tipik yayılım süresi 4–24 saat aralığındadır.
• Birçok kullanıcı 1–4 saat içinde yeni NS üzerinden çözümlemeye başlasa da, bazı İSS’ler TLD yanıtlarını agresif şekilde cache’leyebilir.
• Bu nedenle kritik taşımaları yoğun trafiğin daha az olduğu saatlere almak genelde daha az risklidir.

TXT, CNAME ve diğer kayıtlar

TXT kayıtları (SPF, DKIM, doğrulama kayıtları vb.), CNAME kayıtları ve SRV gibi özel kayıtlar da yayılım açısından TTL’e tabidir. Genelde bu kayıtlar için daha kısa TTL’ler kullanılır ve yayılım 5–60 dakika aralığında tamamlanır. Ancak e‑posta teslim edilebilirliği gibi hassas konularda yanlış konfigürasyon yaparsanız, DNS sadece “yavaş” değil, yanlış da çalışabilir.

Örneğin, SPF/DKIM/TXT tarafındaki bir hata yüzünden e‑postalarınızın spam klasörüne düştüğünü çok sık görüyoruz. Bu konuyu derinlemesine ele aldığımız e‑postaların neden spam klasörüne düştüğünü ve teslim edilebilirliği nasıl iyileştirebileceğinizi anlatan rehber, DNS kayıtlarınızı düzenlerken başucunuzda durmalı.

DNS yayılım süresini gerçekten nasıl hızlandırırsınız?

Gelelim en kritik soruya: DNS yayılımı “kader” midir, yoksa akıllı planlamayla büyük ölçüde yönetilebilir mi? Deneyimimiz, iyi bir stratejiyle hem süreyi hem de riskleri ciddi oranda düşürebileceğiniz yönünde.

1. TTL stratejisini doğru kullanmak

Yayılımı hızlandırmanın en güçlü ve en temiz yolu TTL değerlerini planlı bir şekilde yönetmektir. Önerdiğimiz tipik yaklaşım şöyle:

1. Geçişten 24–48 saat önce: Taşımayı planladığınız A, AAAA, MX vb. kayıtların TTL’ini düşürün (örneğin 3600 → 300 saniye).
2. Bekleme aşaması: Düşük TTL, eski önbelleklerin kendini yenilemesini sağlar. Bu süre zarfında hâlâ eski kayda işaret ediyorsunuz.
3. Cutover anı: Yeni IP’ye, yeni MX’e veya yeni hedefe geçiş yapın. Artık DNS çözümleyiciler, en fazla 300 sn içinde yeni kaydı almış olacak.
4. Stabil olduktan sonra: Gerekiyorsa TTL’i tekrar makul bir seviyeye (örneğin 1800–3600) yükseltebilirsiniz.

Bu konuya özel, senaryo bazlı bir yazımız da var: TTL stratejileriyle DNS yayılımını hızlandırma rehberi. Bu makaledeki genel prensipleri oradaki pratik oyun planlarıyla birleştirdiğinizde, sıfıra çok yakın kesintiyle taşıma yapmak gayet mümkün.

2. Yerel DNS önbelleğini temizlemek (siz ve müşterileriniz için)

TTL stratejisi global yayılımı hızlandırırken, kendi bilgisayarınızda hâlâ eski kaydı görüyor olabilirsiniz. Bu durumda yerel DNS cache’i temizlemek işe yarar:

• Windows: Komut istemini yönetici olarak açıp ipconfig /flushdns komutunu çalıştırın.
• macOS (yeni sürümler): Terminal’de sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Linux: Kullandığınız DNS cache servisine göre (systemd-resolved, nscd, dnsmasq) ilgili servisi yeniden başlatın.
• Tarayıcı: Bazı durumlarda tarayıcı önbelleğini temizlemek veya farklı bir tarayıcıyla test etmek de fark yaratır.

Bu adımlar sadece sizin cihazınız için geçerlidir; tüm internetin yayılım hızını etkilemez. Ancak özellikle geçiş sonrası testlerde, “aslında DNS değişmiş ama siz hâlâ eski cache’i görüyorsunuz” yanılgısını ortadan kaldırır.

3. Doğru DNS altyapısını kullanmak

Yetkili DNS sunucularınızın bulunduğu altyapı da, DNS yanıt sürelerini ve dolaylı olarak yayılımın “hissedilişini” etkiler. Anycast mimarisiyle çalışan, dünya geneline yayılmış DNS sunucuları, kullanıcılara en yakın noktadan cevap döndüğü için daha düşük gecikme (latency) sunar.

DCHost bünyesinde sunduğumuz DNS hizmetlerinde, hosting ve VPS müşterilerimizin kayıtları performans ve süreklilik odaklı bir altyapıda tutulur. Bu sayede:

• DNS yanıt süreleri istikrarlı ve düşük kalır,
• Olası ağ ya da donanım sorunlarına karşı yedekli bir yapı kullanılır,
• Yoğun trafik dönemlerinde bile DNS katmanı darboğaz olmadan işini yapar.

İyi bir DNS altyapısı yayılım süresini “mucizevi şekilde sıfıra indirmez”, ancak hızlı ve tutarlı yanıt sayesinde değişikliklerin etkisini çok daha pürüzsüz hissetmenizi sağlar.

4. Yanlış kayıt ve konfigürasyon hatalarından kaçınmak

Bazen sorun yayılım süresinde değil, yanlış girilmiş bir kayıtta olur. A kaydını hatalı IP’ye, MX kaydını yanlış hostname’e veya SPF kaydını hatalı bir sözdizimiyle girdiyseniz; yayılım beklemekle zaman kaybedersiniz, çünkü en sonunda yayılacak şey yine yanlış bir cevaptır.

Özellikle şu senaryoları sık görüyoruz:

• Alan adının sonuna gereksiz nokta (.) konması veya tam tersi, konulması gerekirken unutulması,
• Apex (kök) alanda CNAME kullanım hataları,
• TXT/SPF kayıtlarında tırnak ve boşluk hataları,
• NS kayıtlarının eksik ya da yanlış yazılması.

Bu tip durumlarda tarayıcınızda DNS_PROBE_FINISHED_NXDOMAIN gibi hatalarla karşılaşmanız mümkün. Bu noktada DNS_PROBE_FINISHED_NXDOMAIN ve benzeri DNS hatalarını teşhis etme rehberimiz üzerinden giderek, problemin yayılımdan mı yoksa yanlış konfigürasyondan mı kaynaklandığını hızlıca ayırt edebilirsiniz.

DNS yayılımı sırasında dikkat etmeniz gereken operasyonel ipuçları

DNS değişikliğini teknik olarak doğru yapmak kadar, operasyonel süreçleri doğru kurgulamak da önemli. Özellikle yüksek trafikli sitelerde, e‑ticaret projelerinde veya kritik e‑posta altyapılarında şu pratikleri öneriyoruz:

1. Eski ve yeni sunucuyu bir süre paralel çalıştırın

Özellikle IP değişimlerinde (A/AAAA kaydı), DNS yayılımının “tam bittiği anı” yüzde yüz yakalamak mümkün değildir. Bu yüzden:

• Yeni sunucuyu tamamen hazır hâle getirdikten sonra DNS’i yeni IP’ye çevirin,
• Eski sunucuyu en az birkaç saat, tercihen 24 saat daha kapatmadan ayakta tutun,
• Statik sitelerde bu neredeyse sıfır çakışma ile çalışır; dinamik uygulamalarda ise veritabanı replikasyonu gibi ilave mimari adımlar gerekebilir.

Daha karmaşık (çok bölgeli, replikasyonlu) mimariler planlıyorsanız, çok bölgeli mimarilerde DNS yönlendirme ve veritabanı replikasyonu ile kesintisizliği anlattığımız rehber size ileri seviye fikirler verebilir.

2. hosts dosyası ile önce kendiniz test edin

DNS’ye dokunmadan önce, yeni sunucunun gerçekten sorunsuz çalıştığından emin olmanın en pratik yollarından biri hosts dosyası ile geçici yönlendirme yapmaktır. Böylece:

• Sadece kendi bilgisayarınız alan adını yeni IP’ye çözer,
• Gerçek kullanıcılar hâlâ eski, stabil sunucuya gitmeye devam eder,
• Tüm testleri (SSL, oturumlar, ödeme adımları, e‑posta gönderimi vb.) DNS’e dokunmadan tamamlayabilirsiniz.

Bu sayede DNS yayılımına geçtiğinizde “sürprizlerle” karşılaşma ihtimaliniz ciddi oranda azalır.

3. E‑posta geçişlerinde MX kayıtlarını aşamalı değiştirin

E‑posta altyapısını taşırken en çok yapılan hata, tek seferde MX değiştirip eski sunucuyu hemen kapatmaktır. Bunun yerine:

• Yeni e‑posta altyapınızı hazır hâle getirin ve test edin,
• MX kayıtlarını öncelik değerleriyle oynayarak aşamalı geçiş yapın (örneğin yeni MX’i daha düşük sayı ile daha öncelikli hâle getirmek),
• Eski sunucudan yeniye forward kuralı ekleyin; böylece yayılım süresince gelen posta kaybolmaz.

DNS yayılımı ve e‑posta geçişlerini aynı potada eritmek için, bu yazının yanı sıra e‑posta odaklı rehberlerimize göz atmanız operasyonel açıdan ciddi rahatlık sağlar.

4. SEO ve yönlendirmeleri doğru kurgulayın

Alan adı değişikliği, HTTP→HTTPS geçişi veya URL yapısı değişiklikleri gibi SEO hassas konularda, DNS yayılımı tek başına yetmez; 301 yönlendirmeleri ve sunucu tarafı ayarlar da kritik rol oynar.

• Yeni sunucuya geçtiğinizde, eski alan adından yenisine 301 yönlendirmeleri mutlaka doğru kurulmalı,
• HTTPS’e geçerken HSTS, sertifika ve yönlendirme zincirleri temiz olmalı,
• DNS ve HTTP düzeyindeki tüm geçişler bir bütün olarak planlanmalı.

Bu noktada HTTP’den HTTPS’e geçişte 301 yönlendirme ve HSTS ayarlarını anlattığımız rehber ile alan adı değiştirirken SEO kaybetmemek için hazırladığımız yazı, DNS tarafındaki bu makaleyle birlikte düşünüldüğünde size uçtan uca bir yol haritası verir.

DCHost üzerinde DNS yayılımını yönetmek

DCHost müşterileri için DNS, günlük operasyonlarda en sık dokunulan katmanlardan biri. paylaşımlı hosting, VPS ya da dedicated sunucu kullanıyor olun; kontrol paneliniz üzerinden alan adınızın DNS kayıtlarını yönetebilir, TTL değerlerini güncelleyebilir ve gerektiğinde geçişlerinizi planlayabilirsiniz.

Genel olarak şu prensipleri öneriyoruz:

• Canlı taşımadan en az 24 saat önce kritik kayıtların TTL’ini düşürün,
• DNS değişikliğini düşük trafikli bir zaman dilimine konumlandırın,
• İlk 1–2 saat boyunca izlemeyi sıkı tutun; logları ve hata bildirimlerini takip edin,
• Her şey stabil olduktan sonra TTL’leri tekrar mantıklı ve dengeli bir seviyeye yükseltin.

Altyapı olarak DCHost; domain, hosting, VPS, dedicated sunucu ve colocation hizmetlerini aynı çatı altında sunduğu için, DNS tarafındaki kararlarınızı da genel barındırma stratejinizle uyumlu şekilde kurgulamanız mümkün. Soru işaretleriniz olduğunda teknik ekibimize senaryonuzu önden anlatmanız, birlikte en doğru TTL ve geçiş planını çıkarmamızı kolaylaştırır.

Özet ve sonraki adımlar

DNS yayılım süresi, çoğu zaman gizemli ve kontrol edilemez bir süreç gibi anlatılır; oysa işin kalbinde son derece net bir mekanizma var: önbellekler ve TTL değerleri. Siz yetkili DNS sunucunuzda kaydı değiştirdiğiniz anda, doğru cevabın tek kaynağı hazırdır; geri kalan tüm gecikme, dünyanın dört bir yanındaki DNS çözümleyicilerin bu yeni cevabı ne kadar sürede alacağıyla ilgilidir.

Bu yazıda, “24 saat sürer” klişesinin nereden geldiğini, farklı kayıt türleri için ortalama yayılım sürelerini, TTL stratejileriyle bu süreyi nasıl ciddi şekilde kısaltabileceğinizi ve geçiş sırasında operasyonel açıdan nelere dikkat etmeniz gerektiğini konuştuk. Artık yeni bir sunucuya geçerken, MX kaydını güncellerken veya nameserver değiştirirken neyle karşılaşacağınızı çok daha net öngörebilirsiniz.

Önünüzde bir taşıma, alan adı değişikliği ya da e‑posta altyapısı yenileme projesi varsa; DCHost üzerinde kullanacağınız domain ve hosting hizmetleriyle birlikte, bu yazıdaki adımları ve bağlantı verdiğimiz diğer detaylı rehberleri bir plan hâline getirmenizi öneririz. Doğru TTL, temiz DNS kayıtları ve iyi tasarlanmış bir geçiş penceresiyle, “DNS yayılımı yüzünden saatlerce bekledik” cümlesini büyük ölçüde tarihe gömebilirsiniz.