DNS TTL (Time to Live) Ayarlarının Rolü

Her DNS yanıtı yanında bir sayı taşır: Time to Live, kısaca TTL. DNS panelleri varsayılan bir değer doldurduğu ve çoğu kişi ona hiç dokunmadığı için gözden kaçması kolaydır. Oysa bu tek değer; web sitenizde, e-postanızda ya da API’nizde yaptığınız bir değişikliğin kullanıcılara ne kadar hızlı ulaşacağını, ad sunucularınızın ne kadar yük taşıyacağını ve alan adınızın bir sağlayıcı kesintisini ne kadar zarif atlatacağını belirler. TTL’yi anlamak, beş dakikada biten bir taşıma ile bir gün boyunca sürünen bir taşıma arasındaki farktır.

Bu rehberde TTL’nin gerçekte ne yaptığını, makul değerleri nasıl seçeceğinizi, bir taşımayı TTL’ye göre nasıl planlayacağınızı ve gerçek dünyadaki önbelleklerin neden her zaman belirlediğiniz sayıya uymadığını anlatıyoruz.

DNS’te TTL ne anlama gelir?

TTL, her kaynak kaydında bulunan ve saniye cinsinden ölçülen bir alandır. ISS’inizin çözümleyicisi ya da 1.1.1.1 veya 8.8.8.8 gibi genel bir özyinelemeli çözümleyici, yetkili bir ad sunucusundan kayıt çektiğinde yanıtı saklar ve TTL’yi geriye doğru sayar. Sıfıra ulaşana kadar yetkili sunucuya tekrar sormadan önbelleğinden yanıt verir. Süre dolduğunda bir sonraki sorgu yeni bir arama başlatır.

Bu geri sayımı dig ile görebilirsiniz. Aynı sorguyu bir çözümleyiciye iki kez gönderin; yanıt bölümündeki TTL ikinci seferde daha düşük olacaktır:

dig @8.8.8.8 example.com A +noall +answer
example.com.    2873    IN    A    93.184.215.14

Bölge sahibinin belirlediği orijinal değeri görmek için doğrudan yetkili bir ad sunucusuna sorun:

dig NS example.com +short
dig @ns1.example-dns.net example.com A +noall +answer

Sık sözü edilen “DNS yayılması” kavramı aslında budur: binlerce bağımsız önbelleğin eski yanıtı kendi takvimine göre unutması. Hiçbir şey dışarıya itilmez; önbellekler sadece unutur.

Kısa ve uzun TTL’lerin artıları ve eksileri

Her kayıt için doğru olan tek bir TTL yoktur. Her seçim çeviklik ile verimlilik ve dayanıklılık arasında bir denge kurar.

Uzun bir TTL aynı zamanda bir güvenlik ağı işlevi görür. Yetkili DNS sağlayıcınız çökerse, kayıtlarınızı bir saat önce önbelleğe almış çözümleyiciler o saatin geri kalanında yanıt vermeye devam eder. 60 saniyelik bir TTL ile kullanıcılar kesintiyi neredeyse anında hisseder. Kısa TTL’ler bedava performans da değildir: her önbellek ıskalaması yetkili sunuculara ek bir gidiş-dönüş ekler.

Her kayıt türü için değer seçmek

A, AAAA ve CNAME

Kararlı bir sunucudaki web sitesi için bir saat makul bir başlangıç noktasıdır. Bir CDN ya da yönetilen yük dengeleyici kullanıyorsanız sağlayıcının önerilerine uyun; birçoğu trafiği yönlendirebilmek için kendi kayıtlarında kısa TTL kullanır, sizin onlara işaret eden CNAME kaydınız ise daha uzun kalabilir.

MX ve e-postayla ilgili TXT kayıtları

E-posta yönlendirmesi nadiren değişir ve gönderen sunucular teslimat başarısız olursa günlerce yeniden dener; bu yüzden birkaç saat ile bir gün arası uygundur. Yeni bir e-posta sağlayıcısına geçecekseniz önceden düşürün.

NS kayıtları

