Black Friday Öncesi E-ticaret Sitesi DNS Hazırlığı

Kasım geldiğinde e-ticaret ekiplerinin dikkati genellikle kampanya sayfalarına, indirim oranlarına ve ödeme akışına çekilir. DNS ise "zaten çalışıyor" diye geçilir. Oysa trafiğin birkaç saat içinde on kata çıktığı bir günde, DNS katmanındaki küçük bir hazırlıksızlık saatlerce erişilemezlik anlamına gelebilir; bu süreyi kimse fark etmeden kapatmak mümkün değildir.

Black Friday hazırlığında DNS'in rolü ikiye ayrılır: trafik artışı öncesinde esneklik sağlamak ve bir sorun anında hızlı müdahale edebilmek. Çok origin'li yapı çoklu CDN planına yaslanır. İki hedef çelişkili görünür; esneklik değişim gerektirir, hızlı müdahale ise önceden test edilmiş yolları gerektirir. İyi bir planlama ikisini aynı anda mümkün kılar.

Aşağıdaki adımlar bir e-ticaret sitesinin etkinlik öncesinde DNS katmanında yapması gerekenleri kapsar: TTL düşürme zamanlaması, A ile CNAME arasındaki pratik farklar, CDN origin kaydı yapılandırması, failover testi ve Cloudflare cache kurallarının DNS boyutu.

DNS TTL'yi Ne Zaman Düşürmelisiniz?

TTL (Time to Live), bir DNS kaydının çözümleyiciler tarafından önbellekte tutulma süresini belirler. Çoğu e-ticaret sitesi bu değeri 3600 saniye ya da daha yüksek tutar; düşük TTL daha fazla sorgu hacmi anlamına gelir ve bazı DNS sağlayıcıları sorgu sayısına göre fatura kestiğinden bu fark göz ardı edilmez. Black Friday yaklaşırken TTL bir sigorta gibi çalışır: bir sunucu ya da CDN origin değiştirmeniz gerektiğinde, değişiklik tam olarak o TTL kadar sürede yayılır.

Hangi kayıtlara öncelik verilmeli? Ana domain ve www alt alan adının A veya CNAME kayıtları ile CDN ile sunucu arasındaki origin kayıtları. MX ve TXT kayıtlarını bu süreçten bağımsız tutabilirsiniz; e-posta akışını gereksiz yere etkilemez.

Zamanlamada kilit nokta şudur: mevcut TTL değerinin sona ermesini bekleyin, ardından yeni değer yayılsın. TTL değeriniz 86400 saniye ise ve etkinlikten 24 saat önce 300 saniyeye düşürürseniz, bir kısım çözümleyici yeni değeri almadan etkinliğe gireceksiniz demektir. Etkinlikten 48-72 saat önce yapılan bir TTL düşürme bu riski ortadan kaldırır.

TTL değerini 60 saniyenin altına düşürmek çoğu durumda gereksizdir. Bazı çözümleyiciler bu sınırın altındaki değerleri yok sayarak minimum 30-60 saniye uygular. 300 saniye, acil müdahale senaryolarının büyük bölümü için yeterlidir.

Düşük TTL'yi etkinlik sonrasında süresiz bırakmayın. Otorite DNS sunucularınıza gelen sorgu hacmi artar; bu gecikme hem gereksiz maliyet hem de altyapıya fazladan yük doğurur. Etkinlik bittikten 24-48 saat içinde TTL'yi 1800-3600 saniye aralığına döndürün.

A Kaydı mı, CNAME mı? Yüksek Trafikte Pratik Fark

Apex domain (example.com) için yalnızca A kaydı kullanabilirsiniz; RFC standardı CNAME'i apex'te açıkça yasaklar. Çözüm ALIAS/ANAME veya flattening katmanındadır. Alt alan adları için CNAME seçeneği geçerlidir; ancak bu seçim bazı pratik sonuçlar doğurur.

CNAME kullanıldığında DNS çözümlemesi bir adım daha uzar: önce CNAME hedefi bulunur, ardından o hedefin A kaydı sorgulanır. CDN sağlayıcıların büyük çoğunluğu bu zinciri kısaltmak için CNAME flattening ya da ALIAS kaydı sunar. DNS sağlayıcınız ALIAS veya ANAME desteği veriyorsa, apex domain için bunu değerlendirin; kullanıcı hem CDN'in anycast ağından hem de daha kısa çözümleme süresinden yararlanır.

