DNS Yayılım Süresi: TTL ve Geçiş Planlaması

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 DNS yayılım süresini adım adım netleştireceğiz. “24 saat sürer” ifadesinin neden sabit bir süre olmadığını, farklı değişikliklerde bekleme süresini nelerin belirlediğini ve önceden planlamayla önbellek kaynaklı beklemeyi nasıl azaltabileceğinizi konuşacağız. TTL stratejilerinden yerel önbellek temizlemeye, nameserver değişikliklerinden kesinti riskini azaltan taşıma planlarına kadar temel başlıkları bir araya getireceğiz.

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, eski yanıtları önbellekte tutan istemci ve çözümleyiciler tarafından görülmeye başlanmasına kadar geçen süreyi anlatır. Bu süre herkes için aynı değildir. Ö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.

Kayıt değişikliklerinin önce ilgili yetkili DNS sunucularında yayımlanması gerekir; bunun anında tamamlandığı varsayılmamalıdır. Nameserver değişikliğinde üst bölgedeki delegasyon bilgisinin de güncellenmesi gerekir. Ardından, eski yanıtı önbellekte tutan çözümleyicilerin yeni yanıtı almaya başlaması 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 sistemlerinde kullanılan çözümleme hizmetine ve yapılandırmaya bağlı olarak DNS sonuçları önbelleğe alınabilir.
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. Kayıt değişikliklerini, alan adınızın yetkili DNS hizmetini yöneten panelde yapmanız gerekir; hosting paneliniz her zaman bu hizmeti yönetmez.

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. Önce ilgili yetkili sunucuların yeni kaydı tutarlı biçimde sunduğunu kontrol etmek gerekir. Yayın veya yapılandırma hataları yalnızca önbellek süresini bekleyerek çözülmez.

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.

DNS yayılımı gerçekten 24 saat sürer mi?

“DNS yayılımı 24 saat sürer” ifadesi evrensel bir teknik süreyi belirtmez. Önbellek kaynaklı beklemenin temel belirleyicilerinden biri, eski yanıtın önbelleğe alındığı sıradaki TTL (Time To Live) değeridir.

TTL, bir DNS cevabının normal önbellek işleyişinde kaç saniye geçerli sayılabileceğini belirtir. Örneğin TTL değeri 3600 ise, recursive resolver cevabı aldığı andan itibaren 1 saat kullanabilir. Yetkili sunucudaki kayıt bu sırada değişse bile, kalan TTL dolana kadar eski cevabı döndürebilir. TTL’i sonradan düşürmek, önceden önbelleğe alınmış yanıtın kalan süresini kısaltmaz.

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

• Değişikliğin ilgili yetkili DNS sunucularında, NS değişikliği varsa üst bölgedeki delegasyonda yayımlanma durumu,
• İlgili yanıtın önbelleğe alındığı sıradaki TTL değeri (örneğin 300 saniye, 3600 saniye, 86400 saniye vb.) ve ne zaman önbelleğe alındığı,
• Yeni kayıt eklenirken önceden alınmış “yok” yanıtlarının negatif önbellekte kalan süresi,
• Çözümleyici ve istemcilerin önbellek politikaları; minimum TTL uygulamaları veya bazı koşullarda süresi dolmuş yanıtların kullanılması.

Planlama için örnek TTL değerleri ve kullanım amaçları şö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.

Örneğin eski yanıtın TTL’i 86400 saniye (24 saat) ise, değişiklikten hemen önce önbelleğe alınan yanıt normal işleyişte yaklaşık 24 saat daha kullanılabilir. Bu, tüm DNS değişiklikleri için ne zorunlu bekleme süresi ne de kesin üst sınırdır. Süreyi değerlendirirken:

• A/AAAA değişikliklerinde eski adres yanıtlarının kalan TTL’ini esas alın,
• MX ve TXT değişikliklerinde de kayıt türüne göre sabit bir süre değil, eski yanıtların TTL’i belirleyicidir,
• Nameserver değişikliklerinde üst bölgedeki delegasyonun yayımlanmasını ve çözümleyicilerin eski delegasyon yanıtlarını ne kadar süre önbellekte tutabileceğini de hesaba katın.

