Hem libspf2(C) hem de Mail::SPF::Query(perl, sendmail-spf-milter'da kullanılır ), 10 DNS'e neden olan mekanizmaların bir limitini uygular , ancak ikincisi (AFAICT), MX veya PTR limitlerini uygulamaz. mx ve ptr'ninlibspf2 her birini de 10 ile sınırlar .
Mail::SPF(perl), MX ve PTR başına 10 DNS'e neden olan mekanizmaların bir sınırına ve mekanizma başına 10 aranma sınırına sahiptir. (İki perl paketi genellikle, varsayılan olarak olmasa da, MIMEDefang'da kullanılır .)
pyspfhepsinde 10 limit vardır: "aramalar", MX, PTR, CNAME; ancak çalışma sırasında MAX_LOOKUPS değerini 4 ile çarpıyor. "Katı" modda değilse, MAX_MX ve MAX_PTR değerlerini 4'e katlar.
Ticari / tescilli uygulamalar hakkında yorum yapamam, ancak yukarıdaki (hariç pyspf), çoğu durumda çalıştırmada geçersiz kılınabilmesine rağmen, 10 DNS tetikleme mekanizmasının üst sınırını (aşağıda daha fazlası) açıkça belirtin, alın veya alın. saati.
Özel durumda, haklısın, 12 ve 10 sınırını aşıyor. SPF yazılımlarının çoğunun "PermError" döndürmesini bekliyorum, ancak başarısızlıklar sayıları yalnızca "dahil edilen" sağlayıcıları etkileyecektir. toplam çalışan olarak hesaplanacak: SPF mekanizmaları soldan sağa değerlendirilir ve kontroller bir geçişte "erken çıkar" olur, bu nedenle gönderen sunucunun hangi sırada göründüğü belirlenir.
Bunun etrafındaki yol, DNS aramalarını tetiklemeyen mekanizmalar kullanmaktır, örneğin ip4ve ip6, ve mxeğer mümkünse, her biri birden fazla IP'ye sahip olabilen 10 adede kadar daha fazla ad alabilmeniz için kullanmaktır.
SPF potansiyel olarak üstel ölçeklendirmeyle keyfi DNS isteklerine yol açtığından, DOS / amplifikasyon saldırıları için kolayca kullanılabilir. Bunu önlemek için kasıtlı olarak düşük sınırları var: istediğiniz şekilde ölçeklendirmiyor.
DNS aramalarına neden olan 10 mekanizma (kesinlikle mekanizmalar + "yönlendirme" değiştiricisi) tam olarak 10 DNS aramasıyla aynı şey değildir. "DNS aramaları" bile açıklamaya açıktır, önceden kaç tane ayrı arama yapılması gerektiğini bilmiyorsunuz ve özyinelemeli çözümleyicinizin kaç tane ayrık arama yapması gerekebileceğini bilmiyorsunuz (aşağıya bakın).
RFC 4408 §10.1 :
SPF uygulamaları, "dahil etme" mekanizmasının veya "yönlendirme" değiştiricisinin kullanımından kaynaklanan aramalar da dahil olmak üzere, DNS araması yapan SPF kontrolü başına en fazla 10 olan mekanizmaları ve değiştiricileri sınırlandırmalıdır. Bu numara bir kontrol sırasında aşılırsa, bir PermError GEREKİR. "İçerir", "a", "mx", "ptr" ve "var" mekanizmaların yanı sıra "yönlendirme" değiştiricisi bu sınırlamaya göre sayılır. "All", "ip4" ve "ip6" mekanizmaları, DNS aramaları gerektirmez ve bu nedenle bu sınıra dahil değildir.
[...]
"Mx" ve "ptr" mekanizmalarını veya% {p} makrosunu değerlendirirken, 10 MX veya PTR RR'den daha fazla bakılmayan ve kontrol edilmeyen bir limit OLMALIDIR.
Bu nedenle, DNS aramalarını tetikleyen en fazla 10 mekanizma / değiştirici kullanabilirsiniz. (Buradaki ifade zayıftır: Sınırın sadece üst sınırını belirttiği anlaşılıyor, onaylayıcı bir uygulamanın 2 limiti olabilir.)
§5.4 için mx için mekanizmanın ve §5.5 ptr mekanizmasının her isim bu tür 10 aramaları bir sınırı vardır ve o mekanizma sadece, örneğin işlenmesi için de geçerlidir:
Hizmet Reddi (DoS) saldırılarını önlemek için, bir "mx" mekanizmasının değerlendirilmesinde 10'dan fazla MX adına bakılmaması GEREKİR (bkz. Bölüm 10).
Buradaki her bir 200 toplam 20 DNS işlemleri (10 MX + 10 DNS her aramaları) neden olabilir, böylece örneğin Bunun için benzerdir, 10 MX kadar isim ile, 10 mx mekanizmalarına sahip olabilir ptr veya % {s} , sen 10 ptr mekanizmalarını, dolayısıyla 10x10 PTR'leri arayabilir, her PTR, ayrıca toplam 200'lük bir A araması gerektirir.
Bu tam olarak 2009.10 test paketinin kontrol ettiği şeydir , " İşlem Sınırları " testlerine bakın.
SPF-kontrol başına toplam müşteri DNS arama işlemi sayısı üzerinde açıkça bir üst sınır yoktur , bunu örtük olarak 210 olarak hesaplarım, verir veya alırım. SPF kontrolü başına DNS verilerinin hacmini sınırlama önerisi de vardır, ancak gerçek bir sınır önerilmemektedir. SPF kayıtları 450 bayt ile sınırlıdır (ne yazık ki diğer tüm TXT kayıtları ile paylaşılır), ancak cömertseniz toplam 100B'yi aşabilir. Bu iki değer de, bir amplifikasyon saldırısı olarak potansiyel istismara açıkça açıktır, bu da kesinlikle §10.1'den kaçınmanız gerektiğini söylüyor.
Ampirik kanıtlar, kayıtlarda genel olarak toplam 10 arama mekanizması uygulandığını öne sürmektedir (SPF’yi, tam olarak 10’a uyacak kadar uzun süren SPF’yi inceleyin). Çok fazla arama hatası olmadığını gösteren kanıtları toplamak zordur, çünkü zorunlu hata kodu her türlü sorunu kapsayan basitçe "PermError" dır ( DMARC raporları bu konuda yardımcı olabilir).
OpenSPF SSS , daha kesin olan "10 DNS'e neden olan mekanizmalar veya yönlendirmeler" yerine, toplamda "10 DNS araması" sınırını sürdürür . Bu SSS aslında söylediği için tartışmasız yanlıştır:
Bir IP adresi belirterek, SPF kaydı başına 10 DNS araması sınırı olduğundan, [...]
"SPF kontrolü" işlemine sınırlar getiren RFC ile uyuşmayan, DNS arama işlemlerini bu şekilde sınırlamaz ve bir SPF kaydının tek bir DNS metni RR olduğunu açıkça belirtir . SSS, yeni bir SPF kaydı olduğu gibi bir "dahil" işlemini işlediğinizde sayımı yeniden başlattığınız anlamına gelir. Ne dağınıklık.
DNS aramaları
Zaten "DNS araması" nedir? Bir kullanıcı olarak . " ping www.microsoft.com" Tek bir DNS "araması" içerdiğini düşünürdüm : bir IP'ye dönüştürmeyi umduğum bir isim var. Basit? Ne yazık ki hayır.
Bir yönetici olarak , www.microsoft.com’un tek bir IP’ye sahip basit bir A kaydı olamayabileceğini biliyorum. Sırasıyla, yukarı akış çözümleyicimin büyük olasılıkla gerçekleştirecek olmasına rağmen, bir A kaydı elde etmek için ayrı bir arama yapılmasını gerektiren bir CNAME olabilir. masaüstümdeki çözümleyici yerine. Bugün, benim için, www.microsoft.com, akamaiedge.net'te nihayet bir A kaydı olarak biten bir 3 CNAME zincirinden oluşan bir zincir. SPF, "ptr" mekanizmalı CNAME'leri görebilir, MX kaydı yine de CNAME olmamalıdır.
Son olarak, bir DNS yöneticisi olarak, herhangi bir soruyu yanıtlamanın (neredeyse) birçok ayrı DNS işlemi, bireysel sorular ve cevap işlemleri (UDP datagramları) içerdiğini biliyorum - boş bir önbellek varsayalım, özyinelemeli bir çözümleyicinin DNS kökünden başlaması ve çalışması gerekir. aşağı: . → com→ microsoft.com→ www.microsoft.combelirli kayıt tiplerini (NS, A vb.) sorma ve CNAME'lerle ilgilenme. Sen ile eyleme görebilirsiniz dig +trace www.microsoft.commuhtemelen (örneğe nedeniyle coğrafi konum kandırmaca için tam aynı cevabı almazsınız olsa burada ). (SPF, TXT kayıtlarını engellediğinden ve DNS yanıtlarında kullanılmayan 512 baytlık sınırların TCP üzerinden yeniden denenmesi anlamına gelebileceğinden bu karmaşıklıktan biraz daha fazlası var.)
Öyleyse SPF arama olarak ne düşünüyor? Yönetici bakış açısına gerçekten en yakın olanı , her DNS sorgusu türünün özelliklerini bilmesi gerekir (ancak tek tek DNS datagramlarını veya bağlantılarını sayması gereken noktaya değil).