Domain TTL ayarı nedir? Neden geçişte düşürülür?

Domain TTL ayarı, DNS (Domain Name System) yanıtlarının ne kadar süre önbellekte (cache) kalacağını belirler. Bu süre, özellikle sunucu taşıma, isim sunucusu (nameserver) değişimi veya sağlayıcı geçişi gibi zamanlaması kritik işlemlerde gecikmeye yol açar. Bu yazıda TTL’in ne olduğunu, düşürmenin geçişi nasıl hızlandırdığını ve pratikte hangi değerleri ne zaman kullanmanız gerektiğini net şekilde öğreneceksiniz.

DNS TTL nedir? Cache nasıl çalışır?

TTL, DNS kayıtlarının (A, AAAA, CNAME, MX vb.) ne kadar süre geçerli sayılacağını belirleyen sayıdır. DNS çözümleyiciler (recursive resolver) bir alan adına ait kaydı aldığında, aynı kaydı tekrar sorgulamak yerine belirlenen TTL süresi bitene kadar önbellekte tutar.

Örneğin: - Bir kullanıcı www.example.com için DNS sorgusu yapar. - DNS çözümleyici, authoritative (yetkili) kaynaktan yanıtı alır. - Bu yanıtta TTL değeri 3600 ise, çözümleyici bu kaydı 1 saat boyunca yeniden sorgulamaz. - TTL bitince tekrar authoritative kaynağa sorar.

TTL’nin etkisi sadece sizin DNS sunucunuzla sınırlı değildir. Cache katmanları vardır: - Tarayıcının/OS’in kendi DNS önbelleği (host cache) - İnternet servis sağlayıcısının (ISP) resolver cache’i - Genel DNS sağlayıcılarının (ör. 1.1.1.1, 8.8.8.8) cache’i - Kurumsal ağlarda firewall/DNS proxy önbelleği

Bu nedenle TTL düşürmek, geçiş hızını artırır ama “anında herkes aynı anda görür” garantisi vermez. Yine de TTL, geçişin kontrol edilebilir tarafıdır.

TTL ile “TTL değil, DNS yayılımı (propagation)” ilişkisi

TTL, “propagation süresini belirleyen en önemli parametrelerden biridir”. Yayılım süresi genellikle şu bileşenlerin toplamına yaklaşır: - TTL’in bitmesi (cache’in yenilenmesi) - Bazı resolver’ların cache temizleme davranışları (bazıları daha agresif yenileyebilir) - DNS kayıtlarının gerçekten güncellenmesi (panelde doğru kayıt seti)

DNS geçişinde neden TTL düşürülür?

Domain geçişinde TTL düşürme hedefi şudur: eski kaydın (veya eski IP’nin) önbellekten daha kısa süre çıkması. TTL’i düşürdüğünüzde, resolver’lar kayıt değişikliğini daha erken tekrar sorgular.

Geçiş senaryoları için pratik örnekler: - Nameserver (ör. ns1/ns2) değişimi: DNS kaynakları değiştiği için kayıtların otoritesi yeni sunucuya geçer. - A kaydı / AAAA kaydı değişimi: Web sitesi veya e-posta sunucusu IP değiştirir. - CNAME hedefi değişimi: Örneğin www kaydını yeni bir barındırma altyapısına yönlendirdiniz.

TTL düşürmezseniz ne olur? - Bazı resolver’lar eski kaydı saatlerce hatta 24-48 saate kadar cache’leyebilir. - Kullanıcılar aynı anda farklı sonuç görür: bazıları eski siteye gider, bazıları yeni siteye gider. - Geçiş tamamlandı zannedip TTL yükseltmeye geçtiğinizde, eski cache daha uzun süre “inatçı” kalabilir.

Bu yüzden profesyonel geçiş planlarında TTL düşürme, kontrollü bir “geçiş penceresi” oluşturmak için kullanılır.

