DNS TTL Nedir ve Doğru Değer Seçimi

Bir alan adının A kaydını değiştirdiniz, yeni sunucunuzu hazırladınız, her şey tamam. Ama bir de bakıyorsunuz ki bazı ziyaretçiler hâlâ eski sunucuya düşüyor, kimileri yeni sunucuyu görüyor, aradaki fark saatlerce sürüyor. Bu kararsızlığın arkasındaki tek sayı çoğu zaman TTL değeridir. TTL, yani "Time To Live", bir DNS kaydının çözümleyiciler tarafından ne kadar süre önbellekte tutulacağını saniye cinsinden söyleyen küçük ama etkisi büyük bir ayardır. Doğru ayarlandığında bir taşıma işlemini pürüzsüz hâle getirir, yanlış ayarlandığında ise günlerce süren tutarsızlıklara yol açar.

Bu rehberde TTL'in tam olarak ne işe yaradığını, düşük ve yüksek değerlerin pratikte neye mal olduğunu, bir sunucu ya da e-posta geçişi öncesinde TTL'i nasıl adım adım düşürmeniz gerektiğini ve farklı kayıt türleri için hangi değerlerin makul olduğunu anlatacağım. Komut satırından TTL'i nasıl okuyup doğrulayacağınıza, sık yapılan hatalara ve en çok merak edilen sorulara da yer verdim. Amacım, TTL'i ezberlenmiş bir "3600 yaz geç" değeri olmaktan çıkarıp, ne zaman düşürüp ne zaman yükselteceğinizi bilinçli seçebildiğiniz bir araca dönüştürmek.

TTL Nedir ve Nasıl Çalışır#

TTL, bir DNS kaydına iliştirilmiş bir zaman etiketidir ve o kaydın kopyasını alan her çözümleyiciye "bu bilgiyi en fazla şu kadar saniye önbelleğinde tut, sonra bana tekrar sor" der. Değer saniye cinsindendir. Örneğin TTL'i 3600 olan bir A kaydını sorgulayan bir çözümleyici, aldığı cevabı bir saat boyunca hafızasında tutar ve bu süre içinde aynı isim tekrar sorulduğunda otoritatif sunucuya hiç gitmeden kendi kopyasından yanıt verir.

Bu mekanizma DNS'in bu kadar hızlı ve ölçeklenebilir çalışmasının temel nedenidir. Dünyadaki her tarayıcı her istekte kök sunuculara kadar tırmanmak zorunda kalsaydı sistem ilk günü çökerdi. Önbellek sayesinde popüler alan adları için cevaplar kullanıcıya en yakın çözümleyicide hazır bekler. Süreç kabaca şöyle işler:

• Kullanıcının bilgisayarı ya da işletim sistemi kaydı sorar.
• Sorgu, internet servis sağlayıcısının ya da 1.1.1.1 gibi bir kamu çözümleyicisinin önbelleğine düşer.
• Önbellekte kayıt varsa ve TTL süresi dolmamışsa cevap oradan gelir, otoritatif sunucuya hiç gidilmez.
• TTL süresi dolmuşsa çözümleyici otoritatif sunucuya taze bir sorgu atar, gelen cevabı yeni TTL süresi kadar tekrar saklar.

Buradaki kritik nokta şudur: TTL'i siz otoritatif tarafta ayarlarsınız, ama sayacı çözümleyici işletir. Yani TTL'i 300 saniyeye düşürseniz bile, o düşük değeri henüz görmemiş, elinde eski uzun TTL'li kayıt bulunan bir çözümleyici o eski süre dolana kadar sizi dinlemeye başlamaz. TTL değişikliğinin etkisini görmek için önce eski TTL'in sona ermesini beklemeniz gerekir. Bu ayrıntı, taşıma planlamasının neden birkaç gün öncesinden başladığını açıklar.

TTL Değeri Saniye Cinsinden Ne Anlama Gelir#

TTL her zaman saniye olarak yazılır, ama kafada saatlere çevirince daha anlamlı olur. Sık kullanılan değerlerin karşılığı şöyledir:

