DNS TTL Değerlerini Doğru Ayarlamak: A, MX, CNAME ve TXT Kayıtları İçin Stratejik Rehber

DNS TTL Nedir ve Neyi Kontrol Eder?

DNS yapılandırması yaparken çoğu zaman A, MX, CNAME veya TXT kayıtlarını ekler, değeri yazar, bir de TTL alanına hızlıca 300 ya da 14400 yazıp geçeriz. Oysa TTL (Time To Live), DNS tarafında yaptığınız her değişikliğin ne kadar sürede etkili olacağını, hata yaptığınızda ne kadar süre canınızın yanacağını ve kesinti planlarken elinizde ne kadar manevra alanı olduğunu belirler. DCHost olarak sahada gördüğümüz sorunların önemli bir kısmı yanlış TTL stratejisinden kaynaklanıyor: Taşıma öncesi düşürülmeyen TTL yüzünden uzayan DNS yayılımları, e-posta geçişlerinde günlerce süren kuyruk sorunları, gereğinden düşük TTL sebebiyle gereksiz DNS trafiği ve yavaşlayan resolver yanıtları gibi.

Bu yazıda TTL kavramını sadece teorik olarak anlatmakla kalmayacağız; A, MX, CNAME ve TXT kayıtları için pratik, senaryo bazlı TTL stratejileri paylaşacağız. Canlı site taşıma, e-posta altyapısı değişikliği, CDN kullanımı, SPF/DKIM/DMARC güncellemeleri gibi gerçek hayatta sık yaşanan durumlarda hangi kayıtta, ne kadar süreyle, hangi TTL değerini tercih etmeniz gerektiğini adım adım netleştireceğiz. Eğer DNS tarafında daha temel kavramları da tazelemek isterseniz, önce DNS kayıtları nedir, A, AAAA, CNAME, MX ve TXT nasıl çalışır yazımıza göz atmanız faydalı olabilir.

TTL, DNS Yayılımı ve Kesinti Riskini Nasıl Etkiler?

TTL, bir DNS kaydının resolver ve istemciler tarafından önbellekte kaç saniye tutulacağını belirler. Örneğin TTL değeri 3600 ise, bu kayıt genellikle en fazla 1 saat boyunca cache’te kalır. Bir ziyaretçi ilk isteğinde gerçek DNS sunucunuza sorar, sonucu alır, sonraki isteklerde TTL dolana kadar cache’teki değeri kullanır.

Bu mekanizma üç kritik sonucu beraberinde getirir:

• Yük azaltma: Yüksek TTL değerleri, DNS sunucunuza gelen sorgu sayısını ciddi şekilde azaltır.
• Değişiklik hızı: IP, e-posta sağlayıcısı veya doğrulama kayıtlarını değiştirdiğinizde, TTL süresi boyunca eski değerler dünyada dolaşmaya devam eder.
• Hata penceresi: Yanlış kayıt girdiğinizde, yüksek TTL ile bu hata uzun süre görünür olmaya devam eder.

TTL, halk arasında sık kullanılan “DNS yayılım süresi” algısının da merkezindedir. Çoğu kişi, DNS yayılım süresi neden 24 saat sürer diye sorduğunda aslında önceden ayarlanmış yüksek TTL değerlerinin sonuçlarını yaşıyordur. İyi haber şu ki, doğru planlama ile bu yayılım sürelerini yönetmek mümkün. Hatta DCHost tarafında anlattığımız gibi, zero‑downtime taşıma için TTL stratejileri uygulayarak kesintisiz geçişler bile yapabilirsiniz.

A Kayıtları İçin TTL Stratejisi

A kaydı (ve IPv6 için AAAA) genellikle web sitenizi, API’larınızı veya uygulama sunucularınızı işaret eder. Yanlış TTL kararı, özellikle trafik yoğun sitelerde doğrudan erişilebilirlik ve performans sorunları olarak geri döner.

Kurumsal web siteleri ve bloglar için önerilen TTL

Kurumsal tanıtım siteleri, bloglar veya sık sık IP değiştirmediğiniz, klasik paylaşımlı hosting ya da sabit IP’li VPS üzerinde çalışan siteler için TTL’i 3600–14400 saniye (1–4 saat) aralığında tutmak genellikle ideal bir dengedir.

