Yayılma son tarihini bir değişiklik planıyla değiştirin
DNS TTL, önbelleğe alınan bilgilerin ne zaman yeniden değerlendirileceğini belirlemeye yardımcı olur. Her alıcının yenisini kullanmaya başlayacağı dünya çapında tek bir an planlamaz SPF politika veya DKIM anahtar. Farklı çözümleyiciler eski yanıtı farklı zamanlarda aldı, yetkili sunucuların tümü yeni verileri sunmuyor olabilir ve uygulamaların kendi arama ve yeniden deneme davranışları olabilir.
Yararlı bir değişiklik planı, yetkili yayınları alt gözlemlerden ayırır. " DNS ana bilgisayarı düzenlemeyi kabul etti", "ilgili yetkili sunucuların amaçlanan yanıtı döndürmesinden" daha erken bir kilometre taşıdır. Her iki ifade de belirli bir posta alıcısının bir dakika önce gönderilen bir mesaj için ne kullandığını belirlemez. Zaman çizelgesini, DNS sabit sayıda saat süreceği yönünde genel bir söz vermek yerine, her bir dönüm noktasına ilişkin kanıtlarla başlatın.
Hangi TTL'nin gözlemlendiğini anlayın
Yetkili bir kaynak kaydının, yayınlanan verileriyle ilişkili bir TTL'si vardır. Önbelleğe alınmış bir yanıt normalde önbelleğe alınmış verilerin kalan ömrünü bildirir, böylece iki özyinelemeli çözümleyici aynı metni farklı kalan TTL'lerle döndürebilir. Bu değerler farklı önbellek durumlarını tanımlar; bunlar, kaydın amaçlanan konfigürasyonunun birbiriyle yarışan iki bildirimi değildir. RFC 1035 , bölüm 4.1.3; RFC 1034 , bölüm 6.2.1.
Mevcut bir kaydın uzun bir TTL'si varsa, bu değerin azaltılması, eski cevabın zaten depolandığı önbelleklere geriye doğru ulaşmaz. Önemli değişiklikten önce azaltmayı planlayın ve önceki önbellekleme aralığının dikkate alınmasına izin verin. Bakım planının bir parçası olarak işleme koymadan önce, daha düşük TTL'nin gerçekten sunulduğunu doğrulayın. Bu, her önbelleğin gözlemlendiğinin kanıtı değil, planlama kılavuzudur.
Takma ad zinciri farklı bağımlılıklar ekler. Takma ad kaydı ve hedefin kayıt kümesi farklı TTL'lere ve farklı operatörlere sahip olabilir. Müşteri tarafında kısa bir TTL CNAME zaten önbelleğe alınmış bir hedef anahtarı aynı anda yenilenmeye zorlamaz. Zamanlamayı açıklamaya çalışmadan önce her iki ismi de yazın.
Eski ve yeni cevapları ayrı ayrı modelleyin
Şu adreste kurgusal bir SPF güncellemesi düşünün: mail.example.com. Çözümleyici A, eski politikayı 09:50'de 3.600 saniyelik TTL ile alır. Saat 10:00'da yetkili operatör yayınlanan TTL'yi 300 olarak değiştirir. Saat 10:10'da operatör poliçeyi değiştirir. Çözümleyici A'nın önceki girişi, başka bir davranış olmadığında, orijinal önbellek ömrü boyunca 10:50'ye kadar hala kullanılabilir. İlk olarak saat 10:10'dan sonra bakan ikinci bir çözümleyici, yedek parçayı zaten iade edebilir.
Bu çalışılan örnek, bir ölçüm veya garantili bir son kullanma planı değil, aritmetik tarafından icat edilmiştir. Buradan çıkan ders, TTL'yi saat 10:00'da düşürmenin Çözümleyici A'nın 09:50 girişini yeniden yazmamasıdır. Operasyonel bir çalışma sayfası, önceki verileri, önceki TTL'yi, TTL değişikliğinin yetkili makamda gözlemlendiği zamanı, içeriğin değiştiği zamanı ve sonraki örnek çözümleyici yanıtlarını saklamalıdır.
DKIM rotasyonu için, yeni belgenin yayınlanmasına ilişkin ayrı aşamaları koruyun seçici, kullanılabilirliğinin doğrulanması, onu kullanan imzaların başlatılması ve eski seçicinin kullanımdan kaldırılması. DNS önbellek aritmetiği, daha önce gönderilen postanın doğrulanmasının ne zaman tamamlanacağına tek başına karar veremez. Gönderenin sıraya alma, yeniden deneme ve saklama gereksinimleri de rotasyon kararına dahildir. RFC 6376 , bölüm 3.1 ve 3.6.
Olumsuz yanıtları ve kesinti davranışlarını dahil edin
Yeni oluşturulan bir ismin zamana karşı hiçbir olumlu kaydı olmayabilir. Çözümleyici bunun yerine daha önceki bir NXDOMAIN veya NODATA sonucunu tutabilir. Negatif yanıtın SOA tabanlı ömrü, yeni yayınlanan TTL'den farklı bir değerdir TXT kaydı. Bu nedenle yeni TXT TTL'yi değiştirmek, daha önce önbelleğe alınmış bir yokluğu silmez. RFC 2308 , bölüm 3 ve 5.
Basit bir son kullanma öyküsünün de açık bir standart istisnası vardır. RFC 8767 süresi dolmuş bir girişin yetkili olarak yenilenemediği durumlarda eski verilerin sunulmasına izin verir. Bunun gerçekleşip gerçekleşmeyeceği çözümleyiciye ve arıza koşullarına bağlıdır. Döndürülen bir yanıtın yalnızca sıfırdan farklı küçük bir TTL'ye sahip olması nedeniyle yeni olduğunu varsaymayın. RFC 8767 , bölümler 4–5.
Bu vakalar soruşturmayı değiştirmeli, keyfi bir ekstra bekleme süresine davetiye çıkarmamalıdır. Yetkililer aynı fikirde değilse yayın tutarlılığını düzeltin. Olumsuz yanıt devam ederse orijinal soruyu ve SOA içeriğini inceleyin. Yetkiye ulaşılamıyorsa, zaten doğru olan bir TXT kaydını tekrar tekrar düzenlemek yerine, kullanılabilirliği geri yükleyin veya araştırın.
Sürüm sorusunu yanıtlayan gözlemleri seçin
Değişiklikten önce, ilgili yetkililerden ve seçilen özyinelemeli yollardan tam kaydı ve TTL'sini alın. Daha sonra aynı sahibi, türü ve sınıfı aynı uç noktalarda tekrarlayın. Mümkün olduğunda, etkilenen ortamla ilgili bir yol ekleyin; her posta alıcısının sayımı değil, birkaç kamu çözümleyici örnek olarak kalıyor.
Önerilen bir sorgu @RESOLVER_IP mail.example.com kazın. TXT, eşleştirilmiş @AUTH_IP mail.example.com kazın. TXT +norecurse. Yanıtların tamamını UTC zaman damgalarıyla kaydedin ve kullanmadan önce tüm yer tutucuları etiketleyin. Yerel önbellek temizleme işlemi yalnızca söz konusu yerel önbelleğe alma yolunu değiştirir. Uzak bir alıcının özyinelemeli önbelleğini temizleyemez, dolayısıyla genel bir tamamlama kontrolü değildir.
Sonucu tam olarak bildirin: hangi yetkililer aynı fikirde, hangi örnek çözümleyiciler yeni değeri döndürüyor ve hangi gözlemler eksik kalıyor. Daha sonra amaçlanan hizmet aracılığıyla kontrollü bir mesaj gönderin ve gerçek kimlik doğrulama kimliklerini ve alıcı sonucunu inceleyin. Bu taslak için hiçbir DNS sorgusu veya mesaj testi gerçekleştirilmedi. TTL, yanıt türü, yetki ve gözlem süresi de dahil olmak üzere gerekli çözümleyici karşılaştırması açık kalır.