EN
← Bloga dönRehberler

DNS TTL Nedir? Kaç Olmalı, Ne Zaman Düşürülmeli?

DNS TTL nedir, çözümleyiciler onu nasıl sayar, hangi kayıtta TTL kaç olmalı, negatif önbellek nedir ve bir DNS değişikliği eski veri görünmeden nasıl planlanır?

Yayınlanma: · 5 dk okuma

TTL ("time to live", yaşam süresi), her DNS kaydına iliştirilen ve bir çözümleyicinin yanıtı yeniden sormak zorunda kalmadan kaç saniye önbellekte tutabileceğini söyleyen sayıdır. Bir DNS değişikliğinin kullanıcılara ne kadar çabuk ulaşacağı üzerindeki tek gerçek kontrolünüz budur. "DNS yayılması neden bu kadar sürüyor?" sorusunun yanıtı da TTL'dir.

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

Zone'daki her kaydın bir TTL değeri vardır:

www.example.com.   3600   IN   A   192.0.2.10

Özyinelemeli bir çözümleyici (internet sağlayıcınızınki, ofisinizdeki ya da 1.1.1.1, 8.8.8.8 gibi herkese açık olanlar) bu kaydı yetkili sunucudan aldığında saklar ve 3600'den geriye saymaya başlar. Sonraki bir saat içinde o çözümleyiciye soran herkes önbellekteki kopyayı, kalan TTL ile alır. Sayaç sıfırlanınca kayıt atılır ve bir sonraki sorgu yeni bir çözümlemeyi tetikler.

Bunu kendiniz izleyebilirsiniz:

$ dig +noall +answer www.example.com @1.1.1.1
www.example.com.   3412   IN   A   192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com.   3397   IN   A   192.0.2.10

İkinci sayı azaldı. Yetkili sunucuya doğrudan sorarsanız her zaman ayarlanmış tam değeri görürsünüz:

$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com.   3600   IN   A   192.0.2.10

Bu fark kullanışlı bir teşhis aracıdır: ayarlanandan düşük bir TTL görüyorsanız bir önbelleğe bakıyorsunuz demektir.

Bu mekanizmanın üç sonucu vardır:

  • Hiçbir şey "gönderilmez". Kaydı değiştirmek hiçbir çözümleyiciye haber vermez. Her önbellek, kendi sayacı bitene kadar eski yanıtı tutar.
  • Önbellekler farklı anlarda boşalır, çünkü her biri kaydı farklı bir anda almıştır. Değişiklikten sonra bir TTL süresi boyunca farklı kullanıcılar farklı yanıt görür. "DNS yayılması" dediğimiz şey bundan ibarettir.
  • Önemli olan eski TTL'dir. Kaydı dün 86400 TTL ile önbelleğe almış bir çözümleyici, bugün ne ayarlarsanız ayarlayın, o 24 saatin kalanını bekler.

Kontrol edemediğiniz önbellekler

Tek önbellek özyinelemeli çözümleyici değildir. İşletim sistemleri, tarayıcılar ve uygulamalar da kendi önbelleklerini tutar ve hepsi TTL'e tam uymaz: tarayıcılar adresleri kısa, sabit bir süre saklar; uzun süre çalışan uygulamalar (klasik örnek eski Java çalışma ortamlarıdır) bir sorgunun sonucunu süreç yaşadığı sürece tutabilir. Bazı çözümleyiciler alt ya da üst sınır uygular: 5 saniyelik bir TTL 30 ya da 60 saniye gibi işlem görebilir, çok uzun TTL'ler bir gün civarında kırpılabilir. Yetkili sunuculara ulaşılamadığında çözümleyiciler süresi geçmiş veriyi kısa bir süre daha sunabilir.

Yani TTL güçlü bir ipucudur, garanti değildir. Bir değişikliğin tam N saniye sonra "her yerde" görüneceğini vaat etmek dürüst olmaz.

Negatif önbellek: "böyle bir ad yok" yanıtının TTL'i

Çözümleyici, "bu ad yok" (NXDOMAIN) ve "bu adda o türde kayıt yok" yanıtlarını da önbelleğe alır. Süreyi zone'un SOA kaydı belirler: SOA kaydının kendi TTL'i ile son alanından (eski adıyla "minimum") küçük olanı geçerlidir.

$ dig +noall +authority nosuch.example.com
example.com.  300  IN  SOA  ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300

"Kaydı oluşturdum, yetkili sunucu döndürüyor ama benim çözümleyicim hâlâ yok diyor" durumunun olağan açıklaması budur: biri (çoğu zaman erkenden kontrol eden siz) adı oluşturulmadan önce sorgulamış ve olumsuz yanıt önbelleğe girmiştir. Negatif TTL 300 ise bu beş dakikalık bir can sıkıntısıdır; 86400 ise kaybedilmiş bir gündür. Makul tutun: 300 ile 3600 arası değerler uygundur.

TTL kaç olmalı?

Tek bir doğru sayı yoktur. Çeviklik ile dayanıklılık arasında bir dengedir:

Düşük TTL (60–300) Yüksek TTL (3600–86400)
Değişiklikler çabuk yansır yavaş yansır
Hatalar çabuk düzelir saatlerce kalır
Yetkili sunuculara sorgu yükü daha yüksek daha düşük
Kullanıcı için sorgu gecikmesi daha çok önbellek ıskası çoğunlukla önbellekten
DNS sağlayıcınız kesinti yaşarsa adlar dakikalar içinde çözülmez olur önbellekteki yanıtlar kullanıcıyı idare eder