• 3600 sn (1 saat): Küçük IP değişikliklerinde makul hızda yayılım, aynı zamanda makul DNS sorgu yükü.
• 7200–14400 sn (2–4 saat): Çok nadir IP değiştiren, son derece stabil altyapılarda tercih edilebilir.

Neden 24 saat değil de 1–4 saat? Çünkü IPv4 fiyatlarının ve IP taşıma ihtiyaçlarının arttığı bu dönemde altyapılar daha sık değişiyor. DCHost müşterilerinde de zaman zaman sunucu yükseltme, farklı veri merkezine taşıma gibi senaryolar görüyoruz. TTL’i 86400 saniye (24 saat) yaparsanız, bu tür operasyonlarda manevra alanınızı gereksiz yere daraltmış olursunuz.

Yüksek trafikli e‑ticaret ve SaaS uygulamaları için TTL

E‑ticaret, marketplace veya SaaS uygulamalarında, arka planda sık sık ölçeklendirme, node değişikliği veya load balancer IP güncellemeleri yapılabiliyor. Bu tür senaryolarda 300–1800 saniye (5–30 dakika) aralığı genelde daha gerçekçi:

• 300 sn (5 dakika): Aktif failover, blue‑green deployment veya sık IP değişimi varsa.
• 900–1800 sn (15–30 dakika): Aylık veya birkaç ayda bir yaşanan planlı değişiklikler için iyi bir kompromi.

TTL’yi 60 sn gibi çok düşük tutmak teoride çekici görünse de pratikte çoğu işletme için gereksiz ve maliyetlidir. Resolver trafiğiniz artar, bazı resolver’lar agresif cache stratejileri yüzünden TTL’i tam anlamıyla uygulamayabilir. 300 sn çoğu gerçek dünyadaki operasyon için fazlasıyla yeterli, aynı zamanda DNS sorgu yükünü de makul seviyede tutan bir değerdir.

IP değişikliği, taşıma ve failover senaryolarında TTL oyunu

A kayıtları, taşıma ve IP değişikliği senaryolarının başrol oyuncusu. DCHost tarafında canlı taşıma yaparken genelde şu oyunu uyguluyoruz:

1. Normalde: Örneğin TTL 3600 sn.
2. Taşımadan 24–48 saat önce: TTL’i 300–600 sn’ye düşürüyoruz.
3. Resolver cache’lerinin yeni TTL’i benimsemesi için: En az 1–2 eski TTL süresi kadar bekliyoruz (yani 1–2 saat).
4. Taşıma anında: A kaydını yeni IP’ye alıp birkaç saat trafiği gözlüyoruz.
5. Her şey stabil: TTL’i tekrar 1800–3600 sn seviyelerine yükseltiyoruz.

Böylece hem DNS yayılım süresini fiilen dakikalar seviyesine indiriyor, hem de uzun vadede gereksiz derecede düşük TTL ile DNS altyapısını yormamış oluyoruz. Kendi operasyonlarınızda da aynı mantığı uygulayabilirsiniz.

MX Kayıtları İçin TTL Stratejisi

MX kayıtları, alan adınıza gelen e‑postaların hangi sunuculara teslim edileceğini belirler. E‑posta trafiği doğası gereği daha toleranslıdır: SMTP sunucuları geçici hatalarda yeniden deneme yapar, sıraya alır. Bu yüzden MX için TTL tercihi, A kayıtlarına göre biraz daha farklı düşünülmelidir.

Standart işletme e‑posta altyapısı için TTL

Günlük e‑posta trafiğinizin aktığı, sık sık e‑posta sağlayıcısı değiştirmediğiniz bir yapıda MX kayıtları için 3600–86400 saniye (1–24 saat) aralığı uygundur:

• 3600–7200 sn: Altyapı üzerinde ara sıra değişiklik yapan, IP veya hostname güncellemesi ihtimali olan firmalar için.
• 14400–86400 sn: Uzun süre stabil kalan, yıllarca aynı e‑posta altyapısını kullanan kurumlar için.

