Altında RFC 9989 §9.2, geçici DMARC hata, değerlendirmenin daha sonraki bir denemede çözülebilecek bir sorunla karşılaştığı anlamına gelir. Bu, alan adının hiçbir politikasının olmadığı veya meşru postanın kimlik doğrulamasının kesin olarak başarısız olduğu anlamına gelmez.
Sonucu bir çözüm araştırmasının başlangıcı olarak değerlendirin. Hangi gerekli aramanın başarısız olduğunu, verinin kendi yetkisinde olup olmadığını ve alıcı sistemin kullanılabilir bir yanıt almasını neyin engellediğini belirleyin.
Başarısız değerlendirmeyi yakalayın
Güvenilir sonucun tamamını veya döndürülen SMTP yanıtını, zamanı, Etki alanından ve gönderme yolunu kaydedin. Hatanın hangi kimlik doğrulama yöntemine ait olduğunu not edin. Geçici SPF veya DKIM sorun otomatik olarak dmarc= ile aynı değildirtemperror.
Günlükler bunları ortaya çıkardığında tam arama adını ve kayıt türünü koruyun. Bir politika TXT sorgusu, bir SPF bağımlılığı ve bir DKIM seçici arama farklı adları ve yetkilileri içerebilir. Yalnızca etki alanı kökünü test etmek, başarısız olan bağımlılığı gözden kaçırabilir.
Değişiklik yapmadan önce küçük bir kanıt paketini saklayın. Tekrarlanan sorgular olaydan sonra başarılı olabilir, dolayısıyla daha sonraki sağlıklı bir yanıt, orijinal başarısızlık kaydının yerini alamaz.
Tepkiye dayalı bir karar yolunu izleyin
Bu bir teşhis karar tablosudur, DNS durumundan tek bir e-posta düzenine kadar evrensel bir eşleme değildir:
- Sorgu gözlemi: NOERROR ile ilgili tam yanıt; Neyi ortaya koyuyor: Bu sorgu o sırada kullanılabilir verileri döndürüyordu; Sonraki araştırma: Bunu alıcının daha önceki gözlemiyle karşılaştırın
- Sorgu gözlemi: Veri içermeyen yanıtı tamamlayın; Neyi ortaya koyuyor: İstenen kayıt kümesi söz konusu yanıt bağlamında bulunamadı; Sonraki araştırma: Tam adı, yetkiyi, takma adları ve keşfi kontrol edin
- Sorgu gözlemi: Takma ad komplikasyonu olmayan NXDOMAIN ; Neyi ortaya koyuyor: Sorgulanan sahibin adı mevcut değil; Sonraki inceleme: Sorgu kapsamını ve uygulanabilir geri dönüşü onaylayın
- Sorgu gözlemi: SERVFAIL ; Neyi ortaya koyuyor: Çözüm başarıyla tamamlanmadı; Sonraki inceleme: Yetki, yetkilendirme, doğrulama ve çözümleyici günlüklerini inceleyin
- Sorgu gözlemi: REDDEDİLDİ; Neyi ortaya koyuyor: Bir sunucu sorguyu reddetti; Sonraki araştırma: Sorgu politikasını ve sunucunun amaçlanan rolünü kontrol edin
- Sorgu gözlemi: Zaman aşımı; Neyi ortaya koyuyor: Girişimin sınırları dahilinde hiçbir kullanılabilir yanıt alınamadı; Sonraki araştırma: Erişilebilirliği, aktarımı, kaybı ve sunucu durumunu kontrol edin
DNS yanıt kodları şu şekilde tanımlanır: RFC 1035 §4.1.1; tarafından verilen olumsuz yanıtlar RFC 2308 §2.1 Ve RFC 2308 §2.2. _dmarc.example.com sorgusu bu sahibin adıyla ilgilidir. Olumsuz yanıtı tek başına example.com var olmadığını kanıtlamaz. Orijinal sorgulanan isme bir yokluk atfetmeden önce takma ad zincirlerini takip edin.
Yetkili ve özyinelemeli yolları karşılaştırın
Öncelikle, yetki verilen alt alan adları da dahil olmak üzere doğru yetkili sunucuları tanımlayın. İlgili adı her makamda test edin ve yanıtları karşılaştırın. Yetkililer aynı görüşte değilse bölgenin hizmet durumunu ve son değişiklikleri araştırın.
Daha sonra kanıtın mevcut olduğu durumlarda, etkilenen alıcı sistem tarafından kullanılan özyinelemeli yolu inceleyin. Sorgu süresini, durumu, yanıtı ve TTL'yi karşılaştırın. Bir operatörün yerel çözümleyicisi ve uzak alıcısı, farklı önbellek veya doğrulama durumuna sahip olabilir.
Aşağıdaki kurgusal kısaltılmış transkript karşılaştırmayı göstermektedir:
14:02 UTC | özyinelemeli çözümleyici R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | yetkili sunucu A | aynı isim/tür | HATA YOK, politika 14:04 UTC'yi döndürdü | yetkili sunucu B | aynı isim/tür | HATA YOK, politika 14:09 UTC'yi döndürdü | onarımdan sonra çözümleyici R | aynı isim/tür | HATA YOKBu gözlemler, araştırmayı özyinelemeli veya araya giren yola doğru daraltır. Sebebi günlükler olmadan kanıtlayamazlar ve her alıcının yaşadığı deneyimi tespit edemezler.
DNSSEC doğrulamasını incelemeye dahil edin
Altında RFC 4035 §5.5, doğrulama çözümleyicisi başarısız olan verileri reddedebilir DNSSEC Yetkili bir sunucuya yapılan doğrudan bir sorgu metin döndürdüğünde bile doğrulama. Sorumlu DNS ekibinin desteklenen araçlarını ve günlüklerini kullanarak, anahtar veya imza değişiklikleri de dahil olmak üzere yetki verme ve doğrulama kanıtlarını kontrol edin.
Bir yetkilinin doğrudan yanıtı, alıcının doğrulama kararını tek başına yansıtmaz. Benzer şekilde, bir SERVFAIL DNSSEC sorununu kanıtlamaz; bunun birkaç nedeni olabilir.
Varsa, belirlenen doğrulama kusurunu onarın. Belirtiyi gizlemek için doğrulamanın devre dışı bırakılması, amaçlanan güvenli çözüm yolunun kurtarıldığının kanıtı değildir.
Gerektiğinde hem UDP'yi hem de TCP'yi test edin
DNS aktarımı başarısızlığın bir parçası olabilir. Küçük bir UDP sorgusunun başarılı olması, daha büyük bir yanıtın, kesilmiş yanıt yeniden denemesinin veya TCP'nin aynı yol üzerinde çalıştığını belirlemez.
RFC 7766 RFC 7766 §5 hem UDP'yi hem de TCP'yi desteklemek için genel amaçlı DNS uygulamaları gerektirir. Erişilebilirliği veya boyutla ilgili arızaları teşhis ederken her bir aktarım için ilgili adı ve türü karşılaştırın. Her zaman aşımının aynı nedene sahip olduğunu varsaymak yerine, kesme işaretini ve ağ kanıtlarını inceleyin.
Taşıma testi tanısal bir gözlemdir. Tasarım gözden geçirilmeden amaçlanan çözümleyiciyi veya doğrulama yolunu atlayan bir üretim geçici çözümüne dönüştürülmemelidir.
Devamsızlığı ve başarısız çözümü ayrı tutun
Altında RFC 2308 §5, olumlu veriler gibi olumsuz yanıtlar da önbelleğe alınabilir. Yeni eklenen bir kayıt, önceki negatif önbellek durumu sona erene kadar özyinelemeli görünümde mevcut olmayabilir. Bu, yetkili bir sunucunun erişilemez olmasından farklıdır.
Gözlemlenen hata geçici olarak sınıflandırılırken bir yapılandırma hatası da devam edebilir. “Geçici”, beklemenin bozuk bir delegasyonu veya imzayı onaracağına dair bir söz değil, değerlendirme kategorisini tanımlar.
Kullanmak kayıp kayıt kılavuzu teyit edilmiş devamsızlık için ve yayınlama iş akışı gerçek adı ve yetkiyi doğrulamak için.
Politikayı yeniden değerlendirmeden önce kurtarmayı doğrulayın
Akım RFC 9989 §4.10.1 Politika arama DNS hatalarının işlenmesini alıcıya bırakır. Değerlendirme kılavuzunda RFC 9989 §5.3.6 DNS hataları nedeniyle tamamlanmayan gerekli DNS sorgularının DMARC geçişi veya başarısızlığı oluşturmadığını ve alan sahibi değerlendirme politikasının bu eksik sonuca uygulanamayacağını söylüyor. Alıcı kullanımı hala farklılık gösterebilir.
p'yi değiştirmek, ulaşılamayan gerekli aramayı onarmaz. Önce kullanılabilir çözünürlüğü geri yükleyin, ardından aynı rotayı yeniden test edin ve yönteme özgü yeni sonuçları inceleyin. Herhangi bir iş kurtarma kararını ayrı bir kapsamlı değişiklik olarak koruyun.
Nihai kayıt, başarısız olan bağımlılığı, belirlenen nedeni, onarımı ve kurtarma sonrasında alıcı kanıtlarını tanımlamalıdır. Bu, refleks olarak çalışan bir politikayı zayıflatmadan bir sonraki aralıklı arızanın teşhis edilmesini kolaylaştırır.
Karar ve delilleri ayrı tutun
Kurgusal 14:02–14:09 transkripti için, otorite başarısı daraltır ancak başarısız olan bileşeni tanımlamaz. Neden olarak DNSSEC , aktarım veya belirli bir sunucuyu adlandırmadan önce gerçek çözümleyicinin veya ağ bulmanın gerekli olmasını sağlayın. RFC 8767 §4 nitelikli eski cevap kullanımına izin verir; Tazelik tek başına evrensel bir kesinti veya iyileşme saati değildir. Bu gözlemler, gerçekleştirilen testler değil, icat edilmiş öğretim materyalleridir.