Pek çok DNS paneli varsayılan olarak 3600 (bir saat) veya 14400 (dört saat) ile gelir. Bu değerler günlük hayatta iş görür çünkü çoğu kayıt aylarca değişmez. Ama unutmayın ki yüksek bir varsayılan, acil bir değişiklik gerektiğinde başınıza iş açar. Sunucunuz çöktüğü için trafiği yedek IP'ye almak istediğinizde, TTL'iniz 86400 ise değişikliğin herkese ulaşması bir günü bulabilir.

Bir başka önemli ayrıntı, çözümleyicilerin TTL'i her zaman harfiyen uygulamayabilmesidir. Bazı kamu çözümleyicileri çok düşük TTL'lere alt sınır koyar; örneğin siz 30 yazsanız da onlar minimum bir değere yuvarlayabilir. Bazı ISP'ler ise kendi önbelleklerini agresif tutup TTL süresi dolduktan sonra bile bir süre eski cevabı vermeye devam edebilir. Yani TTL bir "kesin garanti" değil, bir "üst sınır talebi"dir. Pratikte iyi davranan çözümleyiciler değerinize uyar, ama planınızı yaparken küçük bir tolerans payı bırakmakta fayda var. Önbelleklerin nasıl davrandığını ve bir değişikliğin neden herkese aynı anda ulaşmadığını daha derinlemesine merak ediyorsanız DNS propagasyon süresi yazısı bu tabloyu tamamlar.

Düşük TTL mi Yüksek TTL mi#

TTL seçiminde her zaman iki uç arasında bir denge kurarsınız: hız mı, verimlilik mi. İkisini birden en üst düzeyde alamazsınız, bu bir ödünleşmedir.

Düşük TTL, kaydınızın kısa sürede önbellekten düşmesi ve yeniden sorulması demektir. Bu, değişikliklerinizin hızla yayılması anlamına gelir; TTL'i 300 olan bir kaydı değiştirdiğinizde en fazla beş dakika içinde neredeyse herkes yeni değeri görür. Karşılığında otoritatif sunucularınıza çok daha sık sorgu gelir. Küçük bir siteyseniz bunun maliyeti sıfıra yakındır, ama günde milyonlarca istek alan bir alan adında düşük TTL, DNS altyapınıza ciddi bir yük bindirir ve yanıt gecikmelerini bir miktar artırabilir.

Yüksek TTL ise tam tersidir. Kaydınız uzun süre önbellekte kaldığı için otoritatif sunucularınıza az sorgu gelir, kullanıcılar cevabı hep yakındaki önbellekten alır, çözümleme çok hızlıdır. Fakat bir değişiklik yapmanız gerektiğinde bunun yayılması yavaştır ve acil durumlarda elinizi kolunuzu bağlar. İşte iki yaklaşımın karşılaştırması:

Doğru yaklaşım genellikle "duruma göre" olur. Kayıtlarınız kararlı ve nadiren değişiyorsa, örneğin kurumsal e-postanızın MX kayıtları ya da alan adı sunucusu NS kayıtları, yüksek TTL mantıklıdır çünkü bunları yılda bir kez bile değiştirmezsiniz. Buna karşılık aktif bir load balancer arkasındaki ya da yakında taşıyacağınız bir A kaydı için düşük TTL daha akıllıcadır. En yaygın strateji ise şudur: normal zamanda makul-yüksek bir değer (örneğin 3600) kullanın, bir değişiklik yapacağınız zaman geçici olarak düşürün, işlem bitince tekrar yükseltin.

Taşıma Öncesi TTL Düşürme Taktiği#

Bir siteyi ya da e-postayı yeni bir sunucuya taşıyacaksanız, taşımanın en can sıkıcı kısmı geçiş anındaki kararsızlıktır. Ziyaretçilerin bir kısmı eski sunucuya, bir kısmı yenisine düşer; bu sırada eski sunucuya gelen form gönderimleri, siparişler ya da e-postalar kaybolabilir. Bu pencereyi kısaltmanın en etkili yolu, taşımadan önce TTL'i düşürmektir. Buradaki en önemli kural şudur: TTL'i düşürmenin faydasını görmek için düşürmeyi geçişten en az bir eski-TTL süresi kadar önce yapmalısınız. Çünkü değişikliğin yayılması, o an önbellekte duran eski uzun TTL'in sona ermesine bağlıdır.