Son satır sık unutulur. Uzun TTL, kısa bir DNS kesintisine karşı bedava sigortadır.

Makul başlangıç değerleri:

Kayıt Tipik TTL Gerekçe
Sabit bir web sitesinin A/AAAA kaydı 3600 değişiklik nadir ve planlıdır
Yedekleme (failover) ya da yük dengeleyici arkasındaki A/AAAA 60–300 hızlı taşınmalıdır; çoğu zaman sağlayıcı belirler
SaaS ya da CDN'e giden CNAME 3600 son adresi hedefin kendi TTL'i belirler
MX 3600–86400 posta sunucuları nadiren değişir; gönderenler zaten yeniden dener
TXT (SPF, DKIM, DMARC) 3600 planlı düzenlemeden önce düşürün
NS ve SOA 86400 sabittir; üst zone'daki delegasyon TTL'i zaten sizin elinizde değildir
CAA 3600–86400 CA'lar yeniden kontrol ederken TTL'e uyar

Sağlayıcınız "Auto" seçeneği sunuyorsa bu genellikle 300 saniyedir ve çoğu site için uygundur.

TTL ile değişiklik planlamak

Bir web sitesini, posta sunucusunu ya da bir DNS adının arkasındaki herhangi bir şeyi taşırken izlenecek yol:

  1. Mevcut TTL'e yetkili sunucudan bakın. Buna T diyelim.
  2. 300'e düşürün (daha aşağı değil; bazı çözümleyiciler çok küçük değerleri dikkate almaz) ve en az T kadar bekleyin. Ancak T geçtikten sonra her önbelleğin 300 saniyelik sürümü tuttuğundan emin olabilirsiniz.
  3. Değişikliği yapın.
  4. Doğrulayın: yetkili sunucuya ve birkaç herkese açık çözümleyiciye sorun.
  5. Eski hedefi en az yeni TTL kadar, kurallara uymayan önbellekler yüzünden gerçekçi olarak birkaç saat çalışır durumda tutun.
  6. Geri dönmeyeceğinizden emin olunca TTL'i yeniden yükseltin.

TTL'i düşürmekle kaydı değiştirmeyi aynı düzenlemede yapmak klasik hatadır: asıl önemli çözümleyiciler eski kaydı eski TTL ile tutuyordur ve o süre dolana kadar yeni TTL'inizi görmezler bile.

Nameserver değişikliklerinde ikinci bir TTL devreye girer: üst zone'daki delegasyonun TTL'i. Bu genellikle iki gündür ve sizin değiştirebileceğiniz bir şey değildir. O durumu kesintisiz nameserver değişikliği yazısında anlattık.

TTL ve CNAME zincirleri

Ad bir CNAME ise çözümleyici zincirin her halkasını kendi TTL'iyle ayrı ayrı önbelleğe alır:

www.example.com.        3600  IN  CNAME  site.cdn.example.
site.cdn.example.         60  IN  A      203.0.113.20

CDN kendi A kaydını bir dakika içinde taşıyabilir; ama siz www adını başka bir CDN'e yöneltmek isterseniz kendi 3600'ünüz geçerlidir. Bir değişikliğin gecikmesini, zincirdeki en küçük TTL değil, değiştirdiğiniz kaydın TTL'i belirler.

DNS önbelleği temizlenebilir mi?

Kendi önbelleğiniz: evet.

# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# systemd-resolved kullanan Linux
$ resolvectl flush-caches

Bazı herkese açık çözümleyiciler, bir adı önbelleklerinden sildirmek için web formu sunar; bir hatadan sonra işe yarar. Geri kalan herkesin çözümleyicisine dokunamazsınız. Küresel bir temizleme yoktur; "yayılmayı hızlandırdığını" söyleyen hizmetler hiçbir şey yapmayan bir düğme satıyordur.

Sık yapılan hatalar

  • TTL'i değişiklikle aynı anda ya da beş dakika önce düşürmek.
  • "Esnek olalım" diye her şeyi süresiz 60 saniyede bırakıp DNS sağlayıcısının kesintisinde onunla birlikte çökmek.
  • Yedekleme planının parçası olan bir kayıtta bir günlük TTL.
  • Negatif önbellek değerini unutup adı oluşturmadan önce sorgulamak.
  • Kendi bilgisayarınızdan yaptığınız tek bir sorguyu kullanıcıların gördüğünün kanıtı saymak.
  • Bir "yayılma kontrol" aracındaki yüzdenin tüm interneti anlattığını sanmak. O yüzde yalnızca aracın sorguladığı noktaları anlatır.

OrbitProbe ile kontrol edin

OrbitProbe DNS sorgulama aracı, döndürdüğü her kaydın yanında TTL değerini, herkese açık çözümleyicilerin o anda gördüğü haliyle gösterir. Taşımadan önce hangi TTL'leri düşürmeniz gerektiğini bulmak, değişiklikten sonra da yeni değeri doğrulamak için kullanın. Hangi kayıtların var olduğuna genel bir bakış için DNS kayıt türleri yazısına, değişiklik e-posta teslimatını düzeltmenin parçasıysa mailler spam'e düşüyor: DNS kontrol listesi yazısına bakın.