Geçiş planı: TTL’i ne zaman düşürmelisiniz?

TTL’i geçişten hemen önce düşürmek, tüm cache’lerin yenilenmesini beklemek için yeterli olmayabilir. Daha doğru yaklaşım, TTL’i bir geçiş penceresi oluşturacak şekilde önceden düşürmektir.

Net kural önerisi: - DNS değişikliğinden en az 24-48 saat önce TTL’i düşürün. - Geçiş çok kritikse (örn. e-ticaret): mümkünse 72 saate uzatın.

Neden 24-48 saat? - Çünkü mevcut cache TTL’i hâlâ yüksekse (ör. 3600 veya 86400), bazı resolver’lar eski kaydı o süre bitene kadar saklar. - Siz TTL’i düşürseniz bile, o anda cache’leri zaten oluşmuş resolver’lar eski TTL’e göre davranır.

TTL’i ne kadar düşürmelisiniz? (Net değer önerileri)

TTL için tek bir “herkese uyan” sayı yoktur; ancak operasyonel olarak kullanışlı aralıklar vardır. Amacınız, geçişte gecikmeyi azaltırken DNS sorgu yükünü aşırı artırmamaktır.

Genel pratik aralıklar

• Geçiş öncesi (kısa TTL): 300–900 saniye (5–15 dk)
• Normal dönem: 3600 saniye (1 saat) veya 21600 saniye (6 saat)

Bunlar tipik operasyon aralıklarıdır. Çok daha düşük TTL (ör. 60 saniye) bazı sistemlerde gereksiz sorgu trafiği oluşturabilir; ayrıca her yerde aynı hızda görünmez. Hedefiniz geçişi hızlandırmak olduğu için 5-15 dakikalık aralık çoğu senaryoda dengelidir.

Hangi kayıtları düşürmelisiniz?

Her DNS kaydı eşit derecede kritik değildir.

Öncelik sırası genellikle şöyledir: 1. A / AAAA (web trafiği) 2. CNAME (www veya alt servisler) 3. MX (mail trafiği) 4. TXT (SPF, DKIM, DMARC) 5. SRV (gerekiyorsa)

Not: E-posta geçişinde TTL düşürmek önemlidir çünkü MX kaydı değişince e-posta teslimi gecikebilir. SPF/DKIM/DMARC TXT kayıtlarında da doğrulama için doğru değerler kritik olur.

Geçişte TTL düşürmenin riskleri ve kontrol noktaları

TTL düşürmenin tek yönlü bir faydası yok; doğru kontrol yapılmazsa geçiş planınız boşa gidebilir.

Risk 1: Yanlış kayıt setiyle çok hızlı cache yenileme

TTL’i düşürünce, hatalı bir kayıt hızlı yayılır. - Örnek: A kaydını yanlış IP’ye işlerseniz, resolver’lar daha erken tekrar sorgular ve hatalı yönlendirmeyi daha hızlı görür.

Çözüm: - Panelde kayıtları değiştirmeden önce “önizleme”/değişiklik ekranını kontrol edin. - Mümkünse önce yeni hedefi test edin (staging) ve yalnızca gerekli kayıtları güncelleyin.

Risk 2: Nameserver değişimiyle TTL algısının karışması

Nameserver değişiminde bazı kullanıcılar yeni yetkili kaynağı görmeden önce eski yolu cache’leyebilir. TTL burada dolaylı etkili olur; asıl belirleyici, nameserver yönlendirmesinin oturması ve ilgili kayıtların authoritative tarafta doğru servis edilmesidir.

Çözüm: - Nameserver geçişlerinde TTL’den önce “doğru nameserver’lar doğru domain için aktif mi?” kontrolü yapın.

Risk 3: E-posta doğrulama kırılması (SPF/DKIM/DMARC)

MX ve TXT birlikte düşünülmelidir. SPF/DKIM/DMARC doğrulamaları doğru değerler olmadan e-postalar spam’a düşebilir.