Diyelim ki mevcut A kaydınızın TTL'i 14400 (dört saat). Planınız şöyle olmalı:

• Taşımadan en az 4-5 saat önce: TTL'i 300 saniyeye düşürün. Değeri değiştirdiniz ama IP'yi henüz değiştirmediniz. Bu adımın amacı, çözümleyicilerin ellerindeki dört saatlik eski kaydın süresi dolduktan sonra artık beş dakikalık taze kayıtlar tutmaya başlamasıdır.
• Bekleme: Eski dört saatlik TTL tamamen sona erene kadar bekleyin. Bu süre dolduğunda artık neredeyse tüm çözümleyiciler kaydınızı yalnızca beş dakika saklıyor demektir.
• Geçiş anı: Yeni sunucu hazır olunca A kaydının IP'sini değiştirin. Artık değişiklik en fazla beş dakika içinde her yere ulaşacaktır.
• İzleme: Her iki sunucunun erişim loglarını izleyin. Eski sunucuya gelen trafik beş on dakika içinde kesilmelidir.
• Taşımadan sonra: Her şey oturunca TTL'i tekrar 3600 ya da 14400'e yükseltin ki gereksiz sorgu yükü oluşmasın.

Değişiklikleri komut satırından doğrulamak istiyorsanız dig bunun için idealdir. Kaydın hem değerini hem de o anki TTL'ini gösterir:

# A kaydını ve TTL'ini otoritatif sunucudan sorgula
dig +noall +answer example.com A @ns1.clou.tr

# Bir kamu çözümleyicisinin önbellekte tuttuğu güncel TTL'i gör
# Cevaptaki TTL sayısı her sorguda azalır, sıfırlanınca yeniden sorulur
dig example.com A @1.1.1.1

Çıktının ikinci sütunundaki sayı o kaydın kalan TTL'idir ve arka arkaya sorguladıkça geri saydığını görürsünüz. Bir sunucu ya da e-posta geçişini bu disiplinle yaparsanız kesinti penceresi dakikalar mertebesine iner. Geçişin uygulamalı adımlarını site taşıma hizmetimizle ya da bir sonraki taşımada işinizi kolaylaştıracak DNS önbellek temizleme yöntemleriyle birlikte planlayabilirsiniz.

Farklı Kayıt Türleri için TTL Önerileri#

Her kayıt türü aynı sıklıkta değişmez, dolayısıyla hepsine tek bir TTL vermek zorunda değilsiniz. İşte pratikte iyi çalışan bir başlangıç şablonu:

Bu tabloyu bir zorunluluk değil, mantık çerçevesi olarak görün. Bir BIND zone dosyasında TTL hem dosyanın başında bir varsayılan ($TTL) olarak hem de her kaydın yanında ayrı ayrı belirtilebilir:

$TTL 3600
@       IN  SOA   ns1.clou.tr. hostmaster.example.com. (
                  2026071001 ; serial
                  7200       ; refresh
                  3600       ; retry
                  1209600    ; expire
                  3600 )     ; minimum (negatif cevap TTL'i)

@           IN  A       203.0.113.10
www    300  IN  A       203.0.113.10   ; düşük TTL, taşımaya hazır
mail 86400  IN  A       203.0.113.20   ; çok kararlı
@           IN  MX  10  mail.example.com.

Burada www kaydına 300, mail kaydına 86400 verildiğine dikkat edin; her kayıt kendi ihtiyacına göre etiketlenir, dosyanın başındaki $TTL 3600 ise değeri belirtilmeyen tüm kayıtlar için geçerlidir. SOA kaydının en sonundaki minimum alanı ise "negatif önbellek" süresidir; yani bir kaydın bulunamadığı cevabının ne kadar saklanacağını belirler. Bunu makul tutmak, yeni eklediğiniz bir kaydın "yok" cevabının uzun süre önbellekte takılı kalmasını engeller.

TTL'i Kontrol Etme ve Doğrulama#

TTL'i ayarladıktan sonra gerçekten ne olduğunu görmeden emin olmayın; DNS'te "ayarladım öyleyse çalışıyor" varsayımı çoğu sorunun kaynağıdır. Otoritatif değeri ile önbellekteki değer birbirinden farklı görünebilir, bu normaldir. Otoritatif sunucudan sorguladığınızda hep ayarladığınız tam değeri görürsünüz; bir çözümleyiciden sorguladığınızda ise o anki kalan süreyi görürsünüz.

Farklı araçlarla aynı kaydı kontrol etmek iyi bir alışkanlıktır:

# Kaydın kaynaktaki gerçek TTL değeri (otoritatif)
dig +noall +answer example.com A @ns1.clou.tr

# Google DNS'in önbelleğindeki kalan TTL
dig example.com A @8.8.8.8

# Cloudflare DNS'in gördüğü değer
dig example.com A @1.1.1.1

# Windows tarafında hızlı bakış
nslookup -type=A example.com 1.1.1.1

dig'i art arda çalıştırdığınızda çözümleyicinin verdiği TTL'in geri saydığını görürsünüz; sayı sıfıra ulaşınca çözümleyici otoritatif sunucuya yeniden gider ve TTL tam değere sıçrar. Bu davranışı gözlemlemek, önbelleğin gerçekten sizin ayarınıza uyduğunu doğrulamanın en temiz yoludur. Değişiklik yaptınız ama hâlâ eski değeri mi görüyorsunuz? Büyük ihtimalle henüz eski TTL süresi dolmamıştır; sabırla bekleyin ya da farklı çözümleyicilerden kontrol edin. Kendi bilgisayarınızın ya da tarayıcınızın inatçı önbelleğini boşaltmanız gerekiyorsa DNS önbellek temizleme adımlarını uygulayabilirsiniz. DNS kayıtlarınızı ve TTL değerlerinizi tek panelden yönetmek isterseniz hosting paketlerimiz ve alan adı hizmetimiz DNS yönetim arayüzüyle birlikte gelir.

Sık Yapılan Hatalar#

TTL basit bir sayı gibi görünse de etrafında tekrar tekrar karşılaştığım birkaç klasik hata var. Bunları bilmek çoğu baş ağrısını baştan önler.

Birinci hata, TTL'i taşımadan hemen önce düşürmektir. TTL'i geçişten beş dakika önce 300'e çektiyseniz ama eski değeriniz dört saatti, o dört saatlik kayıt hâlâ birçok önbellekte duruyor demektir; düşük TTL'iniz ancak eski süre dolduktan sonra devreye girer. Düşürme işlemini önceden yapmak esastır.

İkinci hata, kalıcı olarak çok düşük TTL kullanmaktır. Bazı yöneticiler "her ihtimale karşı" tüm kayıtlarını 60 saniyede bırakır. Bu, otoritatif sunuculara gereksiz yük bindirir ve çözümleme gecikmesini bir miktar artırır. Düşük TTL bir taşıma aracıdır, sürekli bir durum değil; iş bitince yükseltin.

Üçüncü hata, TTL'i değişikliğin kendisi sanmaktır. TTL'i değiştirmek IP'yi ya da kaydın içeriğini değiştirmez; yalnızca o kaydın gelecekte ne kadar saklanacağını ayarlar. Asıl değişikliği ayrıca yapmanız gerekir.

Dördüncü hata, negatif önbellek TTL'ini unutmaktır. Yeni bir kayıt eklediğinizde ve "hâlâ görünmüyor" dediğinizde, sorun çoğu zaman o ismin daha önce sorulup "yok" cevabının SOA minimum TTL'i kadar önbelleğe alınmış olmasıdır. SOA minimum değerini makul tutmak bu tür gecikmeleri kısaltır.

Sıkça Sorulan Sorular#

TTL değerini kaç saniye yapmalıyım?#

Kararlı, nadiren değişen kayıtlar için 3600 (bir saat) sağlam bir varsayılandır ve çoğu site için yeterlidir. Bir taşıma, e-posta geçişi ya da failover senaryosu planlıyorsanız, işlemden birkaç saat önce ilgili kaydı 300 saniyeye düşürün, işlem bittikten sonra tekrar 3600 ya da 14400'e yükseltin. NS ve MX gibi çok kararlı kayıtları 86400'de bırakabilirsiniz.

TTL'i düşürünce değişiklik neden hemen hızlanmıyor?#

Çünkü düşük TTL ancak çözümleyicilerin elindeki eski TTL süresi dolduktan sonra devreye girer. TTL'iniz dört saatti ve az önce 300'e düşürdüyseniz, o an önbellekte duran dört saatlik kayıtların süresi bitene kadar birçok çözümleyici hâlâ eski hıza göre davranır. Bu yüzden düşürmeyi taşımadan en az bir eski-TTL süresi kadar önce yapmak gerekir.

TTL sıfır yaparsam ne olur?#

TTL 0 teorik olarak "hiç önbelleğe alma" anlamına gelir ve her sorguda otoritatif sunucuya gidilmesini ister. Uygulamada birçok çözümleyici bunu ya tümden reddeder ya da kendi minimum değerine yuvarlar, ayrıca otoritatif altyapınıza aşırı yük biner. Çok kısa bir pencere için bile 60 ya da 300 gibi küçük ama sıfır olmayan bir değer tercih edin.

TTL değişikliğini nasıl doğrularım?#

Komut satırından dig example.com A @1.1.1.1 çalıştırın; cevaptaki TTL sayısını arka arkaya sorgulayarak geri saydığını görün. Otoritatif değeri kontrol etmek için sorguyu doğrudan alan adı sunucunuza yöneltin, örneğin dig +noall +answer example.com A @ns1.clou.tr. İkisi arasındaki farkın normal olduğunu, birinin kaynak değeri, diğerinin kalan süreyi gösterdiğini unutmayın.

Her kayıt için farklı TTL kullanabilir miyim?#

Evet ve çoğu zaman en doğrusu budur. Zone dosyasında ya da DNS panelinizde her kaydın yanına ayrı bir TTL yazabilirsiniz; dosyanın başındaki $TTL yalnızca değeri belirtilmeyenler için varsayılan olur. Sık değişen bir web A kaydına 300, yıllarca sabit kalan bir NS kaydına 86400 vermek tamamen mantıklıdır ve DNS altyapınızı gereksiz yüke sokmadan esneklik sağlar.

TTL güvenlikle ilgili bir ayar mı?#

Doğrudan bir güvenlik ayarı değildir, ama dolaylı etkileri vardır. Çok düşük TTL, DNS tabanlı bir saldırı sırasında kaydı hızlıca temiz bir adrese yönlendirmenizi kolaylaştırır; çok yüksek TTL ise ele geçirilmiş bir kaydın uzun süre önbelleklerde kalmasına yol açabilir. Yine de asıl koruma katmanı WAF ve DDoS koruma gibi hizmetlerdir; TTL bunların yerini tutmaz, yalnızca acil müdahale esnekliğinizi etkiler.

Kapanış#

TTL'i tek cümlede özetlemek gerekirse: kayıtlarınızın ne kadar süre önbellekte tutulacağını belirleyen ve değişikliklerin ne hızla yayılacağını kontrol eden bir denge ayarıdır. Normal zamanda makul-yüksek bir değer kullanarak altyapınızı verimli tutar, bir taşıma ya da geçiş öncesinde geçici olarak düşürerek kesinti penceresini dakikalara indirir, işlem bitince tekrar yükselterek gereksiz yükü ortadan kaldırırsınız. Bu üç adımı doğru sıralamak, çoğu DNS kaynaklı baş ağrısını daha başlamadan çözer.

Clou.TR'de alan adınızın DNS kayıtlarını ve TTL değerlerini kolay bir arayüzden yönetebilir, taşıma ve geçiş süreçlerinde bu denetimi tam olarak elinizde tutabilirsiniz. Yeni bir projeye başlıyorsanız hosting paketlerimize ve alan adı hizmetimize göz atın; daha fazla kontrol isteyen ekipler için VDS sunucularımız ve sunucu yönetimi hizmetimiz DNS dâhil tüm altyapınızı uzman desteğiyle yönetmenizi sağlar. Bir sonraki taşımanızı planlarken TTL'i düşürmeyi unutmayın; küçük bir sayı, büyük bir fark yaratır.