Kimlik doğrulamayı değiştirmeden önce DNS sonucunu sınıflandırın
“DKIM kayıt eksik” birkaç farklı durumu tanımlayabilir: seçici isim mevcut değil, ismin kullanılabilir bir özelliği yok TXT kaydı, takma ad hedefi eksik veya çözümleyici yanıt alamadı. Bu koşullar farklı araştırmalara ihtiyaç duyar. Her başarısız aramaya devamsızlık muamelesi yapmak, biletin yanlış operatöre gönderilmesine neden olabilir ve gereksiz aramaları teşvik edebilir. SPF veya DMARC değişiklikler.
Tam kimliğin kontrol edilmesiyle başlayın. bir için DKIM imzası, sorguyu gerçek seçicisinden ve imzalama etki alanından oluşturun. Geçen ayın seçicisine ilişkin bir arama, bu ayın seçicisiyle imzalanan bir mesaj hakkında çok az şey söylüyor. Yalnızca boş bir çıktı kutusu değil, tam yanıtı kaydedin. RFC 6376 , bölüm 3.6.2 ve 6.1.2.
Aşağıdaki karar dizisi önerilen bir teşhis yöntemidir. Örneklerinde kurgusal isimler ve sonuçlar kullanılıyor; henüz orijinal canlı sorgu transkriptleri tarafından desteklenmemektedir.
Birinci dal: Kullanılabilir bir DNS yanıtı geldi mi?
Zaman aşımı, istemcinin bekleme süresi içinde yanıt alamadığı anlamına gelir. Bu bir DNS yanıt kodu değildir ve NXDOMAIN kanıtlamaz. Hedef adresi, ulaşımı, zamanlamayı ve diğer onaylı uç noktaların yanıt verip vermediğini kaydedin. Reddetme, yokluktan da farklıdır: REFUSED, sunucunun işlemi reddettiğini belirtir. RFC 1035 , bölüm 4.1.1.
Kanıtların işaret ettiği yerde kesmeyi ve taşımayı kontrol edin. TC bayrağı ayarlanmış bir UDP yanıtı, TCP'nin yeniden denenmesini gerektirebilir ve DNS uygulamalarının TCP'yi desteklemesi gerekir. Yayınlanan bir anahtar, bu alışverişi bozan bir yol üzerinden erişilemez durumda kalabilir. Aşağıdaki gibi önerilen bir karşılaştırma kullanın: dig @SERVER_IP amber._domainkey.example.com . TXT +tcp, önceki sorguyla aynı sahibi ve uç noktayı koruyarak. Bu makaledeki hiçbir komut çalıştırılmadı. RFC 7766 , bölümler 5–6.
Yakalanan kanıtlarla aktarım sorununu ağa veya DNS operatörüne iletin. Kayıt içeriğini değiştirmek, ulaşılamayan bir hizmeti onarmaz. Açıklanamayan bir sorun giderme kısayolu olarak güvenlik kontrollerini devre dışı bırakmayın.
İkinci dal: NXDOMAIN beklenen adı tanımlıyor mu?
NXDOMAIN ad hatası yanıtıdır. Takma ad içermediğinden sorgulanan adla ilgilidir. ne zaman bir CNAME mevcutsa, hata orijinal sahipten ziyade nihai hedefle ilgili olabilir. Müşterinin seçicisinin hiçbir zaman yayınlanmadığını duyurmadan önce zinciri okuyun. RFC 2308 , bölüm 2.1.
Kurgusal bir durumda, amber._domainkey.example.com CNAME olarak mevcut amber.keys.example.net, ancak hedef mevcut değil. Müşteri tarafındaki yayın ve sağlayıcı tarafındaki hedefin farklı sorumlulukları vardır. Önerilen bir sonraki eylem, yayınlanan hedefin operatörüyle teyit edilmesi ve ilgili yetkililerin sorgulanmasıdır. Müşteri takma adının silinmesi, yalnızca özyinelemeli yanıtın NXDOMAIN gerçek eksik adı çözmeden yararlı yapılandırmayı atacağını söylediği için silinir.
Ayrıca önbellek durumunu da karşılaştırın. Daha eski bir özyinelemeli NXDOMAIN ile birlikte yetkili bir olumlu yanıt, önbelleğe alınmış yokluğu gösterebilir. Olumsuz yanıtın SOA bağlamını ve zaman damgasını koruyun ve her şeyi önbelleğe almaya bağlamadan önce yetkililer arasındaki anlaşmazlığı araştırın.
Üçüncü dal: NOERROR gerçekten NODATA anlamına mı geliyor?
NOERROR hiçbir DNS hatası bildirmez ancak istenen TXT verilerinin mevcut olduğunu garanti etmez. NODATA yanıt içeriklerine göre belirlenir: ilgili yanıt yok ve onu bir yönlendirmeden ayıran yetki bağlamı var. Yetki bölümündeki bir SOA veya yönlendirme NS kayıtlarının bulunmaması bu ayrımın yapılmasına yardımcı olur; takma adlar daha fazla sorgulama gerektirebilir. RFC 2308 , bölüm 2.2.
Kurgusal bir amber._domainkey.example.com olabilir Bir kayıt ancak TXT anahtarı yok. Bu tamamen eksik bir isimden farklı bir onarım. Başka bir yanıt, istemciyi yetkilendirilmiş bir alt bölgeye yönlendiren NS kayıtlarını içerebilir; bu yönlendirmede durmak, eksik bir aramayı eksik veri olarak yanlış etiketlemeye neden olur. Karar boyunca tam olarak istenen türü görünür tutun.
İlgili TXT verileri mevcut olduğunda, protokol sözdizimini inceleyin ve sınırları ayrı ayrı kaydedin. DNS başarısı, geçerli bir DKIM anahtarının veya SPF politikasının olduğunu garanti etmez. SPF kaydı arama adımında, RFC 7208 eşleşmeyen politikayı zaman aşımı veya sunucu hatası gibi DNS hatalarından ayırır. Bu sonuçları tek bir kimlik doğrulama hatası etiketine sığdırmayın. RFC 7208 , bölümler 4.4–4.5.
Dördüncü dal: yokluğunu varsaymadan SERVFAIL araştırın
SERVFAIL sunucunun sorguyu başarıyla işleyemediğini gösterir. Olası nedenler arasında kullanılamayan yetki, yetkilendirme veya takma ad döngüleri ve DNSSEC doğrulama hataları. Anlamı “yeni bir TXT kaydı yayınlamak” değil. Genişletilmiş hata bilgilerini koruyun ancak yalnızca SERVFAIL benzersiz bir neden çıkarmayın. RFC 9520 , bölüm 2.
İlgili yetkili sunucuları ve etkilenen özyinelemeli çözümleyiciyi karşılaştırın. Olumlu bir doğrudan otorite yanıtı, doğrulama ve erişilebilirlik farklılıklarını çözümsüz bırakırken sorunu daraltabilir. RFC 9520 aynı zamanda hataların önbelleğe alınmasını da gerektirir; bu nedenle, anında tekrarlanan bir hata, çözümleyicinin her yukarı akış sorgusunu tekrarladığı anlamına gelmez. RFC 9520 , bölüm 3.2.
Delillerle şubeyi kapatın
Olay kaydı, mesaj seçiciyi veya diğer protokol kimliğini, sorgu sahibini/türü/sınıfını, UTC saatini, sunucu uç noktasını, bayrakları, yanıt kodunu, tüm bölümleri ve aktarımı tanımlamalıdır. Orijinal çıktıyı önerilen şube kararına ekleyin. Bir sonraki sorumlu operatörü ve mevcut açıklamayı çürütecek gözlemi belirtin.
Düzeltmeden sonra ilgili DNS karşılaştırmasını tekrarlayın ve etkilenen rota üzerinden kontrollü bir mesajı test edin. DNS kullanılabilirliğini, kimlik doğrulama doğrulamasını ve teslimatı ayrı gözlemler olarak raporlayın. Orijinal sorgu transkriptleri, bağımsız teknik inceleme ve yayın onayı bu belgesel adayı için açık kalacaktır; kurgusal karar örnekleri bunların yerini tutamaz.