Bir joker karakterin kasıtlı olarak genişlettiği şey
Bir rapor tüketicisinin almaya istekli olabileceği DMARC Her ilişki için tek bir yetki sahibi yayınlamak yerine herhangi bir alan adı için rapor hazırlayabilirsiniz. RFC 9990 bu amaçla joker karakterli bir DNS kaydına açıkça izin verir. Onun örneği bir TXT kaydı *. _report._dmarc.example.com ve en az v=DMARC1. Bu, alıcı etki alanı tarafından yapılan geniş bir katılımdır; rapor veren her müşterinin incelendiğini kanıtlayan bir mekanizma değildir.
Ayrım operasyonel açıdan önemlidir. Bir sağlayıcı, verileri müşteriye göstermeden önce hesap düzeyinde doğrulamayı ayrı olarak zorunlu tutarken meşru bir şekilde geniş alımı seçebilir. DNS kaydı bu hesap kontrollerini uygulamaz. Bir güvenlik incelemesi, joker karakterin tam olarak hangi sınırı değiştirdiğini ve hangi sınırların alıcı uygulamanın ve sahiplerinin sorumluluğunda kaldığını tanımlamalıdır. RFC 9990 , bölüm 4
Tam sorguları joker karakterin altında görünür tutun
Raporlayan kişi yetkilendirme aramasını yine de politikanın alındığı etki alanı olan _report'tan oluşturur. _dmarc etiketleri ve hedef ana bilgisayar. Joker karakter, bu sorgulara yanıt verebilecek bir DNS yayınlama stratejisidir; sorgulanan sahibi veya döndürülen değeri anlama ihtiyacını ortadan kaldırmaz. Belirli bir ilişkiyi doğrularken tam sahibi ve yanıtı koruyun.
Onaylayan yanıtın, zorunlu ilk v=DMARC1. Sürüm değeri, gerekli durumuyla birlikte DMARC1 olarak kalır. Yöneticinin joker karakter kullanma niyeti, belirli bir sorgunun konuşlandırılan DNS ağacında beklendiği gibi çözümlendiğinin kanıtı değildir. Tam ad kayıtları ve DNS yapısı gerçek çözünürlüğü etkileyebilir, bu nedenle önerilen testlerin, ekran görüntüsünün kapsamı kanıtladığını varsaymak yerine gerçek yanıtı saklaması gerekir. RFC 9990 , bölüm 4; RFC 9989 , bölüm 4.7
Sahiplik ve veri erişiminden ayrı alım izni
Joker karakter, alıcı alanın protokol düzenlemesi kapsamındaki raporları almaya istekli olduğunu belirtir. Kontrol panelinde oturum açan bir kişinin, raporda belirtilen etki alanını kontrol ettiğini belirlemez. Ayrıca yüklenen yapıyı gönderenin güvenilir olduğunu veya raporun onu alan hesaba ait olduğunu kanıtlamaz.
Uygulama düzeyinde kabul gereksinimlerini ayrı ayrı tanımlayın: etki alanı-kiracı bağlama, kimlik doğrulamalı erişim, kaynak izleme, kopyaların işlenmesi ve beklenmedik etki alanlarının incelenmesi. Bunlar, uygulanan bir EmailAuth platformuyla ilgili iddialar değil, önerilen kontrollerdir. Bir kuruluştan bahseden bir rapor, otomatik olarak bir sahiplik ilişkisi oluşturmamalı veya verileri, adı talep eden ilk hesaba göstermemelidir.
Faturalandırma, katılım ve veri yetkilendirmesini DNS çıkarımının dışında tutun. Trafik almaya yönelik geniş isteklilik, bir kuruluşun ücretli bir hizmete kaydolmasına veya gözlemlenen yapılandırmasını yayınlamasına rıza göstermez. Bir iş akışının bu eylemlere ihtiyacı varsa, joker karakter kaydının ötesinde açık kararlar ve kanıtlar gerektirir. İncelemede, tek bir DNS sonucunu kapsamlı onay olarak ele almak yerine, her sınır için sorumlu sahibin adı belirlenmelidir.
Kötüye kullanım ve kaynak baskısını hesaba katın
RFC 9990 rapor içeriğinin sıkıştırıcıya veya XML ayrıştırıcıya saldırabileceği ve rapor verilerinin sahte olabileceği konusunda uyarıyor. Bu nedenle geniş bir alım hizmeti, rapor alma izninin gelen her dosyayı güvenli veya doğru kılmadığını varsaymalıdır. Kapasite planlaması, ayrıştırıcı sınırları ve kaynak kontrolleri yetkilendirme tasarımının yanı sıra yer alır.
Sınırlandırılmış mesaj boyutları, sıkıştırılmış boyut sınırları, ayrıştırma süresi bütçeleri, kuyruk izolasyonu ve beklenmedik kaynak hacmi için uyarı önerin. Sayısal değerler, icat edilmiş bir evrensel sınırdan kopyalanmak yerine, gerçek ortam için seçilmeli ve test edilmelidir. Reddetme nedenlerini koruyun ve gürültülü bir kaynağın ilgisiz müşteri kanıtlarını karartmasına izin vermeyin. Bu kontrollerin hiçbirinin burada dağıtıldığı veya test edildiği iddia edilmemektedir. RFC 9990 , bölüm 8.1 ve 8.2
Para çekme ve önbelleğe alınmış yetkilendirme
Hacimden bunalan bir rapor tüketicisi, onaylayan DNS kaydını kaldırabilir, ancak RFC 9990 pozitif önbelleğe almanın, kaydın TTL'si kadar etkiyi geciktirebileceğini belirtir. DNS değişikliğinden sonra raporların derhal durdurulacağına söz vermeyin. Giriş sistemlerinin ayrıca yeni arama durumundan bağımsız olarak önceden oluşturulmuş veya sıraya alınmış raporları işlemesi gerekebilir.
Geri çekme planı, kayıt sahibini, onay yolunu, ilgili TTL kanıtını, geçiş sırasındaki alım davranışını ve iletişim sorumluluklarını tanımlamalıdır. Bir joker karakterin kaldırılması aynı anda birçok meşru ilişkiyi etkileyebilir. Etki alanı başına açık yetkilendirmeye yönelik önerilen bir geçiş, yalnızca bu ilişkilerin bir envanterine ve bir doğrulama planına ihtiyaç duymaz. bir kayıt Silme.
DNS geri çekilmesi ile uygulama erişiminin iptali arasındaki ayrımı koruyun. Alma izninin kaldırılması, depolanan raporların silinmesine, müşteri hesaplarının kapatılmasına veya mevcut kullanıcı oturumlarının iptal edilmesine yol açmaz. Bunlar, ayrı yetkilendirme ve saklama sonuçları olan ayrı kontrollerdir. RFC 9990 , bölüm 4
Kurgusal sınır incelemesi ve test tasarımı
reports.example.net adresinde * teklif eden kurgusal bir tüketiciyi düşünün. _report._dmarc.reports.example.net v=DMARC1; . blue.example.com adresindeki varsayımsal bir politika için tam sorgu blue.example.com._report._dmarc.reports.example.net olacaktır. Bu örnek için hiçbir sorgu, yayın veya DNS çözümü yürütülmedi.
Olumlu durum planı, tam sorguyu koruyacak ve döndürülen yetkilendirme değerinin ayrıştırmayı geçtiğini doğrulayacaktır. Negatif durum planı dikkatli bir şekilde seçilmelidir: Aynı geniş yetkiye sahip hedefe yönlendirilen başka bir kaynak etki alanının mutlaka yetkisiz olması gerekmez, çünkü joker karakter kasıtlı olarak genel olarak kaynak etki alanlarını kapsar. Bunun yerine, ayrı olarak kontrol edilen bir hedef ana bilgisayar, herhangi bir fiili donanımın yetkilendirilmesi ve izole edilmesi koşuluyla, izinsiz olarak harici hedef sınırını gösterebilir.
Çalışma sayfası joker karakter sahibini, beklenen kapsamı, tam test sahiplerini, yanıtları, sürüm ayrıştırmayı, hedef-ana bilgisayar sınırını ve kiracı erişim kontrollerini listelemelidir. Ayrıca geri alma planını ve rapor işlemeye ilişkin sınırları da kaydetmelidir. Beklenen sonuçlar, gerçek sınırlı testler gerçekleştirilene kadar tasarım hipotezleridir; sırf gerekçe makul olduğu için geçti olarak etiketlenmemelidirler.
Çözülmemiş orijinal kanıtlar ve serbest bırakma kapıları
Katalog, pozitif test ve yetkisiz hedef testi de dahil olmak üzere tam yetki sahibini ve yanıtını gerektirir. Bu orijinal gözlemler açık kalıyor. Bu metinde, işleyen bir joker karakter dağıtımı veya hesap erişimi değerlendirmesi değil, önerilen bir test tasarımı ve kurgusal adlar verilmektedir.
Doğrulanmış bir operasyonel kılavuz olarak yayınlanmadan önce nitelikli bir incelemecinin gerçek DNS yanıtlarını incelemesi ve negatif testin gerçekten amaçlanan yetkilendirme sınırını aştığını doğrulaması gerekir. Orijinal kanıtlar, insan incelemesi, kaynak uygulanabilirliği, üretim yolları, görsel erişilebilirlik ve sahibinin serbest bırakılması açık olmaya devam etmektedir. Bu çalışma için herhangi bir dış iletişim, rapor yükleme veya DNS değişikliği yapılmadı.