Kaydı değiştirdiniz, dig kendi sunucunuzdan yeni yanıt veriyor, ama müşteri hâlâ eski siteyi görüyor. Ya da tam tersi: TTL'i 300 yaptınız ve her değişiklikten sonra yarım saat uğraşıyorsunuz. Her iki durumun da tek bir kökü var: TTL sütununa yazdığınız sayı, gerçekte yaptığınız işle uyumlu değil. TTL değeri basit bir sayı değildir; sizinle internetteki her resolver arasında bir sözleşmedir.
TTL değeri tam olarak kime talimat veriyor
TTL'in birimi saniyedir ve aradaki resolver'lara bu yanıtı kaç saniye boyunca yeniden sormadan geçerli sayabileceklerini söyler. Dikkat edin, bu sayı kullanıcının tarayıcısına veya işletim sistemine talimat vermez; onların kendi önbellekleri vardır ve bazı tarayıcılar TTL'den bağımsız hareket eder. Yani "TTL'i düşürdüm ama hâlâ önbellekte" dediğinizde, muhtemelen bu sayıyı okumayan bir katmana bakıyorsunuz.
Daha az söylenen ikinci nokta: Etkin TTL her zaman sizin sayınız değildir. Resolver'ların daha düşük bir değer uygulama hakkı vardır ve bazı ISP'lerin kendi iç üst sınırları vardır. TTL'i 30 yaparsanız, her yerde 30 saniye kalacağı garanti değildir; yalnızca üst sınırı belirlemiş olursunuz, alt sınırı değil.
Her kayıt türü için mantıklı aralık
Evrensel bir sayı yoktur. Aşağıdaki tablo, pratikte işe yarayan aralığı gösterir:
| Kayıt türü | Önerilen TTL | Neden |
|---|---|---|
| Kararlı sunucu A / AAAA | 3600 ila 86400 | Az değişiklik, uzun önbellek resolver yükünü azaltır |
| Bulut servisi CNAME | 300 ila 1800 | Hedef sizin haberiniz olmadan değişebilir |
| MX | 3600 | E-posta sunucuları TTL'e duyarlıdır ve uzun önbellek e-posta kaybını önler |
| TXT (SPF, alan adı doğrulama) | 300 ila 3600 | Periyodik değişiklikler, ama anlık değil |
| Üst bölgedeki NS | 86400 | Nadir değişiklik; düşürmek gereksiz risktir |
| Taşınan kayıt | 60 ila 300 | Yalnızca geçici olarak, değişiklikten önce |
Sabit bir sunucunun A kaydı için 3600 saniye makul bir başlangıç noktasıdır. Site trafiği yüksekse ve çok sayıda resolver devredeyse, 86400 de mantıklıdır. Ama aynı kaydı 60 yaparsanız, her ziyaretçi neredeyse her dakika authoritative sunucunuza yeni bir sorgu gönderir. Zayıf bir DNS sunucusunda bu küçük sayı doğrudan CPU ve bant genişliğinde görülür.
TTL'i değişiklikten önce düşürün, sonra değil
Burada hata yapılıyor: Kaydı değiştiriyorlar, sonra TTL'i düşürüyorlar. Doğru sıra tam tersidir. Mevcut TTL 86400 ise ve yarın IP'yi değiştirmek istiyorsanız, bugün onu 300'e indirin ve eski TTL kadar geçmesini bekleyin. Yani yaklaşık bir gün. Sonra değişikliği uygulayın. Bunu yapmazsanız, eski yanıtı bir günlük TTL ile önbelleğe almış resolver'lar o sürenin sonuna kadar size eski yanıtı verir ve o önbelleği zorla geçersiz kılmanın hiçbir yolu yoktur.
Belirtisi de şudur: Kullanıcıların yarısı yeni siteyi görür, diğer yarısı görmez. Bazıları mobilden doğru görür, ev Wi-Fi'sinden görmez. Bu dağınıklık, sunucu sorunu değil, kalan uzun TTL'in işaretidir.
TTL'i düşürmenin maliyeti
Karşı konulması gereken cazibe, "her zaman değişikliğe hazır olalım" diye TTL'i sürekli düşük tutmaktır. Bedelini resolver'lar ve DNS sunucunuz öder. Orta trafikli bir alan adında 60 saniyelik TTL ile authoritative üzerindeki sorgu yükü birkaç katına çıkar ve o sunucu siteyi sunan makinedeyse, en kötü anda kendinize saldırmış olursunuz.
Yani benim tercihim net: Kararlı kayıtlar için uzun TTL koyun ve yalnızca taşıma penceresinde kısaltın. Sürekli düşük tutmayı haklı çıkaran tek durum, gerçekten otomatik ve sık sık yeniden yazılan bir kayıttır; dinamik IP'li bir servisin A kaydı veya bir betikle güncellenen alt alan adı gibi. Dinamik alt alan adı yapınız varsa, sayıyı seçmeden önce wildcard kaydının davranışını da göz önünde bulundurun; DNS'te wildcard kaydı ve dinamik alt alan adı yönetimi tam da bu senaryoyu ele alıyor.
Gerçek değeri nasıl görürsünüz, düşündüğünüzü değil
Authoritative yanıtı ve resolver yanıtını ayrı ayrı sorun. Bu iki sayı çoğu zaman aynı değildir:
dig +noall +answer example.com A
dig @1.1.1.1 +noall +answer example.com A
dig @ns1.example.com +noall +answer example.com AÇıktının son sütunu kalan TTL'dir. Authoritative sunucudan 3600 sayısını alıp resolver'dan 2400 aldıysanız, o resolver yanıtı 1200 saniye önce almış ve 2400 saniye daha tutacak demektir. Tam yolu ve hangi sunucunun yanıt verdiğini görmek için dig +trace example.com komutunu çalıştırın. Bu komutların çıktısı kafanızı karıştırıyorsa, DNS kayıtlarını kontrol etme daha hızlı bir başlangıç noktasıdır.
Pratik bir not: Her değişiklikten sonra dig çıktısındaki TTL değerini kontrol edin. Gördüğünüz sayı paneldekiyle uyuşmuyorsa, muhtemelen kaydı yanlış bölgede veya başka bir DNS servisinde düzenlemişsinizdir. Bu durum sandığınızdan daha sık olur, özellikle alan adı bir kayıt kuruluşundan alınıp bölge başka bir serviste barındırıldığında.
TTL ve e-postaya duyarlı kayıtlar
MX için küçük sayının gerçek riski vardır. TTL'i 60 yaparsanız ve e-posta sunucunuz birkaç dakika erişilemez olursa, göndericiler değişikliği daha hızlı fark eder ve e-postayı yanlış yola gönderebilir veya geçici olarak reddedebilir. MX için 3600 dengeli bir seçimdir. SPF ve DKIM ile ilgili TXT kayıtları için de 300 ila 3600 yeterlidir; yalnızca bazı e-posta servislerinin alan adı doğrularken eski önbelleğe alınmış değeri okuduğunu ve değişikliği görmesinin birkaç saat sürebileceğini unutmayın.
Alan adınız .ir ise, bir katman daha var: Bölge değişiklikleri İRİNİC yolundan geçebilir ve zamanlaması sizin TTL'inizden bağımsızdır. Bu yolun ayrıntıları İRİNİC kimliğiyle ir alan adı kaydı ve yönetimi tam rehberi içinde yer alıyor.
DNS sunucusu günlüğünde görülen hatalar
TTL'i çok kısa yaptığınızda, ilk belirti genellikle günlükte değil; sunucu yükündedir. Ama bölgeyi elle düzenliyorsanız, bu hataları ciddiye alın:
- Bölge düzenlemesinden sonra
SERVFAIL: Neredeyse her zaman sözdizimi hatasıdır, TTL değil. Seri numarasını (SOA serial) unutmuşsunuz veya ana makine adının sonundaki noktayı atlamışsınız. - Var olan bir alt alan adı için
NXDOMAIN: Kayıt, authoritative sunucunun yanıt vermediği bir bölgeye kaydedilmiş. - Belirli bir resolver'dan yüksek TTL'li eski yanıt: O resolver'ın önbelleği henüz sona ermemiş. Bekleyin veya başka bir resolver'dan test edin.
Bu belirtileri doğru sırayla incelemeyi Pratik DNS sorun giderme rehberi: Belirtiler ve kayıtları inceleme sırası yazısında ele aldık; çoğu durumda sorun TTL değil, yanlış kaydedilmiş bir kayıttır.
Önerdiğim nihai sayılar
Sabit sunucuda sitesi olan normal bir alan adı için: A ve AAAA 3600, MX 3600, CNAME 1800, TXT 3600, NS 86400. Her taşımadan önce ilgili kaydı 300'e indirin, eski TTL kadar bekleyin, değişikliği uygulayın ve oturduktan sonra sayıyı geri döndürün. Çok ziyaretçili bir siteniz varsa ve DNS sunucunuz sitenin bulunduğu makinedeyse, uzun TTL yalnızca optimizasyon değil, kendinizi korumadır.
Alan adını yeni kaydediyorsanız veya bölgeyi sıfırdan kuruyorsanız, bu sayıları baştan doğru koyun; sonradan düzeltmek her zaman ilk ayarlamadan daha pahalıdır. Yeni alan adları için alan adı arama ve kaydı ile başlayıp bölgeyi bu varsayılanlarla kurabilirsiniz.
Sık sorulan sorular
Minimum TTL değeri ne kadar olabilir?
Teknik olarak sıfır bile geçerlidir, ama pratikte hiçbir resolver her sorguyu yeniden sormaz ve çoğunun birkaç saniyelik iç alt sınırı vardır. 60 saniyenin altındaki değerlerin neredeyse hiçbir pratik faydası yoktur ve yalnızca DNS sunucusu yükünü artırır.
TTL'i değiştirdikten sonra neden hâlâ eski siteyi görüyorum?
Çünkü eski TTL hâlâ resolver önbelleklerinde duruyor. TTL'i düşürmek yalnızca sonraki yanıtları etkiler ve önbelleğe alınmış yanıtlar kendi ömürlerinin sonuna kadar geçerli kalır. Eski TTL kadar beklemeniz gerekir.
TTL'in Google'daki site sıralamasına etkisi var mı?
Doğrudan hayır. Ama çok kısa TTL, DNS yanıt süresini biraz yükseltebilir ve ağır yük koşullarında hissedilir yavaşlık yaratabilir. Etkisi dolaylıdır ve birkaç milisaniye düzeyindedir, bağımsız bir sıralama faktörü değildir.
Sunucu taşıması için TTL'i kaç saat önce düşürmeliyim?
Mevcut TTL kadar, sabit bir sayı değil. TTL 86400 ise, en az 24 saat önce düşürün. 3600 ise, bir saat yeterlidir. Basit kural: Bekleme süresi yeni TTL değil, eski TTL'e eşittir.