Trafik yüksek geldiğinde A kaydının sabit IP işaret etmesi bir dezavantaja dönüşebilir. CDN, arka planda sunucu ekleyip çıkarırken siz hâlâ tek bir IP adresine bağlı kalırsınız. CNAME veya ALIAS ile CDN sağlayıcınızın kendi yük dengeleme mantığını devreye alırsınız. Bulut altyapısında zone yapılandırması söz konusu olduğunda bu ayrım özellikle kritiktir; managed zone'lar üzerinden A yerine ALIAS kullanmak otomatik ölçeklemeyle uyumu kolaylaştırır.

Değişiklik yapmadan önce mevcut kayıtlarınızı not edin. Apex'te A kaydını CNAME'e çevirme girişimi hata verir; bunun yerine A kaydının değerini CDN'in sağladığı IP listesiyle güncelleyin ya da ALIAS desteği olan bir DNS sağlayıcısına geçin.

CDN Origin Kaydını Doğru Yapılandırmak

CDN, kullanıcıdan gelen isteği edge node'larında karşılar; önbellekte yoksa asıl sunucuya (origin) gider. Bu origin adresini CDN'e bildirmenin yolu genellikle bir CNAME ya da A kaydıdır: origin.example.com gibi bir alt alan adı oluşturursunuz, bunu sunucunun gerçek IP'sine ya da yük dengeleyicisine yönlendirirsiniz.

Origin alt alan adını doğrudan herkese açık hale getirmeyin. Bunu yaparsanız trafik CDN'i atlayarak doğrudan sunucuya ulaşabilir; DDoS süzgeci, cache katmanı ve coğrafi yönlendirme devre dışı kalır. Origin sunucunuzun gerçek IP adresini CDN dışına sızdırmamak için güvenlik duvarı kuralları ekleyin; yalnızca CDN'in IP aralıklarından gelen bağlantılara izin verin.

CDN geçişi sırasında SSL sertifikası doğrulaması için ek TXT veya CNAME kayıtları gerekebilir. Bu kayıtların TTL'si doğrulama tamamlanana kadar düşük tutulabilir; ancak doğrulama sonrasında kaldırmayı unutmayın. Eski CNAME kayıtları bazen beklenmedik yönlendirmelere yol açar.

Bir CDN sağlayıcısından diğerine geçiş yapıyorsanız, eski origin CNAME kaydını hemen silmeyin. Her iki yapılandırmayı birkaç saat paralel çalıştırın; yeni yapılandırma kararlı göründükten sonra eski kaydı kaldırın. Acele silme işlemleri, önbelleği henüz yenilenmemiş kullanıcılar için kopuk bağlantı yaratır.

Failover Testi: Gerçek Trafik Gelmeden Önce Deneyin

Failover, birincil sunucu ya da bölge erişilemez olduğunda trafiği yedek adrese yönlendirmektir. DNS tabanlı failover'da bu geçiş, birincil kaydın kaldırılması ve yedek A veya CNAME kaydının eklenmesiyle gerçekleşir; bazı DNS sağlayıcıları bunu otomatik sağlık kontrolüyle (health check) yönetir.

Test etmeden güvenmeyin. Prova şöyle işler: etkinlikten bir hafta önce birincil kaydı geçici olarak yedek adrese yönlendirin, yayılmasını bekleyin ve sitenin yedek origin'den doğru çalıştığını doğrulayın. Ardından birincil adrese geri dönün. Bu test birkaç şeyi açığa çıkarır: failover TTL'niz gerçekten düşük mü, yedek sunucunuzun kapasitesi yeterli mi ve sertifika yapılandırmanız yedek origin'de de çalışıyor mu?

Test çalışır. Geri alırsınız. Basit ama atlanan adım budur.

Komut satırında basit bir doğrulama için nslookup ya da dig kullanabilirsiniz:

dig example.com A +short
nslookup example.com

Beklenen IP'yi görüyorsanız değişiklik yayılmıştır. Farklı coğrafyalarda yayılmayı doğrulamak için çeşitli ülkelerden DNS sorgusu yapan web tabanlı araçlar kullanılabilir. Birden fazla subdomain üzerinden trafik dağıtıyorsanız her kaydı ayrı ayrı doğrulayın; tek bir subdomain'in sağlıklı görünmesi diğerlerinin de düzgün çalıştığını garanti etmez.

Cloudflare Cache Kurallarının DNS Boyutu