Burada kritik nokta şu: MX kayıtları genellikle hostname (örneğin mail.ornek.com) gösterir, bu hostname’in arkasındaki A kaydı ise daha kısa TTL’e sahip olabilir. Böylece MX kayıtlarınız nispeten sabit kalırken, asıl IP değişikliklerini A kaydı üzerinden daha hızlı yönetebilirsiniz.

Yeni e‑posta sağlayıcısına geçiş planı ve MX TTL

E‑posta sağlayıcısı veya kendi mail sunucunuzu değiştirirken en sık yapılan hata, geçişten hemen önce MX kaydını değiştirmek ama TTL’i unutmaktır. Sağlıklı bir plan şöyle olmalı:

1. Geçişten 48–72 saat önce mevcut MX kayıtlarının TTL’ini 600–1800 sn aralığına düşürün.
2. Bu yeni TTL’in dünya genelinde benimsenmesi için en az 1 eski TTL süresi kadar bekleyin.
3. Yeni e‑posta altyapınızı test edin; gerektiğinde birden fazla MX kaydı ile split delivery veya backup MX senaryosu kurgulayın.
4. MX kayıtlarını yeni sağlayıcıya yönlendirin ve SMTP loglarını dikkatle izleyin.
5. Her şey yolunda ise TTL’i tekrar 3600–14400 sn seviyesine yükseltin.

Böylece MX değişikliğinizin etkisi dakikalar içinde hissedilir hale gelir; günlerce süren karışık teslim senaryolarından kaçınmış olursunuz.

Backup MX ve çoklu MX kayıtlarında TTL

Eğer yapınızda yedeklilik için birden fazla MX kaydı kullanıyorsanız (örneğin öncelik 10 ana sunucu, öncelik 20 backup sunucu), TTL değerlerini de tutarlı tutmak önemlidir. Genellikle:

• Tüm MX kayıtlarının aynı TTL değerine sahip olması önerilir.
• Backup MX’in işaret ettiği A kayıtlarının TTL’i, ana MX IP’lerinden bir tık daha düşük tutulabilir (örneğin ana 3600, backup 1800) ki değişiklikler daha hızlı yansısın.

Backup MX, felaket senaryolarında devreye girer; bu yüzden yanlış yapılandırılmış bir backup MX, fark edilene kadar sessizce e‑postaları gereksiz yere geciktirebilir. TTL stratejinizin bu mimariyi desteklediğinden emin olun.

CNAME Kayıtları İçin TTL Stratejisi

CNAME kayıtları genellikle CDN, üçüncü taraf servisler, subdomain yönlendirmeleri ve çoklu ortam (blog, mağaza, panel) yapılarında kullanılır. Burada hem sizin hem de işaret ettiğiniz tarafın değişim sıklığı belirleyicidir.

CDN, statik içerik ve alt alan adları

CDN’ler ve statik içerik servisleri bazen arka plandaki IP adreslerini sık değiştirebilir. Siz alan adınızı onların size verdiği hostname’e CNAME ile yönlendirirsiniz. Böyle bir durumda:

• CNAME’in TTL’ini genellikle 300–1800 sn aralığında tutmak mantıklıdır.
• CDN sağlayıcınız çok sık dinamik routing yapıyorsa, 300–600 sn daha güvenli olabilir.

Bu sayede CDN tarafındaki değişiklikler ziyaretçilerinize daha hızlı yansır. Ancak aşırı düşük TTL değerleri CDN’in size önerdiği sınırlar ile çelişmemeli; bazı sağlayıcılar minimum TTL tavsiyesinde bulunur. DCHost müşterilerinde gördüğümüz iyi pratik, kritik alt alanlar (www, app) için 300–600 sn, daha az kritik statik alanlar için 900–1800 sn civarında kalmak.

Üçüncü taraf servis entegrasyonlarında CNAME TTL

CRM, ticket sistemi, analitik ya da benzeri SaaS ürünlerine subdomain yönlendirdiğinizde (örneğin support.ornek.com) altyapı genellikle çok sık IP değiştirmez; değişiklik olduğunda da sağlayıcı tarafında çoğunlukla kendi DNS’inde yönetilir.

• Bu tür CNAME kayıtları için 1800–7200 sn aralığı pratik ve dengeli bir seçimdir.
• Entegrasyonun kritikliği yüksek, ancak değişim sıklığı düşükse 3600–7200 sn iyi çalışır.