Yetkilendirme için gerçekten önemli olan NS kayıtları üst bölgede durur ve kayıt otoritesi tarafından yönetilir; TTL’leri çoğu zaman bir ya da iki gündür. Kayıt firmanızda ad sunucularını değiştirmenin bir A kaydını değiştirmekten daha uzun sürmesinin nedeni budur. Bir alan adının şu anda hangi ad sunucularına yetki verdiğini TLDix WHOIS sorgulama aracıyla kontrol edebilirsiniz.

SOA

SOA kaydı, ikincil sunucular için zamanlayıcıları ve aşağıda ele alınan negatif önbellek değerini taşır. Kendi TTL’si genellikle bir saat ya da daha fazladır.

Taşıma öncesinde TTL’yi düşürmek

En kullanışlı pratik TTL tekniği, planlı bir değişiklikten önce değeri küçültmektir. İnsanların gözden kaçırdığı kritik ayrıntı zamanlamadır: çözümleyiciler yeni ve daha düşük TTL’nizi ancak eski TTL’li önbellek kopyalarının süresi dolduktan sonra öğrenir.

1. Mevcut TTL’yi yetkili sunucuda kontrol edin. Diyelim ki 86400 saniye.
2. Taşımadan en az 24 saat, yani bir tam eski TTL süresi önce değeri 300 saniyeye düşürün. Biraz daha uzun beklemek daha güvenlidir.
3. Değişikliği yapın, örneğin A kaydını yeni sunucuya yönlendirin. Önbelleklerin çoğu artık beş dakika içinde yenilenir.
4. Bazı istemciler geride kalacağı için eski sunucuyu bir süre çalışır tutun.
5. Trafik ve günlükler taşımanın tamamlandığını doğruladığında TTL’yi normal değerine yükseltin.

; 24+ hours before
www.example.com.   300    IN  A  203.0.113.10
; migration moment
www.example.com.   300    IN  A  198.51.100.20
; after verification
www.example.com.   3600   IN  A  198.51.100.20

2. adımı atlayıp TTL hâlâ bir günken kaydı değiştirirseniz bazı kullanıcılar bir güne kadar eski sunucuya ulaşmaya devam eder.

Negatif önbellek ve SOA minimum değeri

Çözümleyiciler bir kaydın yokluğunu da önbelleğe alır. Bir ad mevcut değilse (NXDOMAIN) ya da mevcut olup istenen türde kaydı yoksa (NODATA), RFC 2308’e göre çözümleyici bu negatif yanıtı önbelleğe alabilir. Bunun ömrü, SOA kaydının kendi TTL’si ile SOA’nın tarihsel olarak “minimum” adı verilen son alanından küçük olanıdır.

dig example.com SOA +noall +answer
example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026100701 7200 3600 1209600 3600

Buradaki son 3600, başarısız bir aramanın bir saat boyunca hatırlanabileceği anlamına gelir. Bu durum, yeni bir alt alan adını oluşturmadan önce sorguladığınızda can yakar: bir izleme kontrolü, bir sertifika doğrulama denemesi ya da sabırsız bir test NXDOMAIN yanıtını önbelleğe alır ve yeni kayıt daha sonra “yayılmıyor” gibi görünür. Bunu önlemek için kayıtları herhangi bir şey onları sorgulamadan önce oluşturun ve SOA negatif TTL’sini makul düzeyde, genellikle 300 ile 3600 saniye arasında tutun.

Çözümleyiciler TTL’nizi ne zaman sınırlar ya da yok sayar?

Yayımladığınız TTL bir garanti değil, bir üst sınırdır. Birkaç katman onu değiştirebilir:

• Çözümleyici sınırları. BIND ve Unbound gibi yazılımların yapılandırılabilir maksimum önbellek süreleri vardır ve işletmeciler çok kısa TTL’lerin yükseltilmesi için minimum değerler belirleyebilir. BIND’ın varsayılan maksimum değeri bir haftadır; negatif önbelleği ise varsayılan olarak üç saatle sınırlıdır.
• Serve-stale. RFC 8767, yetkili sunuculara ulaşılamadığında çözümleyicilerin süresi dolmuş verilerle yanıt vermeye devam etmesine izin verir. Bu dayanıklılığı artırır ama eski yanıtların ömrünü uzatabilir.
• İşletim sistemleri ve tarayıcılar. Yerel stub çözümleyiciler ve tarayıcılar, ağ çözümleyicisinden bağımsız olarak kendi kısa önbelleklerini tutar.
• Uygulamalar. Uzun süre çalışan süreçler bir adı bir kez çözümleyip adresi yeniden kullanabilir; bazı çalışma ortamlarının da kendi DNS önbellek ayarları vardır.

Sonuç: uzun bir kuyruk bekleyin. Herhangi bir değişiklikten sonra trafiğin büyük bölümünün TTL süresi içinde taşınmasını, küçük bir kısmın ise daha uzun süre geride kalmasını hesaba katın.

Pratik örnek: E-posta sağlayıcısı değişikliği

TTL planlamasının en çok işe yaradığı durumlardan biri e-posta taşımasıdır. Diyelim ki şirketiniz kendi barındırdığı posta sunucusundan bulut tabanlı bir e-posta hizmetine geçiyor. MX kayıtlarınızın TTL’si 86400 saniye, SPF kaydınızı içeren TXT kaydının TTL’si de aynı. Geçişten iki gün önce her iki kaydın TTL’sini 300 saniyeye düşürün. Bu arada yeni sağlayıcının istediği doğrulama TXT kaydını ekleyin ve DKIM anahtarlarını yayımlayın; bunlar mevcut postayı etkilemez.

Geçiş günü MX kayıtlarını yeni sağlayıcıya yönlendirin ve SPF kaydını yeni gönderen sunucuları içerecek biçimde güncelleyin. Eski posta sunucusunu en az birkaç gün açık tutun; geride kalan çözümleyiciler ve uzun süre önbellek tutan gönderen sunucular iletileri hâlâ oraya teslim edebilir. Gelen kutularını her iki tarafta da kontrol edin ve eski sunucuya gelen posta tamamen durduğunda onu kapatın. Son olarak MX ve TXT kayıtlarının TTL’sini yeniden birkaç saat ya da bir gün düzeyine çıkarın. Bu sıralama, iletilerin kaybolmasını ve SPF hatalarından kaynaklanan reddetmeleri büyük ölçüde önler.

Değişiklik sonrası doğrulama nasıl yapılır?

Bir değişiklik yaptıktan sonra yalnızca kendi bilgisayarınızdan bakmak yanıltıcı olabilir, çünkü yerel önbelleğiniz eski yanıtı tutuyor olabilir. Bunun yerine önce yetkili sunucuyu doğrudan sorgulayın ve yeni değerin orada olduğundan emin olun. Ardından birkaç farklı genel çözümleyiciyi, örneğin 1.1.1.1, 8.8.8.8 ve 9.9.9.9 adreslerini ayrı ayrı sorgulayın. Yanıtlardaki TTL değerleri size her önbelleğin eski kaydı ne kadar daha tutacağını gösterir. Farklı ülkelerden kontrol yapan çevrim içi araçlar da genel tabloyu görmenize yardımcı olur. Bu kontrolleri tarih ve saatiyle not etmek, bir sorun çıktığında neyin ne zaman değiştiğini kolayca açıklamanızı sağlar.

İzleme ve iyi alışkanlıklar

• Geçici düşürmelerin unutulmaması için her kaydın normal TTL değerini belgeleyin.
• Değişikliklerden sonra yetkili yanıtları birkaç genel çözümleyiciyle karşılaştırın.
• Sağlayıcınız özellikle gerektirmedikçe 30 saniyenin altındaki TTL’lerden kaçının.
• DNS değişikliklerini alan adı, sertifika ve hosting bitiş tarihlerinin takibiyle birlikte yürütün; süresi dolmuş bir alan adı, TTL ne olursa olsun DNS’i bozar.

Her kayıt türünün ne işe yaradığını hatırlamak için DNS kayıtlarının temelleri rehberimizi okuyabilirsiniz.