DNS Değişikliğinde Önbelleği Planlamak
Bir taşıma sırasında bazı kullanıcıların yeni, bazılarının eski sunucuya ulaşması sık rastlanan bir önbellek durumudur. Örneğin, kaydın TTL’i değişimden hemen önce düşürülürse daha önce alınmış uzun ömürlü cevaplar bundan etkilenmez. Bu varsayımsal senaryo, hazırlık süresini mevcut TTL’den başlayarak hesaplamanın neden önemli olduğunu gösterir.
Bu rehber, sunucu taşımada DNS TTL planlamasını; veri eşitleme, eski ve yeni uçların birlikte çalışması, doğrulama ve geri dönüşle birlikte ele alıyor. Amaç kesinti ve veri kaybı riskini azaltmaktır. Düşük TTL tek başına kesintisiz geçiş garantisi vermez; uygulamanın yazma yolu, oturumları ve bağlantıları ayrıca tasarlanmalıdır. A/AAAA, CNAME, NS ve e-posta kayıtlarının farklı bağımlılıklarını adım adım inceleyeceğiz.
Hazırsan başlayalım. Çünkü doğru yapıldığında, taşımanın en stresli kısmı olan DNS yayılımı, aslında kontrollü ve tahmin edilebilir bir süreç olabiliyor. Küçük bir sır: Sihirli değnek yok, ama doğru zamanlama var.
TTL Nedir ve Neden Herkes Ondan Bahseder?
TTL, DNS kayıtlarının önbellekte ne kadar süreyle tutulacağını söyler. Basitçe, “Bu adresi belirlenen saniye cinsinden süre boyunca tekrar sorma” demektir. Bu değer yüksekse, sorgular daha az yapılır, hız ve yük açısından ferahlık verir; ama değişikliğin yayılması yavaşlar. Düşükse, yeni cevapların alınma aralığı kısalabilir; bunun karşılığında çözümleyiciler daha sık soru sorar. Kâğıt üzerinde çok net, pratikte ise zamanlama bütün oyunu değiştirir. Çünkü TTL, geçişten önce düşürülmediyse, bazı kullanıcılar eski bilgiyi inatla tutar.
DNS yayılımı denen şey aslında bir dalga. Sen yeni IP’yi yazarsın, ama dünyanın dört bir yanındaki çözümleyiciler kendi önbellek süreleri dolana kadar eskiyi göstermeye devam edebilir. Sen “hadi hızlan” diye bağırırsın, o kendi saatine bakar. Bu yüzden zero-downtime taşımada plan, her şeyden önce TTL’e saygı duymayı gerektirir. Birazdan anlatacağım stratejiler tam burada devreye giriyor: Değişiklikten günler önce hazırlık, geçiş sırasında kademeli yönlendirme, geçişten sonra kontrollü temizlik.
Taşımadan Önce Yapılacaklar: Zemin Hazırlığı ve Küçük Tuzaklar
Önce Sahneyi Kur: Eski ve Yeni Sunucuyu Aynı Anda Hazır Tut
Yeni ortamı hazırla ve mevcut veriyi kopyala; ardından yeni yazıların hangi sistemde kabul edileceğini açıkça belirle. İki bağımsız veritabanına aynı anda sipariş yazmak güvenli bir geçiş stratejisi değildir. Uygun seçenekler; tek yazma kaynağına erişim, eski ucun yeni uygulamaya doğrulanmış ters proxy olması veya son eşitleme için kısa bir yazma duraklamasıdır. Ters proxy’nin üst hedefi, yeniden eski proxy’ye çözümlenebilecek genel alan adı değil, doğrudan yeni hedef veya ayrı bir orijin adı olmalıdır. TLS/SNI, Host başlığı, yönlendirmeler, çerezler, istemci IP’sine güven kuralları ve varsa WebSocket davranışını doğrula. Tek yönlü replikasyon kullanılıyorsa gecikmeyi ölç, eski yazmaları durdur ve tutarlı terfi sırasını uygula. Eski DNS cevabına ulaşan istemciler de aynı veri durumunu görmelidir.
TTL’i Ne Zaman Düşürmeli?
Değişecek A, AAAA ve varsa CNAME kayıtlarının mevcut TTL’lerini önce kaydet. Yeni düşük TTL’nin tüm yetkili sunucularda yayımlandığını doğruladıktan sonra en az önceki TTL kadar hazırlık süresi bırak; bağımlılıklar için ek pay gerekebilir. Örneğin eski TTL 24 saatse son dakika 300 saniyeye düşürmek önceki cevapları beş dakikada geçersiz yapmaz. Yalnız değişecek MX ve ilgili TXT kayıtlarını aynı mantıkla planla.
Hangi Kayıtları Düşüreceğim?
Öncelik web trafiğini taşıyan kök veya “www” kayıtlarında. E-posta senin için kritikse MX ve ilgili SPF/DKIM kayıtları da listede olmalı. CDN kullanıyorsan, apex kayıtta ALIAS/ANAME gibi çözümlerle karşılaşırsın; burada da mantık aynı: Kayıt değişecekse TTL’i önceden aşağı çek. DNS dünyasının haritasına hâkim değilsen, DNS kayıtlarını A’dan Z’ye anlatan rehberimizi göz atmalık küçük bir mola gibi düşünebilirsin.
DNS Yayılımını “Hızlandırmak” Ne Demek? Gerçekte Olan ve Olabilecekler
Kimse beklemeyi sevmez, ama DNS bekletir. “Hızlandırmak” dediğimiz şey aslında yayılım fiziğini değiştirmek değil; yayılımın sana çarpmasını yumuşatmak. TTL’i önceden düşürmek birincisi. İkincisi, kırılgan tek noktaları azaltmak. Üçüncüsü, riskli değişiklikleri parçalamak. “Bugün hem isim sunucularını hem IP’yi değiştireyim, aradan çıksın” dediğinde hayatın şakası sert olabiliyor. Parçalara böl, önce birini yap, stabilize et, sonra diğerine geç.
Yerel uygulama önbellekleri, çözümleyici politikaları ve açık bağlantılar gözlenen geçişi etkileyebilir. RFC 8767, yetkili sunucuya erişilemediğinde süresi dolmuş cevabın kullanılabileceği durumları da tanımlar. Bu yüzden eski ucu kapatmak için yalnız kısa TTL’nin dolmasını değil, erişim loglarını, DNS sağlığını ve uygulama akışlarını birlikte değerlendir.
TTL Stratejileri: Kademeli, Temkinli, Geri Dönüşlü
Adım Adım Zamanlama
TTL’yi 24 saatten doğrudan 300 saniyeye indirmek mümkündür; kademeli düşüş protokol gereği değildir. Önemli nokta, düşük değer yetkili sunucularda etkin olduktan sonra önceki TTL’nin dolmasına zaman tanımaktır. Sağlayıcının alt sınırını ve artan sorgu yükünü dikkate al. Geçiş öncesi son veri eşitlemesini, yazma kaynağını, sertifikaları ve geri dönüş eşiğini kontrol et; ancak bu koşullar sağlandığında kayıt değişikliğine geç.
Negatif Önbellek ve Küçük Sürprizler
Olmayan bir ad veya kayıt türü için alınan NXDOMAIN/NODATA cevabı da önbelleğe girebilir. RFC 2308 uyarınca negatif TTL, SOA kaydının TTL’i ile SOA MINIMUM değerinin küçüğünden türetilir. Yeni alt alan adını ihtiyaçtan önce oluşturup yetkili sunucularda doğrula. Daha önce önbelleğe alınmış olumsuz cevabı, sonradan eklenen A kaydının kısa TTL’i ortadan kaldırmaz.
Yük Paylaşımı ve İki Uçlu Çalışma
Ağırlıklı DNS cevapları, yeni uca giden trafiği yaklaşık olarak artırmaya yardımcı olabilir; aynı çözümleyiciyi kullanan çok sayıda kişi tek önbellek cevabını paylaşabileceği için oranlar kullanıcı veya istek bazında kesin değildir. Çoklu A/AAAA kaydı da kendiliğinden sağlık kontrolü veya güvenli failover sağlamaz. Hangi uç seçilirse seçilsin yazma, oturum ve dosya tutarlılığı sağlanmalı; kesin istek bazlı dengeleme gerekiyorsa uygun proxy veya yük dengeleyici kullanılmalıdır.
Gerçek Hayatın Detayları: CDN, Apex Kayıt ve CNAME Flattening
Alan adının kökünde CNAME kullanamadığın durumlar olur. Burada sağlayıcına göre ALIAS/ANAME veya “flattening” gibi çözümler devreye girebilir. Basitçe şunu bilmek yeterli: Kökte başka bir adrese işaret etmek istiyorsan, sağlayıcının bu işi perde arkasında çözen bir özelliği vardır ya da yoktur. Varsa, geçiş planında bu aracı da hesaba katarsın. Bu konunun güzel anlatıldığı bir kaynak istersen, CNAME flattening’i açıklayan bu döküman işini görür. Önemli olan, burada TTL’in nerede uygulandığını anlamak ve değişiklikten önce düşürmeyi unutmamak.
CDN zaten ön taraftaysa orijin değişikliği, ziyaretçinin DNS kaydını değiştirmeden yapılabilir; ancak sağlayıcının orijin çözümleme ve bağlantı davranışını kontrol et. DNS TTL ile HTTP içerik önbelleği farklıdır. Orijin değişimi aynı kalan tüm dosyaların topluca temizlenmesini gerektirmez; eski dinamik veya değişen içerik için hedefli purge planla. Yeni orijinin TLS/SNI, Host başlığı, erişim izinleri ve kişisel yanıtları önbelleğe almama kurallarını doğrula.
E-Postayı Unutma: MX, SPF, DKIM ve Dostları
Web geçişi derken e-postayı geride bırakmak en sık yaptığımız hatalardan. MX kayıtlarının TTL’i yüksekse, yeni posta sunucusuna geçiş bazen saatler sürer. Bu sürede bazı mailler eskisine düşer, bazıları yenisine. Bunun panzehiri, geçişten önce MX, SPF ve DKIM gibi kayıtların TTL’ini düşürmek ve bir süreliğine her iki uçta da maillerin kabul edilmesini sağlamak. Eski sunucudan yeniye iletim kullanılıyorsa döngü, kopya teslim, SPF etkisi ve posta kutusu eşitlemesini planla. Eski sunucuya gelen mesajları kaybetmeden son senkronu tamamla.
Mail akışını doğrularken, eskiden kalma bir TXT kaydı yüzünden SPF’in beklenmedik şekilde başarısız olduğunu görmek moral bozabilir. Bu yüzden geçişten önce bu kayıtları tek tek gözden geçirmekte fayda var. “Gereksiz bir include var mı?”, “Yeni IP’lerim listelenmiş mi?”, “DKIM anahtarım doğru yerde mi?” gibi soruları küçük bir kontrol listesinden geçmek, taşınmanın sabahında yüz güldürür.
Yayılımı Takip Etmek: Ne Görüyoruz, Ne Zannediyoruz?
Bir kaydı değiştirdin ve “neden bende görünüyor da onda görünmüyor?” dediğinde, çoğu zaman farklı çözümleyicilerin önbellek süreleri devrededir. Farklı ağlardan test yapmak iyi fikir. Halka açık çözümleyiciler bazen sanki canlı bir monitör gibi kullanışlıdır. Örneğin Google Public DNS ile ilgili bu sayfa üzerinden mantığı okuyabilir, farklı ağlardaki durumu ayrı makinelerle deneyimleyebilirsin. Benzer şekilde Cloudflare’ın 1.1.1.1 çözümleyicisi farklı lokasyonlarda nasıl davrandığına dair pratik bir his verir.
Bir de tarayıcı ve işletim sistemi önbelleği var. DNS tarafında her şeyi doğru yaptığını bildiğin halde, tarayıcının ısrarla eskide kalması can sıkıcı olabilir. Bu gibi durumlarda farklı tarayıcı, farklı cihaz ve mümkünse farklı ağlarla kontrol etmek gerekir. Klasik ama etkili bir yöntem de yerel makinede hosts dosyasına yeni IP’yi yazıp uygulamayı gerçek ortamda gezmektir; böylece gerçek Host/SNI adıyla yeni ucu test edebilirsin. Bu yalnız yerel istemciyi etkiler; webhook veya ödeme sağlayıcısı gibi dış hizmetler normal DNS’i kullanmaya devam eder. Test sonrası hosts değişikliğini kaldır.
Kesintisiz Geçişin İncelikleri: Adım Adım Bir Senaryo
Bir senaryo düşünelim. Taşıma tarihini pazar gece yarısına koydun, çünkü trafik düşük. Önceki TTL ve bağımlılıklara yeterli pay bırakarak değişecek kayıtların TTL’ini düşürdün. Üç gün kala uygulama ve veritabanını yeni ortama aktardın, dosyaları senkronladın. İki gün kala yeni ortamda gerçek alan adını yerel hosts eşlemesiyle yeni IP’ye yönlendirerek son testleri yaptın. Arayüzdeki ufak bir yönlendirme problemini daha oradayken düzelttin. Bir gün kala oturum yönetimi, ödeme sayfası, e-posta tetiklemeleri ve görsel yükleme akışını gerçek trafikten bağımsız test ettin. Ödeme sağlayıcısının test ortamını ve kontrollü e-posta alıcılarını kullandın; gerçek tahsilat veya müşterilere yanlışlıkla bildirim oluşmasını önledin.
Varsayımsal geçişte son veri eşitlemesi tamamlandıktan ve tek yazma kaynağı doğrulandıktan sonra A/AAAA kayıtları yeni IP’lere alınır. Eski uca gelen kullanıcılar aynı veri kaynağına veya test edilmiş ters proxy yoluna ulaşır. Replikasyon gecikmesi, hata oranları, siparişler ve kuyruklar izlenir. İki saat gibi sabit bir süre, eski ucu kapatma ölçütü değildir; kalan trafik, açık bağlantılar, doğrulama sonuçları ve geri dönüş planı birlikte değerlendirilir.
NS Değişikliği, Kök Kayıtlar ve “Bir Taşla İki Kuş” Tuzakları
Otoritatif isim sunucularını değiştirmek başka bir başlık. NS değişikliği, registrar ve üst düzey alan adının da işin içinde olduğu, bu yüzden de yayılımın daha katmanlı ilerlediği bir süreç. IP değişikliğiyle aynı anda yapmak cazip gelebilir, ama riskli olur. Önce birini, sonra diğerini yapmak her zaman daha sakin. NS değişikliğinden önce yeni sağlayıcıdaki tüm sunucularda eşdeğer kayıtları ve imzaları doğrulamak, TTL ve SOA parametrelerinin beklediğin gibi olduğundan emin olmak ve küçük adımlarla ilerlemek önemlidir. Üst bölgedeki delegasyon NS/glue TTL’lerini, alt bölgedeki A TTL’sini düşürerek değiştiremezsin. DNSSEC kullanılıyorsa DS ve anahtar geçişini sağlayıcıların belgeli prosedürüyle ayrıca planla.
Eğer özel isim sunucuların varsa (ns1.seninalanadın.com gibi), gerekli glue kayıtlarını da geçiş envanterine al. Eski glue cevabını kullanan bir çözümleyici eski yetkili sunucu adresine gidebilir; bu durum yalnız apex kaydını değil, bölgedeki diğer adların çözümlemesini de etkileyebilir. Glue değişikliğini registrar tarafında ayrıca doğrula ve ölçümlü geçiş süresince eski ve yeni yetkili hizmetleri tutarlı biçimde ayakta tut.
Performans ve Sağlamlık: Biraz Dağıtık Düşünmek
Taşıma anlarının en güzel yanı, mimarini gözden geçirmek için harika bir fırsat sunması. Tek uç yerine iki ucu kısa süreliğine çalıştırdığında, “acaba kalıcı bir dengeleme kursam mı?” sorusu kendiliğinden gelir. Yükü dengeleyen, farklı bölgelerden hızlı yanıt veren ve arıza anında trafik yönlendirebilen bir DNS düzeni, sadece taşıma günleri için değil, her gün için huzur verir. İleride daha ileri seviye bir koruma kurmak istersen, Anycast DNS ve otomatik failover gibi yöntemler de düşünce dünyana eklenebilir; bunlar ayrı dayanıklılık araçlarıdır. Anycast DNS, kullanıcıların mevcut önbelleğini temizlemez; DNS failover da önbelleklerden dolayı anlık değildir.
Bu arada güvenlik ve performans ayarlarını da taşıma sonrasına bırakma. TLS ayarların, HSTS gibi başlıkların ve önbellek işaretlerinin yeni ortamda doğru çalıştığından emin ol. Küçük bir yönlendirme hatası, özellikle ödeme adımlarında, büyük bir terk oranına dönüşebiliyor. Taşıma gecesi “bitti” dediğinde gerçekten bittiğinden emin olmak için, en kritik akışları iki kez gezmek iyi hissettirir.
Rollback: Şemsiyeyi Yanında Taşı
Eski ortamı geri dönüş için erişilebilir tut, ancak DNS kaydını geri almak tek başına güvenli rollback değildir. Yeni ortamda kabul edilen yazıların eski ortama nasıl taşınacağı ve hangi uygulama sürümünün bu veriyi okuyacağı önceden belirlenmelidir. DNS önbellekleri nedeniyle her iki yol bir süre daha kullanılabilir. Hata eşiğini, veri uzlaştırma adımlarını ve trafik yönlendirme sırasını prova et; sabit birkaç dakikalık dönüş sözü verme.
Veri tarafında da “geri alınabilir” planlar kur. Ödeme, sipariş ve üyelik gibi işlemlerin güvenli tek yazma kaynağı veya doğrulanmış geçiş mekanizması yoksa, en azından geçiş penceresinde bu işlemleri kısa süreli bakım moduna almak daha güvenli olabilir. Alternatif olarak, sadece yazma operasyonlarını kilitleyip okuma operasyonlarını açık bırakmak da işe yarar. Böylece veri tutarlılığı bozulmadan nefes alırsın.
Sık Yapılan Hatalar ve Ufak Düzeltmeler
Yaygın planlama hatalarından biri, TTL’i son dakika düşürmektir. Bir diğeri, NS değişikliğini IP değişikliğiyle aynı anda yapmak. Üçüncüsü, sadece web trafiğine odaklanıp e-postayı unutmak. Dördüncüsü, geçişi kendi cihazından test edip her şey yolundaymış gibi düşünmek. Bunların hepsi küçük dokunuşlarla düzeliyor: Önceden planlama, adımları parçalama, farklı ağlardan test ve çift uçlu çalışma.
Bir de şu var: CDN veya WAF kullanıyorsan, onların arkasındaki kayıtların da kendi TTL ve önbellek mantıkları var. Orijin değişikliğini yapsan bile, kenar noktalarının temizlik planını unuttuğunda eski içerik bir süre daha yaşamaya devam edebilir. Geçiş notlarında DNS önbelleği, CDN orijin ayarı ve gereken hedefli içerik temizliği için ayrı kontrol maddeleri bulundur.
Adım Adım Pratik Bir Yol Haritası
Uygulanabilir sıra şöyle olabilir: mevcut kayıt ve TTL envanterini çıkar; değişecek TTL’leri önceki süreyi karşılayacak kadar erken düşür; yeni ucu gerçek alan adıyla yerel olarak test et. Son eşitlemeyi ve yazma devrini tamamla, A/AAAA veya gerekli hedefi değiştir, eski yolu tutarlı biçimde açık tut. Farklı ağlardan DNS ve uygulama akışlarını izle. Geri dönüşün artık gerekmeyeceği doğrulandığında eski yolu kapatıp TTL’leri hizmetin kararlılık gereksinimine göre yükselt.
Bu arada, daha geniş güvenlik ve süreklilik fotoğrafını tamamlamak istersen, altyapının geri kalan parçalarını da gözden geçirmelisin. DNS tarafındaki düzenin, uygulama tarafındaki dayanıklılıkla el ele yürüsün. Böylece tek bir adımın aksaması bütün geceyi gölgelemez.
Kapsamı Genişleten Okumalar
DNS’in alt türleri, kayıtların incelikleri ve küçük tuzaklar üzerine daha keyifli bir tur için, DNS kayıtlarını A’dan Z’ye anlatan rehberimizi inceleyebilirsin. Yayılımı farklı gözlerden kontrol etmek için Google Public DNS ile ilgili açıklamalar ve hızlı testler için Cloudflare 1.1.1.1 sayfası da işini kolaylaştırır. Apex’te CNAME benzeri davranışlar gerekiyorsa, CNAME flattening hakkında bir tur atmak akışını netleştirir.
Kapanış: Sessiz Bir Gece, Rahat Bir Nefes
Bir taşıma gecesinin en tatlı anı, grafikleri izlerken kahveni yudumladığın ve hiçbir şeyin kırılmadığını fark ettiğin an. Bunu mümkün kılan şey genelde büyük mucizeler değil, küçük planlar. TTL’leri önceden düşürmek, kademeli geçiş, çift uçlu çalışma ve geri dönüş kapısını açık tutmak gibi basit ama etkili alışkanlıklar. DNS yayılımını hızlandırmak diye bir düğme yok; ama yayılımı yönetilebilir hâle getiren sağlam adımlar var.
Umarım bu yazı, kafandaki sis bulutunu biraz dağıtmıştır. Önceden hazırlan, küçük adımlarla ilerle, test etmeyi bırakma ve kritik akışları iki kere doğrula. Takıldığın bir yerde nefes almayı unutma; bazen en iyi çözüm, bir adım geri atıp planı sadeleştirmek oluyor. Soruların olursa not al, bir sonraki yazıda belki onları konuşuruz. Şimdilik benden bu kadar; umarım bir sonraki taşıman sessiz ve pürüzsüz geçer. Görüşmek üzere.