Böylece, sağlayıcı tarafındaki DNS değişiklikleri makul sürede yansır; siz de kendi DNS sunucularınızı gereğinden fazla sorguyla yormamış olursunuz.

Kök alanda CNAME kısıtı ve alternatifler

Standart DNS kurallarına göre kökte (örnek.com) CNAME kullanılamaz; burada genellikle A, AAAA ve/veya ALIAS/ANAME gibi sağlayıcıya özgü sanal kayıt türleri kullanılır. TTL stratejisi açısından bu şu anlama gelir:

• Kök alanın A kaydının TTL’i genellikle 300–3600 sn aralığında tutulmalı; aşırı yüksek TTL, IP değiştirdiğinizde SEO ve erişilebilirlik açısından risklidir.
• www gibi CNAME ile işaret edilen alt alan adlarında ise 300–1800 sn, özellikle taşıma ve CDN senaryolarında ideal dengeyi sağlar.

Kök alan için TTl belirlerken, sadece web trafiğini değil; aynı zamanda API, mobil uygulama ve entegrasyonların da bu domaine bağlı olup olmadığını göz önünde bulundurun.

TXT (SPF, DKIM, DMARC vb.) Kayıtları İçin TTL Stratejisi

TXT kayıtları genellikle e‑posta doğrulama (SPF, DKIM, DMARC), güvenlik politikaları (MTA‑STS, TLS‑RPT, BIMI) ve servis doğrulama (Google, Facebook, arama motorları vb.) gibi amaçlarla kullanılır. Bu kayıtlar doğrudan son kullanıcı trafiğini değil, çoğunlukla e‑posta teslim edilebilirliğini ve entegrasyon güvenilirliğini etkiler.

SPF kayıtları için TTL

SPF kaydı, alan adınızın hangi IP veya sunuculardan e‑posta göndermeye yetkili olduğunu tanımlar. Yanlış SPF yapılandırması, e‑postalarınızın spam klasörüne düşmesine veya direkt reddedilmesine yol açabilir. Bu nedenle SPF için TTL seçerken şu denge önemli:

• Günlük/haftalık değişiklik yapıyorsanız: 600–1800 sn
• Nadiren değişiklik yapıyorsanız: 3600–14400 sn

Özellikle birden fazla e‑posta servisi kullanıyorsanız ve gelişmiş SPF yönetimi ve 10 DNS lookup limitine takılmama gibi konularla uğraşıyorsanız, test dönemlerinde TTL’i 600–900 sn gibi daha düşük tutmak, hatalı yapılandırmaları hızlıca düzeltmenizi sağlar.

DKIM ve DMARC için TTL

DKIM public key’leri ve DMARC politikaları genellikle SPF kadar sık değişmez. Buna rağmen, ilk kurulum ve test sürecinde düşük TTL kullanmak, ardından stabil hale gelince artırmak iyi pratiktir:

• İlk kurulum/test: 900–1800 sn
• Stabil dönem: 3600–86400 sn (1–24 saat)

DMARC politikası (örneğin p=none → p=quarantine → p=reject geçişleri) yaparken, değişikliğin etkisini görmek için önce 900–1800 sn gibi nispeten düşük bir TTL ile başlayıp, raporları analiz ettikten sonra TTL’i artırabilirsiniz. DKIM anahtar rotasyonu planlı, nadir bir işlem olduğundan, key’ler oturduktan sonra TTL’i 14400–86400 sn seviyesine çekmek genelde sorun çıkarmaz. Ayrıntılı e‑posta doğrulama stratejisi için SPF, DKIM ve DMARC nedir ve nasıl kurulur yazımızı da inceleyebilirsiniz.

Doğrulama ve güvenlik odaklı diğer TXT kayıtları

Google Search Console, Microsoft 365, Facebook, çeşitli SaaS ürünleri vb. için eklediğiniz TXT doğrulama kayıtları genellikle sadece ilk doğrulama aşamasında kritik olur, sonrasında nadiren dokunulur. Bu senaryoda:

• İlk doğrulama süreci: 300–900 sn (hızlı yayılım için)
• Doğrulama tamamlandıktan sonra: 3600–86400 sn (hatta isterseniz daha da yüksek)

