DKIM doğrulama, genel doğrulama materyalinin DNS aracılığıyla alınmasına bağlıdır. Bir imza, kriptografik olarak iyi biçimlendirilmiş olabilir ancak ilgili arama mevcut olmadığında doğrulanamaz durumda kalabilir. Anahtarları değiştirmeden veya mesaj içeriğini değiştirmeden önce DNS yolunu ve alıcının deneme zamanını araştırın.
Bir olaydan sonra yapılan başarılı bir arama, yararlı bir kurtarma kanıtıdır ancak başarısız girişim sırasında ne olduğunu belirlemez. Orijinal kimlik doğrulama sonucunu, mesajı, zaman damgasını ve mevcut çözümleyici günlüklerini koruyun. Amaç, sahip olmadığınız bir alıcının altyapısının görünürlüğünü iddia etmeden gözlemlenen arızayı açıklamaktır.
Kesin aramayı ve sonucu belirleyin
Etkilenenlerden d ve s'yi okuyun DKIM-Signature ve inşa et seçici d'nin _domainkey altında arama yapın. Altında RFC 6376 §3.6.2.1 Ve RFC 1034 §3.6.2Desteklenen kurulum bir CNAME, zinciri ve son doğrulama yanıtını yakalayın. Varsa yanıt kodunu, zamanı, çözümleyiciyi ve yetkili sunucuyu ekleyin.
RFC 6376 §6.1.2 Yanıt vermeyen bir sorguyu, var olmayan bir anahtar kaydından ayırır. İlki TEMPFAIL'e ve daha sonraki bir girişime neden olabilir; ikincisi, bu imza için anahtarsız bir PERMFAIL gerektirir. RFC 8601 §2.7.1 temperror aynı şekilde olası bir geçici doğrulama hatasını da açıklar. DNS ile ilgili tüm arızaları tek bir eksik kayıt teşhisine dönüştürmeyin.
Görünümleri abartmadan karşılaştırın
Yetkili bölgeyi ve temsili özyinelemeli çözümleyicileri kontrol edin. Bir fark, eski önbelleğe alınmış verilere, yetkilendirme tutarsızlıklarına veya DNS yolunun bir kısmına ulaşmada bir soruna işaret edebilir. Sağlayıcı tarafından yönetilen bir hedef söz konusuysa müşteri tarafından kontrol edilen takma adın yanı sıra bu hedefi de araştırın.
Yalnızca hata etiketinden birini seçmek yerine potansiyel nedenlere ilişkin kanıtları kaydedin. Örneğin bir çözümleyicinin SERVFAIL daha fazla tanı gerektirir; anahtarın silindiğinin kanıtı değildir. DNSSEC doğrulama (bkz. RFC 4035 §5.5), yetki verme ve taşıma sorunları, DNS operatörünün günlüklerini ve uzmanlığını gerektirebilir. Yalnızca bir aramanın başarılı olması için doğrulamayı varsayılan çözüm olarak devre dışı bırakmayın.
Zamana dayalı bir örneği takip edin
Örnek sıra: bir alıcı, saat 10:00'da active1._domainkey.sender.example örneğini almaya çalışır ve geçici bir anahtar alma hatası bildirir. Saat 10:05'te yönetici farklı bir çözümleyiciden geçerli bir anahtar alır. Her iki gözlem de doğru olabilir. İkincisi, bu sorgu için 10:05'teki kullanılabilirliği belirler, ilk alıcının beş dakika önce kullanılabilirliğini değil.
Bunun aksine, olay zamanındaki yetkili yanıt aktif seçicinin bulunmadığını tespit ederse, geçici bir kesintinin giderilmesini beklemek konfigürasyon sorununu çözemeyebilir. Kayıt geri yüklenirse, negatif önbelleğe alma RFC 2308 §5 diğer çözümleyicilerin bunu gözlemlemesini de etkileyebilir. Örnek, ölçülen bir kesinti veya vaat edilen bir kurtarma aralığı değil, bir teşhis zaman çizelgesidir.
Kurtarma işleminden sonra doğrulamanın geri kalanını kontrol edin
Takip etme RFC 6376 §6.1.2 Ve RFC 6376 §6.1.3, anahtar alma işlemi tamamlandıktan sonra döndürülen kaydın kullanılabilir olduğunu ve imzalayana karşılık geldiğini doğrulayın. Alınan bir anahtar yine de iptal edilebilir, hatalı biçimlendirilmiş veya uyumsuz olabilir. Eşleşen bir anahtar, imzalamadan sonra değiştirilen içeriği telafi edemez. Olay kaydında arama, anahtar doğrulama, gövde karma doğrulaması ve imza doğrulamayı ayrı aşamalar olarak tutun.
Birkaç imza mevcut olduğunda, başarısız bir aramanın her hizalanmış kimlik doğrulama yolunu mutlaka kaldırması gerekmez. Altında RFC 9989 §5.3.5, diğer imzaları inceleyin ve SPF bunu sonuçlandırmadan önce DMARC arızalı. Altında RFC 6376 §6.3 Ve RFC 9989 §5.4alıcı teslim politikası da ayrı bir karardır; geçici bir DKIM sorunu ertelemeyi veya kabul etmeyi garanti etmez.
Kontrollü testlerle kesintiyi kapatın
DNS operatörünün yetkili onarımından sonra, etkilenen aramayı ilgili görünümler aracılığıyla test edin ve yeni mesajları orijinal rota üzerinden gönderin. Beklenen ve gözlemlenen sonuçları kaydedin. Sebep idari kapsamınız dışında olduğunda DNS ve sağlayıcı olay kanıtlarını isteyin.
Bir sonraki uyarının doğru ekibe ulaşması için, yetkilendirilen seçici hedeflerin ve sahiplerinin envanterini tutun. Gerçekte başarısız olan bağımlılığı izleyin, ancak izleme kapsamını dürüstçe açıklayın: periyodik bir genel sorgu, her alıcının önbelleğini, ağını veya doğrulama davranışını yeniden oluşturmaz. Kapanışta nelerin iyileştiği, hangi kanıtların tanıyı desteklediği ve nelerin gözlemlenmediği belirtilmelidir.
Sınırlı bir sonucu koru
10:00 başarısızlığını ve 10:05 başarısını, her biri çözümleyici, sorgu adı, sonuç ve görünürlük sınırlarını içeren iki kayıt olarak tutun. Beş dakikalık aralık, bir iyileşme hedefi değil, örnek niteliğindedir. DNS TTL, genel bir iptal tarihi değil, bir güncellik aralığıdır: RFC 8767 §4 nitelikli eski kullanıma izin verir. Çözümleyici kesintisi, kurtarma veya posta testi ölçülmedi.