Bazı çözümleyiciler veya istemciler TTL’in ötesinde eski yanıtı kullanabilir. Bu yüzden kritik geçişlerde yalnızca “24 saat bekledik” ya da “çoğunluk yeni sunucuya gidiyor” ölçütüne güvenmeyin; eski TTL değerlerini ve eski sunucuya gelen trafiği birlikte değerlendirerek geçişi planlayın.

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

Değişikliğin türü, hangi kayıtların ve önbelleklerin dikkate alınacağını belirler. Aşağıdaki senaryolar ölçülmüş ortalamalar değil, TTL ve geçiş planlaması açısından değerlendirme örnekleridir:

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:

• Önbellek kaynaklı bekleme büyük oranda eski yanıtın kalan TTL’ine bağlıdır. Eski yanıt 300 saniyelik TTL ile alınmışsa, normal işleyişte alındığı andan itibaren en çok 5 dakika daha kullanılabilir; bu, küresel tamamlanma garantisi değildir.
• Eski IP’ye giden kullanıcılar olabilir; eski sunucuyu kapatmadan önce önceki TTL sürelerini ve erişim günlüklerini değerlendirin. Veri yazılan sitelerde eski ve yeni sunucu arasındaki veri tutarlılığını da koruyun.
• Kesinti riskini azaltmak için TTL’yi önceden düşürün ve eski yüksek TTL’in dolmasına zaman tanıdıktan sonra IP değişikliğini yapın (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.

• Önbellek kaynaklı bekleme büyük ölçüde eski MX yanıtının kalan TTL’ine bağlıdır; kayıt türü tek başına 1–4 saatlik bir tamamlanma süresi belirlemez.
• Eski MX sunucunuz geçiş boyunca posta kabul etmeye devam etmeli; burada biriken iletiler yeni sisteme senkronize edilmeli veya döngü oluşturmayacak biçimde forward edilmelidir. Eski sistemi kapatma kararını TTL’in yanında teslimat günlükleri ve bekleyen iletiler üzerinden verin.
• 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.

• Üst bölgedeki delegasyon değişikliğinin yayımlanması ve eski NS yanıtlarının çözümleyici önbelleklerinde kalan TTL’i beklemeyi etkiler; 4–24 saat kesin bir süre aralığı değildir.
• Çözümleyiciler farklı zamanlarda yeni NS’leri kullanmaya başlayabilir. Geçiş boyunca eski ve yeni yetkili DNS sunucularının gerekli kayıtları tutarlı biçimde sunmasını sağlayın; web kaydının TTL’ini düşürmek delegasyon yanıtının TTL’ini düşürmez.
• DNSSEC etkin alan adlarında, geçişten önce üst bölgedeki DS kaydı ile yeni sağlayıcının DNSKEY kayıtları ve imzalarının uyumunu planlayın. Eski ve yeni sunucularda aynı A, MX ve TXT kayıtlarının bulunması tek başına yeterli değildir. DS–DNSKEY veya imza uyumsuzluğu, DNSSEC doğrulayan çözümleyicilerde SERVFAIL yanıtına yol açabilir. Kalıcı bir güven zinciri hatası yalnızca yayılım beklemekle giderilmez; kayıt kuruluşu ve DNS sağlayıcılarıyla anahtar, imza ve DS geçişini, ilgili önbellek sürelerini de hesaba katarak koordine edin.
• 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

Mevcut TXT kayıtları (SPF, DKIM, doğrulama kayıtları vb.), CNAME kayıtları ve SRV gibi özel kayıtlar değiştirildiğinde de bekleme süresi eski yanıtların TTL’ine ve önbelleklerin durumuna bağlıdır; kayıt türü tek başına 5–60 dakikada tamamlanmayı garanti etmez.

Yeni kayıt eklemek ise ayrı değerlendirilmelidir. Daha önce sorgulanan bir ad için NXDOMAIN (ad yok) veya mevcut bir adda istenen kayıt türü için NODATA (bu türde kayıt yok) yanıtı önbelleğe alınmış olabilir. Bu negatif yanıtın önbellekleme süresi, bölgenin SOA kaydının TTL’i ile SOA MINIMUM alanının küçüğünden türetilir. Yeni kayıt yetkili sunucularda yayımlansa bile çözümleyici, negatif önbellekteki yanıtın kalan süresi boyunca kaydı yok sayabilir. Yeni kayda düşük TTL vermek, önceden önbelleğe alınmış bu yanıtı erken sona erdirmez.

E‑posta teslim edilebilirliği gibi hassas konularda yanlış konfigürasyon yaparsanız, sorun yalnızca bekleme süresi değildir; DNS yanlış bir yanıt da sunabilir.

Örneğin, SPF veya DKIM için kullanılan TXT kayıtlarındaki hatalar, e‑posta kimlik doğrulamasını bozarak spam sınıflandırmasına katkıda bulunabilir. 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ında beklemeyi ve geçiş risklerini nasıl azaltırsınız?

Planlı TTL değişiklikleri bekleme süresini azaltabilir; ancak mevcut önbellekleri uzaktan anında temizleyemezsiniz. Amaç, beklemeyi ve geçiş risklerini birlikte yönetmektir.

1. TTL stratejisini doğru kullanmak

Mevcut kayıtların hedefini değiştirirken önbellek kaynaklı beklemeyi azaltmanın temel yolu, TTL değerlerini planlı biçimde yönetmektir. Yeni eklenen kayıtlar için yukarıda açıklanan negatif önbellek süresini ayrıca değerlendirin; yeni kaydın TTL’ini düşürmek bu beklemeyi kısaltmaz. Mevcut kayıtlar için önerdiğimiz tipik yaklaşım şöyle:

1. Geçişten önce: Taşımayı planladığınız A, AAAA, MX vb. kayıtların TTL’ini düşürün (örneğin 3600 → 300 saniye). 24–48 saatlik hazırlık süresinin eski TTL’i karşılayıp karşılamadığını kontrol edin.
2. Bekleme aşaması: TTL düşüşü yetkili sunucularda yayımlandıktan sonra en az eski TTL kadar bekleyin; düşüş mevcut önbelleklerin kalan süresini kısaltmaz. Bu aşamada hedefi değiştirmeyin.
3. Cutover anı: Yeni IP’ye, yeni MX’e veya yeni hedefe geçiş yapın. 300 saniyelik TTL’i kullanan çözümleyiciler, önbellek süresi dolduktan sonraki sorguda yeni kaydı alabilir; bu, tüm kullanıcılar için 300 saniyelik kesin bir üst sınır değildir.
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 planlar kesintiyi azaltmaya yardımcı olabilir; kesintisiz geçiş için uygulama hazırlığı ve veri tutarlılığı da gerekir.

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

Planlı TTL yönetimi değişiklikten sonraki önbellek kaynaklı beklemeyi azaltabilir; ancak kendi bilgisayarınızda hâlâ eski kaydı görüyor olabilirsiniz. Eski yanıt cihazınızdaki önbellekten geliyorsa yerel DNS önbelleğini temizlemek yardımcı olabilir:

• Windows: Yönetici komut isteminde ipconfig /flushdns, Windows DNS istemcisinin yerel önbelleğini temizler; uzak çözümleyicinin önbelleğini değiştirmez.
• macOS: Önbellek temizleme adımını kurulu macOS sürümünün ve kullandığı çözümleyicinin belgelerine göre seçin. Sürümü doğrulamadan internetteki birden çok komutlu reçeteyi bütün macOS sürümlerine uygulamayın; önce yetkili DNS yanıtıyla cihazınızdaki sonucu karşılaştırın.
• Linux / systemd-resolved: Etkin çözümleyici buysa ve sürüm destekliyorsa sudo resolvectl flush-caches kullanın; seçenek systemd 239 ile eklenmiştir.
• Linux / nscd: Etkin hosts önbelleği için sudo nscd -i hosts hedefli temizleme yapar. Debian 12’nin nscd belgeleri bu seçeneği açıklar. Kalıcı önbellek yeniden başlatma sonrasında korunabildiğinden yalnız servisi yeniden başlatmayı temizleme kanıtı saymayın.
• Linux / dnsmasq: Belgelenen SIGHUP sinyali önbelleği temizler; önce doğru dnsmasq sürecini ve servis yönetim yöntemini belirleyin. Bu sinyal bazı hosts/ethers girdilerini yeniden yükler ve mevcut DHCP kiraları için değişiklik betiğini çağırabilir; ana yapılandırma dosyasını yeniden okumaz. DHCP hizmeti de veren bir örnekte bu etkileri hesaba katın.
• Tarayıcı: Bazı tarayıcılar ayrı DNS önbelleği tutar; normal sayfa önbelleğini temizlemek bunu her zaman temizlemez. Farklı bir tarayıcıyla karşılaştırmalı test yapabilirsiniz.

Bu adımlar sadece sizin cihazınız için geçerlidir; tüm internetin yayılım hızını etkilemez. Geçiş sonrası testlerde yerel önbellekten kaynaklanan yanılgıları azaltabilir; kullandığınız uzak DNS çözümleyicisinin önbelleğini ise temizlemez.

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ı, sorguları ağ yönlendirmesinin seçtiği bir noktada yanıtlayarak gecikmeyi azaltabilir; bu nokta coğrafi olarak en yakın sunucu olmak zorunda değildir.

Hosting veya VPS projeniz için yetkili DNS altyapısı seçerken şu ölçütleri değerlendirin:

• DNS yanıt sürelerinin istikrarlı ve düşük olması,
• Olası ağ ya da donanım sorunlarına karşı yedeklilik,
• Yoğun trafik dönemleri için yeterli sorgu kapasitesi.

İyi bir DNS altyapısı hızlı ve tutarlı yanıt sağlamaya yardımcı olur; ancak başka çözümleyicilerdeki mevcut önbellek sürelerini kısaltmaz.

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 hata olasılıklarını kontrol edin:

• DNS panelinin tam alan adlarını nasıl yorumladığının gözden kaçırılması: bazı giriş biçimlerinde sondaki nokta tam adı belirtir; panelin beklediği biçimi ve kaydedilen hedefi kontrol edin,
• Apex (kök) alanda standart CNAME kullanmaya çalışılması; sağlayıcının varsa özel alias/flattening özelliğini standart CNAME ile karıştırmayın,
• TXT/SPF kayıtlarında panelin beklediği biçime aykırı tırnak veya boşluk kullanılması,
• NS kayıtlarının eksik ya da yanlış yazılması.

Her kayıt hatası aynı belirtiyi üretmez. Yanlış bir A kaydı sizi yanlış sunucuya götürebilir; DNS_PROBE_FINISHED_NXDOMAIN ise sorgulanan adın bulunamadığını gösterir ve önceden önbelleğe alınmış bir “yok” yanıtıyla da ilişkili olabilir. DNS_PROBE_FINISHED_NXDOMAIN ve benzeri DNS hatalarını teşhis etme rehberimiz üzerinden ilerleyerek, problemin önbellekten mi yoksa yayın veya yapılandırma hatasından mı kaynaklandığını araştırabilirsiniz.

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 eski TTL’leri ve devam eden trafiği dikkate alarak ayakta tutun; birkaç saat veya 24 saat her geçiş için yeterli olmayabilir,
• Statik sitelerde iki sunucunun aynı içeriği sunduğunu doğrulayın; dinamik uygulamalarda yazmaların hangi sunucuda kabul edileceğini ve verilerin nasıl eşitleneceğini planlayın. Replikasyon tek başına yazma çakışmalarını önlemeyebilir.

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,
• Yerel web testlerini (SSL, oturumlar, ödeme arayüzü vb.) DNS’e dokunmadan yapabilirsiniz. Dış ödeme bildirimleri ve e‑posta teslimatı gibi akışlar yerel hosts değişikliğini kullanmaz; bunları ayrıca test edin.

Testten sonra geçici hosts kaydını kaldırın; aksi hâlde sonraki kontrolleriniz gerçek DNS yanıtları yerine bu kaydı kullanabilir.

3. E‑posta geçişlerinde eski ve yeni altyapıyı birlikte planlayın

E‑posta altyapısını taşırken MX değişikliğinden hemen sonra eski sunucuyu kapatmak, eski kaydı kullanan göndericiler için teslimat sorunlarına yol açabilir. Bunun yerine:

• Yeni e‑posta altyapınızı hazır hâle getirin ve test edin,
• Yeni MX’i daha düşük sayı ile daha öncelikli yapabilirsiniz; ancak MX öncelikleri trafiği kontrollü oranlarda aşamalı taşımaz. Geçiş sırasında her iki altyapının da posta kabul etmeye hazır olması gerekir,
• Eski sunucuya gelen iletiler için aktarım veya posta kutusu eşitleme planı hazırlayın. Forward kullanacaksanız yeni altyapıya ulaştığını, döngü oluşturmadığını ve kimlik doğrulama sorunlarına yol açmadığını test edin; yönlendirme tek başına kayıpsız teslimat garantisi değildir.

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.

• Alan adı da değişiyorsa, eski alan adından yenisine 301 yönlendirmeleri 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.

Barındırma geçişlerinde DNS yayılımını yönetmek

paylaşımlı hosting, VPS ya da dedicated sunucu için geçiş planlarken, alan adınızın yetkili DNS hizmetinin nerede yönetildiğini ve kullanılan panelin kayıt ve TTL düzenlemelerine izin verip vermediğini belirleyin.

Genel olarak şu prensipleri öneriyoruz:

• Canlı taşımadan önce değişecek mevcut kayıtların TTL’ini düşürün; düşük TTL’in yetkili sunucularda yayımlanmasından sonra en az eski TTL kadar beklemeyi geçiş planına katın,
• DNS değişikliğini düşük trafikli bir zaman dilimine konumlandırın,
• Geçişin hemen ardından izlemeyi sıkı tutun; logları ve hata bildirimlerini takip edin. İzlemeyi yalnızca ilk 1–2 saatle sınırlamayın; eski TTL’lere ve eski altyapıya gelen trafiğe göre sürdürün,
• Her şey stabil olduktan sonra TTL’leri tekrar mantıklı ve dengeli bir seviyeye yükseltin.

DNS kararlarınızı genel barındırma stratejinizle birlikte planlayın. Geçiş planında DNS kayıtlarını kimin değiştireceğini, eski ve yeni altyapının ne kadar süre paralel çalışacağını ve sorun hâlinde nasıl geri dönüleceğini belirleyin.

Ö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. Yetkili DNS sunucuları yeni kaydı sunmaya başladıktan sonra bile, önbelleğinde eski cevap bulunan çözümleyiciler bir süre eski kaydı döndürebilir. Bu nedenle kayıt değişikliğini kaydetmek, tüm kullanıcıların hemen yeni cevabı alacağı anlamına gelmez.

Bu yazıda, “24 saat sürer” ifadesinin neden evrensel bir süre olmadığını, farklı kayıt türlerinde beklemeyi etkileyen koşulları ve mevcut kayıtların TTL’ini önceden düşürerek önbellek kaynaklı beklemeyi nasıl azaltabileceğinizi ele aldık. Yeni kayıtlarda negatif önbelleği, DNSSEC’li nameserver geçişlerinde ise DS–DNSKEY ve imza uyumunu ayrıca değerlendirmek gerekir. Bu ayrımları operasyonel hazırlıkla birlikte kullanarak sunucu, MX ve nameserver değişikliklerinizi daha kontrollü planlayabilirsiniz.

Önünüzde bir taşıma, alan adı değişikliği ya da e‑posta altyapısı yenileme projesi varsa; kullanacağınız alan adı ve barındırma 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, önbellek kaynaklı beklemenin hizmet sürekliliğine etkisini azaltabilirsiniz.