MTA‑STS, TLS‑RPT, BIMI gibi güvenlik ve görünürlük odaklı TXT kayıtlarında da benzer strateji uygulanabilir: İlk kurulumda düşük TTL, stabil ve doğrulanmış politikalar için yüksek TTL. Bu tür kayıtlar da doğrudan son kullanıcı trafiğinden çok, e‑posta güvenliği ve marka görünürlüğü tarafında etki yaratır.

Farklı Senaryolar İçin Önerilen TTL Değerleri

Aşağıdaki tablo, DCHost olarak sahada sık gördüğümüz senaryolar için pratik TTL önerilerini özetliyor. Elbette her projenin ihtiyaçları farklı olabilir; ancak bu değerler iyi bir başlangıç noktası sağlar.

DCHost Panelinde TTL Yönetimi İçin Pratik İpuçları

DCHost altyapısında DNS yönetimini yaparken TTL’i her kayıt ekleyişinizde bilinçli seçmenizi öneririz. Pratikte uygulayabileceğiniz birkaç ipucu:

• Varsayılan TTL’i mantıklı bir seviyede tutun: Örneğin 3600 sn; böylece yeni eklenen kayıtlar için fena olmayan bir taban değeri olur.
• Taşıma ve büyük değişikliklerden önce TTL’i planlayın: Yeni sunucuya geçecekseniz, zero‑downtime taşıma rehberimizde anlattığımız gibi birkaç gün önce TTL düşürme planı yapın.
• E‑posta kayıtlarını grup halinde düşünün: MX, SPF, DKIM ve DMARC kayıtlarınızı aynı anda değerlendirip, özellikle test dönemlerinde hepsine benzer TTL pencereleri tanımlayın.
• Geçici kayıtlar için çok düşük TTL kullanın: Sadece test amaçlı açtığınız alt alanlar veya geçici yönlendirmeler için 60–300 sn TTL kullanıp iş bitince kaydı tamamen silin.
• DNS değişikliklerini loglayın: Hangi gün, hangi kaydın TTL’ini değiştirdiğinizi bir dokümana yazmak, sorun anında geriye dönüp bakarken büyük kolaylık sağlar.

Özellikle e‑posta tarafında sorun yaşıyorsanız, hem DNS hem SPF/DKIM/DMARC hem de MX mimarisini birlikte ele almak gerekir. Bu noktada çoklu MX ve yedekli e‑posta altyapısı kurulumu yazımız ile SPF, DKIM, DMARC rehberimizi birlikte okumanızı öneririz.

Sonuç ve Yol Haritası

TTL, DNS ekranında gördüğünüz küçük bir sayı gibi dursa da, aslında kesinti riskinizi, hata pencerelerinizi ve operasyonel esnekliğinizi doğrudan belirleyen kritik bir parametre. A kayıtlarında çok yüksek TTL ile IP değişikliklerini günlerce sürüncemede bırakmak da, TXT kayıtlarında gereksiz derecede düşük TTL ile DNS altyapısını yormak da orta ve uzun vadede baş ağrısına dönüşebiliyor. Sağlam bir strateji için kaydı türüne göre düşünmek, normal dönem ve geçiş dönemleri için farklı TTL seviyeleri tanımlamak en sağlıklı yaklaşım.

DCHost olarak DNS, hosting, VPS, dedicated sunucu ve colocation altyapılarımızda müşterilerimize tam da bu bakış açısıyla yol gösteriyoruz: Önce mimariyi ve değişim sıklığını anlamak, sonra TTL ve DNS tasarımını ona göre şekillendirmek. Siz de alan adınızı yeni bir sunucuya taşımayı planlıyor, e‑posta sağlayıcınızı değiştirmek istiyor veya karmaşık bir çoklu ortam (blog, mağaza, panel, API) mimarisi kuruyorsanız, DNS ve TTL tarafında birlikte detaylı bir plan çıkarabiliriz. Mevcut DCHost hizmetiniz üzerinden kontrol paneline girip kayıtlarınızı gözden geçirmeye bugün başlayın; birkaç küçük TTL dokunuşunun bile ne kadar fazla rahatlık sağladığını kısa sürede fark edeceksiniz.