Cloudflare'i hem DNS sağlayıcısı hem de proxy olarak kullandığınızda, DNS kayıtlarınızın "proxied" (turuncu bulut) mı yoksa "DNS only" (gri bulut) mı olduğu her şeyi belirler. Proxied modda trafik Cloudflare'in ağından geçer; cache, firewall ve rate limiting aktiftir. DNS only modda bu katmanlar devre dışıdır.

Black Friday öncesinde hangi kayıtların proxied, hangilerinin DNS only olduğunu gözden geçirin. Ana site için A ve CNAME kayıtları genellikle proxied olmalı; ama origin sunucuya işaret eden iç kayıtlar ya da API endpoint'leri için bu tercih her zaman doğru değildir. Proxied origin kaydı, bazı durumlarda CDN ile origin arasında beklenmedik bir döngü yaratabilir.

Cache kuralları (Page Rules veya Cache Rules) DNS katmanından bağımsız gibi görünse de, bir kaydın proxy durumu bu kuralların uygulanıp uygulanmayacağını belirler. Proxy olmadan cache kuralları çalışmaz. Özel domain kurulumlarında sık karşılaşılan sorunların bir kısmı tam da bu ayrımdan kaynaklanır: kayıt DNS only bırakıldığında Cloudflare katmanı devreye girmediğinden cache kuralları sessizce etkisiz kalır.

Etkinlik için özel bir subdomain kullandıysanız, örneğin kampanya.example.com, bu kaydı da proxied modda açın ve cache kurallarının o subdomain'i kapsadığını doğrulayın. Cloudflare'deki önbellek temizleme (cache purge) işlemi de DNS kaydının proxied olmasını gerektirir; DNS only modda purge isteği gönderilse de etkisi olmaz.

Etkinlik Öncesi Son Kontrol Listesi

Aşağıdaki kontroller etkinlikten 48-72 saat önce tamamlanmış olmalı. Bunlar birbirinden bağımsız adımlardır; farklı ekip üyeleri paralel yürütebilir.

1. TTL düşürme: Ana domain ve www için TTL 300 saniyeye indirildi mi? Eski TTL sona erdi mi?
2. Origin kaydı doğrulaması: origin.example.com doğru IP'ye işaret ediyor mu? Güvenlik duvarı yalnızca CDN IP aralıklarına izin veriyor mu?
3. Failover testi tamamlandı: Yedek origin'den başarılı servis doğrulandı mı? Geri dönüş test edildi mi?
4. Cloudflare proxy durumu: Kampanya subdomain'i proxied mı? Cache kuralları o subdomain'i kapsıyor mu?
5. SSL sertifikası: Hem birincil hem yedek origin için sertifika geçerliliği kontrol edildi mi? Yakın vadede sona erme var mı?
6. Eski kayıtların temizlenmesi: Kullanılmayan A veya CNAME kayıtları kaldırıldı mı? Atıl kayıtlar saldırı yüzeyi oluşturur.

Örnek senaryo: Bir e-ticaret sitesi etkinlikten 60 saat önce www ve apex domain TTL'sini 86400'dan 300'e düşürdü. 48 saat sonra failover testini çalıştırdı; yedek origin sertifika hatası verdi çünkü sertifika yalnızca birincil alt alan adı için düzenlenmişti. Sertifikaya wildcard eklendi, test tekrar çalıştırıldı ve başarıyla geçildi. Etkinlik günü herhangi bir DNS müdahalesi gerekmedi.

Domain kayıtlarını düzenli envanter halinde takip etmek, bu tür kontrolleri kolaylaştırır; etkinlik öncesi listeyi sıfırdan çıkarmak yerine güncel bir kayıt tablosu üzerinden çalışırsınız ve hangisinin aktif, hangisinin atıl olduğunu hemen görürsünüz.

Black Friday günü DNS değişikliği yapmaktan kaçının. TTL ne kadar düşük olursa olsun, anlık bir değişiklik bazı kullanıcılar için geçiş süresi yaratır ve bu süre içinde hangi kullanıcının hangi kaydı gördüğü tahmin edilemez. Tüm değişiklikler etkinlikten en az 24 saat önce tamamlanmış olmalı; etkinlik günü ise izlemeye odaklanın.

DNS kayıtlarınızın durumunu izlemek için otorite DNS sunucularınıza periyodik sorgular gönderen basit bir script ya da sağlayıcınızın sunduğu uyarı mekanizmaları yeterlidir. Beklenmedik bir TTL artışı, yanlışlıkla değiştirilen bir kayıt ya da ortadan kalkan bir proxy durumu bu yolla birkaç dakika içinde fark edilir; saatler sonra keşfetmek yerine erken tespit, müdahale penceresini açık tutar.