Çözüm: - MX’i güncellemeden hemen önce TXT kayıtlarınızın yeni değerleri doğru mu doğrulayın. - DKIM için anahtar (public key) seçeneğini ve seçim yapılan selector’ı (örn. default) kontrol edin.

Kontrol noktaları (net ve uygulanabilir)

Geçiş boyunca şu testleri rutin yapın: - nslookup / dig ile ilgili kaydın hangi değeri döndürdüğünü doğrulayın. - Farklı resolver’larla bakın (örn. yerel DNS, 1.1.1.1, 8.8.8.8) çünkü cache davranışı değişebilir. - Web için HTTP status kontrolü: 200/301/302 beklediğiniz gibi mi? - E-posta için doğrulama: SPF/DKIM/DMARC sonuçlarını gönderdiğiniz test e-postalarında inceleyin.

Örnek komutlar: - dig A www.example.com +noall +answer - dig MX example.com +noall +answer

TTL’i düşürmeden önce mutlaka yapmanız gerekenler

TTL değişikliği “kayıt güncellemesi” ile birlikte planlanmazsa tek başına çözüm olmaz.

1) Hedef altyapıyı hazır edin

Yeni sunucu/hosting hazır değilse TTL düşürmek, trafiği hızlı şekilde hataya yönlendirebilir. - DNS’e bağlanacak yeni IP veya load balancer hazır olmalı. - Güvenlik duvarı (firewall) ve portlar doğru olmalı. - SSL sertifikası (HTTPS) planı net olmalı (sertifika yeni hedefe bağlanacak şekilde).

2) Kayıt haritasını çıkarın

Geçişten sonra “hangi kayıt neydi?” karmaşasını önleyin. - A/AAAA/CNAME: domain ve alt domainler - MX: öncelikler (priority) ile birlikte - TXT: SPF/DKIM/DMARC

Bu harita sayesinde yanlış bir kaydı hızlı fark edersiniz.

3) Değişiklik penceresi belirleyin

TTL düşürdüğünüz günlerde kontrollü ilerleyin. - Gün içinde değişiklikleri çok sık yapmayın. - “Rollback” (geri alma) planınız olsun: yanlış bir durumda eski kaydı hızlı geri koymak.

Geçiş sonrası TTL’i yükseltmeli misiniz?

Evet. Çünkü geçiş bittiğinde uzun süre düşük TTL kullanmak DNS sorgu trafiğini artırabilir.

Net öneri: - Geçiş tamamlandıktan ve doğrulamalar stabil hale geldikten sonra (ör. 24 saat içinde beklenen sonuçlar tutarlıysa) TTL’i normal aralığa çekin. - Normal dönem için çoğu senaryoda 3600 saniye (1 saat) veya 21600 saniye (6 saat) iyi bir denge sağlar.

Net sonuç: TTL ile geçiş süresini kontrol edin

Domain TTL ayarı, DNS cache süresini belirleyen ve geçiş gecikmelerini doğrudan etkileyen bir parametredir. Geçişte TTL’i düşürmek, eski kayıtların önbellekten daha erken çıkmasını sağlar ve yeni yönlendirmelerin daha hızlı oturmasına yardım eder. En doğru yaklaşım; TTL’i değişiklikten 24-48 saat önce düşürmek, web (A/AAAA/CNAME) ve e-posta (MX + TXT) kayıtlarını birlikte planlamak, ardından geçiş stabil olunca TTL’i normal değere çekmektir.

Aksiyon önerisi: Geçiş takviminizi çıkarın; önce DNS kayıt haritanızı hazırlayın, TTL’i geçişten 24-48 saat önce 300–900 saniye aralığına çekin, değişiklikten sonra farklı resolver’larla doğrulama yapın ve geçiş oturduğunda TTL’i 3600 veya 21600 saniyeye geri alın.