Zero-Downtime Taşıma İçin TTL Stratejileri: DNS Yayılımını Gerçekten Nasıl Hızlandırırsın?

Kafamızı Kurcalayan O Meşhur Yayılım: Giriş ve Küçük Bir Hikâye

Hiç gece yarısına doğru sitede küçük bir güncelleme yapıp, ardından “neden hâlâ eski sunucuya gidiyor?” diye kendi kendinize söylendiğiniz oldu mu? Benim oldu. Bir keresinde taşıma planı mükemmel gibiydi, testler şahane geçmişti, ama bir şeyi unuttum: TTL’i önceden düşürmeyi. O an anladım ki, DNS’in sabrı var, senin aceleciliğin var. O saatten sonra telaş başlıyor, ekibin bir kısmı yeni IP’yi görüyor, bir kısmı hâlâ eskide. İşte bu yazıyı o gecenin hatırasına yazıyorum; sıcacık bir kahve eşliğinde, “bir daha aynı şeyi yaşamayalım” diye.

Sana burada, zero-downtime taşıma için TTL stratejilerini en küçük pürüzlere kadar anlatmak istiyorum. Kuru bir teknik doküman gibi değil, gerçek hayatın içinden örneklerle, bazen can sıkıcı küçük ayrıntılarla, ama en çok da işi kolaylaştıran pratiklerle. DNS yayılımı denen şeyin nasıl çalıştığını, hızlandırmak için neleri önceden ayarlayabileceğini, kesintiyi hissettirmeden nasıl geçiş yapabileceğini ve olmazsa olmaz geri dönüş planını birlikte kuracağız. Mesela “TTL kaç olmalı?”, “NS kayıtlarını ne zaman değiştirmeliyim?”, “E-posta kayıtları taşınırken neyi unutmamalıyım?” gibi soruların hepsine adım adım değineceğ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 şu kadar dakika saat 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, değişiklikler hızlı yayılır; 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

Zero-downtime geçişin sırrı, bir süreliğine ikisini birden çalışır durumda tutmak. Yeni ortamı kur, veritabanını eşitle, medyayı taşı, ardından arka planda senkronu sürdür. Trafik tamamen yeni tarafa dönmeden eski tarafı kapatma. Bu, hem geri dönüş kapını açık tutar hem de kullanıcıların bir kısmının hâlâ eski DNS cevabını görmesi durumunda bile sitede problem yaşamamasını sağlar. Geçişin ilk dakikalarında “Siparişler yeni veritabanına mı gidiyor?” gerilimini böyle törpülersin.

TTL’i Ne Zaman Düşürmeli?

İdeal akış şöyle olur: Taşıma tarihinden birkaç gün önce kritik kayıtların TTL’ini düşür. A ve AAAA kayıtları başrol oyuncularıdır; CNAME kullandıysan o da sahnede. MX, TXT (özellikle SPF), DKIM ve DMARC gibi e-posta kayıtlarını da unutma. Bu ön hazırlık, geçiş anında “IP değişti, haydi hemen yeniye” demeni kolaylaştırır. TTL’i son dakika düşürmenin çoğu zaman işe yaramadığını yaşayarak öğrenenlerdenim; önbellekte daha önce tutulmuş değerler süre dolana kadar inat eder.

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ç.

Bir diğer gerçek de şu: Bazı çözümleyiciler kuralları düzgün uygular, bazıları biraz daha yavaş salıverir. Büyük servis sağlayıcıların geçişi genelde tahmin edilebilir olurken, yerel bazı servislerde eldeki önbellek beklenmedik kadar uzun tutulabilir. Bu yüzden geçiş anında “haydi oldu” demek yerine, belirli bir pencere boyunca iki ucun da ayakta kalması en akıllı yaklaşım.

TTL Stratejileri: Kademeli, Temkinli, Geri Dönüşlü

Adım Adım Zamanlama

Takvimini şöyle hayal et: Taşıma gününden bir hafta önce TTL’leri düşürmeye başla. Önce 24 saatten 1 saate, sonra 1 saatten 10 dakikaya. Bu kademeli düşüşle hem çözümleyicileri ani bir trafik artışına maruz bırakmaz, hem de senin sinir sistemini. Geçişten bir gün önce kritik kayıtların hepsi düşük TTL’de olsun. Geçişten birkaç saat önce son senkronu al, yeni ortamı nefes aldıran denetimlerle kontrol et, ardından kaydı değiştir.

Negatif Önbellek ve Küçük Sürprizler

Hiç var olmayan bir kaydı aratıp sonra eklediğinde, bazı çözümleyiciler “yok” bilgisini de bir süre tutar. Buna basitçe “yok bilgisinin beklemesi” diyelim. Eğer hemen ardından “var” dersen, bu önbelleğin dolmasını beklemek gerekebilir. Bu yüzden kritik bir kaydı ekleyeceksen, o kaydın daha önce “yok” olarak görülmemiş olmasına dikkat etmek iyi bir refleks. Küçük ama sinir bozan bir ayrıntı.

Yük Paylaşımı ve İki Uçlu Çalışma

Bazı servisler ağırlıklandırılmış yönlendirme sunar. Bu, trafiğin bir kısmını yeni tarafa, bir kısmını eski tarafa akıtarak kontrollü bir geçiş yapmanı sağlar. Destekleyen bir DNS sağlayıcın veya bulut hizmetin varsa, kademeli geçiş tarifsiz bir huzur getirir. Böyle bir imkân yoksa, çok basitçe her iki IP’yi de aynı içerikle hizmet verecek şekilde koşturmak da çoğu senaryoda yeterlidir.

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 kullanıyorsan işler aslında biraz kolaylaşır. Orijinini değiştirir, CDN’in TTL’ini ve önbellek davranışını da plana dahil edersin. CDN kenar noktalarındaki önbelleğin sinirini azaltmak için aşamalı temizleme yapmak hoş bir numaradır. Ben genelde önce düşük trafikli sayfalarda dener, ardından kritik sayfalara geçerim. Böylece sürpriz bir “404” veya beklenmedik bir yönlendirme hatası yakalarsam, zararı yaymadan düzeltebilirim.

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. Eğer altyapın destekliyorsa, eski sunucudan yeniye iletim köprüsü kurmak harikalar yaratır.

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 DNS’i beklemeden son kontrolleri yapabilirsin.

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. Bir hafta önceden TTL’leri kademe kademe düşürmeye başladın. Üç gün kala uygulama ve veritabanını yeni ortama aktardın, dosyaları senkronladın. İki gün kala yeni ortamda gerçek domain yerine geçici bir host adıyla 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.

Geçiş saati geldiğinde, önceden düşürülmüş TTL’lerin keyfini çıkararak A ve AAAA kayıtlarını yeni IP’lere yönlendirdin. Dakikalar içinde yeni trafik akmaya başladı. Eski tarafta gelen birkaç isteği loglardan izledin, beklediğin gibi küçük bir dilim kullanıcı hâlâ oraya düştü. Panik yok; çünkü eski uç da sorunsuz servis veriyor, veritabanı replikasyonun açık, ya da en azından sipariş oluşturma gibi kritik işlemler yeniden denemeye uygun. İki saat sonra trafik neredeyse tamamen yeni tarafta. O gece eski tarafa gelen son istekleri kontrol edip, “artık kapatabiliriz” demek kolaylaştı.

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ıda kayıtları hazırlamak, TTL ve SOA parametrelerinin beklediğin gibi olduğundan emin olmak ve küçük adımlarla ilerlemek nefes aldırır.

Eğer özel isim sunucuların varsa (ns1.seninalanadın.com gibi), glue kayıtları dediğimiz o küçük ama hayati bağları da işin içine alırsın. Bu bağların değişimi, özellikle apex tarafında beklenmedik gecikmeler yaratabilir. Bu yüzden DNS’nin köküne dokunduğunda, sabırlı davranmak ve bir süreliğine her iki tarafı da ayakta tutmak en mantıklısıdır.

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; benzer mantığı anlattığım yazılardan aldığım tat, pratikte iki kere kurtarıcı olmuştu.

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şı

En güzel planın bile yağmura yakalandığı olur. Bu yüzden geri dönüş kapısını baştan açık bırakmak önemli. Eski ortamı aceleyle kapatma, en azından kısa bir pencere boyunca sıcak tut. DNS tarafında geri adım atman gerekirse, önceden düşürdüğün TTL’ler yine avantaj sağlar. Birkaç dakikada trafiği eskiye çevirir, sorunu giderir ve tekrar denersin. Tüm bu süreçte logları bol bol koklamak, nerede takıldığını anlamanı kolaylaştırır.

Veri tarafında da “geri alınabilir” planlar kur. Ödeme, sipariş ve üyelik gibi işlemlerin iki uçta da anlık senkronu 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

En sık gördüğüm hataların başında, TTL’i son dakika düşürmek geliyor. 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. Ben bu yüzden geçiş notlarımda “CDN purge” diye kırmızı bir satır tutarım, o gece o satırın üstünü kalın bir çizgiyle çizerim.

Adım Adım Pratik Bir Yol Haritası

Şöyle akışkan bir yol haritası düşün: Taşıma tarihini belirle, ondan en az bir hafta önce kritik kayıtların TTL’ini düşür. İki-üç gün önce yeni ortamı kur, veri akışını senkronla, geçici alan adıyla doğrula. Bir gün önce uygulamanın en kritik akışlarını tek tek gez. Geçiş saatinde A ve AAAA kayıtlarını yeni IP’lere çevir, logları izle, hatayı yakalarsan geri dönüş kapın açık kalsın. Sonraki birkaç saat farklı ağlardan ve cihazlardan durumu kontrol et. Her şey yolundaysa, TTL’leri yavaşça tekrar yükselt, çünkü sonsuza kadar düşük tutmak da iyi fikir değil.

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.