Baik libspf2(C) dan Mail::SPF::Query(perl, digunakan dalam sendmail-spf-milter ) menerapkan batas 10 mekanisme penyebab DNS , tetapi yang terakhir tidak (AFAICT) menerapkan batas MX atau PTR. libspf2membatasi masing-masing mx dan ptr hingga 10 juga.
Mail::SPF(perl) memiliki batas 10 mekanisme yang menyebabkan DNS, dan batas 10 pencarian per mekanisme, per MX dan per PTR. (Dua paket perl umumnya, meskipun tidak secara default, digunakan dalam MIMEDefang .)
pyspfmemiliki batas 10 pada semua: "pencarian", MX, PTR, CNAME; tetapi secara eksplisit mengalikan MAX_LOOKUPS dengan 4 selama operasi. Kecuali dalam mode "ketat", ini juga mengalikan MAX_MX dan MAX_PTR dengan 4.
Saya tidak bisa berkomentar tentang implementasi komersial / kepemilikan, tetapi di atas (kecuali pyspf) jelas menerapkan batas atas 10 mekanisme pemicu DNS (lebih lanjut tentang itu di bawah), memberi atau menerima, meskipun dalam kebanyakan kasus dapat ditimpa saat dijalankan- waktu.
Dalam kasus spesifik Anda, Anda benar, itu termasuk 12 dan melebihi batas 10. Saya berharap sebagian besar perangkat lunak SPF mengembalikan "PermError", namun , kegagalan hanya akan memengaruhi penyedia "yang termasuk" terakhir karena penghitungannya akan dihitung sebagai total berjalan: mekanisme SPF dievaluasi dari kiri ke kanan dan pengecekan akan "lebih awal" pada pass, sehingga tergantung pada di mana dalam urutan server pengirim muncul.
Cara mengatasinya adalah dengan menggunakan mekanisme yang tidak memicu pencarian DNS, misalnya ip4dan ip6, dan kemudian gunakan mxjika mungkin karena itu membuat Anda hingga 10 nama lebih lanjut, yang masing-masing dapat memiliki lebih dari satu IP.
Karena SPF menghasilkan permintaan DNS sewenang-wenang dengan potensi penskalaan eksponensial, maka dapat dengan mudah dieksploitasi untuk serangan DOS / amplifikasi. Ini sengaja membatasi rendah untuk mencegah ini: itu tidak skala seperti yang Anda inginkan.
10 mekanisme (hanya mekanisme + pengubah "redirect") yang menyebabkan pencarian DNS tidak persis sama dengan 10 pencarian DNS. Bahkan "pencarian DNS" terbuka untuk interpretasi, Anda tidak tahu sebelumnya berapa banyak pencarian diskrit yang diperlukan, dan Anda tidak tahu berapa banyak pencarian diskrit yang harus dilakukan oleh resolver rekursif Anda (lihat di bawah).
RFC 4408 §10.1 :
Implementasi SPF HARUS membatasi jumlah mekanisme dan pengubah yang melakukan pencarian DNS paling banyak 10 per cek SPF, termasuk semua pencarian yang disebabkan oleh penggunaan mekanisme "include" atau pengubah "redirect". Jika nomor ini terlampaui selama pemeriksaan, PermError HARUS dikembalikan. Mekanisme "sertakan", "a", "mx", "ptr", dan "ada" serta pengubah "pengalihan" dihitung terhadap batas ini. Mekanisme "semua", "ip4", dan "ip6" tidak memerlukan pencarian DNS dan karenanya tidak dihitung terhadap batas ini.
[...]
Ketika mengevaluasi mekanisme "mx" dan "ptr", atau makro% {p}, HARUS ada batas tidak lebih dari 10 MX atau RR PTR yang melihat dan memeriksa.
Jadi, Anda dapat menggunakan hingga 10 mekanisme / pengubah yang memicu pencarian DNS. (Kata-katanya di sini buruk: tampaknya hanya menyatakan batas atas batas, implementasi yang dikonfirmasi dapat memiliki batas 2.)
§5.4 untuk mekanisme mx , dan §5.5 untuk mekanisme ptr masing-masing memiliki batas 10 pencarian nama semacam itu, dan itu berlaku untuk pemrosesan mekanisme itu saja, misalnya:
Untuk mencegah serangan Denial of Service (DoS), lebih dari 10 nama MX TIDAK HARUS dilihat selama evaluasi mekanisme "mx" (lihat Bagian 10).
yaitu Anda mungkin memiliki mekanisme 10 mx, dengan hingga 10 nama MX, sehingga masing-masing dapat menyebabkan 20 operasi DNS (masing-masing 10 MX + 10 A pencarian DNS) untuk total 200. Ini serupa untuk ptr atau % {p} , Anda dapat melihat 10 mekanisme ptr , maka 10x10 PTR, setiap PTR juga membutuhkan pencarian A, sekali lagi total 200.
Inilah yang diperiksa oleh test suite 2009.10 , lihat tes " Batas Pemrosesan ".
Tidak ada batas atas yang dinyatakan dengan jelas pada jumlah total operasi pencarian DNS klien per-SPF-cek, saya menghitungnya secara implisit 210, memberi atau menerima. Ada juga saran untuk membatasi volume data DNS per-SPF-check, namun tidak ada batas aktual yang disarankan. Anda bisa mendapatkan perkiraan kasar karena catatan SPF dibatasi hingga 450 byte (yang sayangnya dibagi dengan semua catatan TXT lainnya), tetapi totalnya bisa melebihi 100kiB jika Anda murah hati. Kedua nilai itu jelas terbuka untuk penyalahgunaan potensial sebagai serangan amplifikasi, yang persis seperti yang dikatakan §10.1 yang harus Anda hindari.
Bukti empiris menunjukkan total 10 mekanisme pencarian umumnya diimplementasikan dalam catatan (lihat SPF untuk microsoft.com yang tampaknya telah berusaha keras untuk mempertahankannya hingga 10). Sulit untuk mengumpulkan bukti kegagalan pencarian terlalu banyak karena kode kesalahan yang diamanatkan hanyalah "PermError", yang mencakup semua jenis masalah ( pelaporan DMARC mungkin membantu dengan itu).
FAQ OpenSPF melanggengkan batas total "10 pencarian DNS", daripada "10 DNS yang menyebabkan mekanisme atau pengalihan" yang lebih tepat. FAQ ini bisa dibilang salah karena sebenarnya mengatakan:
Karena ada batas 10 pencarian DNS per catatan SPF, menentukan alamat IP [...]
yang tidak setuju dengan RFC yang memberlakukan batasan pada operasi "pemeriksaan SPF", tidak membatasi operasi pencarian DNS dengan cara ini, dan dengan jelas menyatakan catatan SPF adalah teks DNS tunggal RR. FAQ akan menyiratkan bahwa Anda memulai kembali penghitungan ketika Anda memproses "termasuk" karena itu adalah catatan SPF baru. Berantakan sekali.
Pencarian DNS
Apa itu "pencarian DNS"? Sebagai pengguna . Saya akan mempertimbangkan " ping www.microsoft.comuntuk melibatkan" pencarian "DNS tunggal: ada satu nama yang saya harapkan berubah menjadi satu IP. Sederhana? Sayangnya tidak.
Sebagai administrator saya tahu bahwa www.microsoft.com mungkin bukan catatan A sederhana dengan IP tunggal, itu mungkin CNAME yang pada gilirannya membutuhkan pencarian diskrit lain untuk mendapatkan catatan A, meskipun itu yang mungkin akan dilakukan oleh resolver upstream saya. daripada resolver di desktop saya. Hari ini, bagi saya, www.microsoft.com adalah rantai 3 CNAME yang akhirnya berakhir sebagai catatan A di akamaiedge.net, itu (setidaknya) 4 operasi permintaan DNS untuk seseorang. SPF mungkin melihat CNAME dengan mekanisme "ptr", catatan MX seharusnya bukan CNAME.
Akhirnya, sebagai adminstrator DNS, saya tahu bahwa menjawab (hampir) pertanyaan apa pun melibatkan banyak operasi DNS terpisah, pertanyaan individual dan transaksi transaksi (datagram UDP) - dengan asumsi cache kosong, resolver rekursif perlu dimulai pada root DNS dan bekerja dengan caranya bawah: . → com→ microsoft.com→ www.microsoft.commeminta jenis catatan tertentu (NS, A dll) seperti yang diperlukan, dan berurusan dengan CNAME. Anda dapat melihat ini dalam tindakan dig +trace www.microsoft.com, meskipun Anda mungkin tidak akan mendapatkan jawaban yang sama persis karena tipu daya geolokasi (contoh di sini ). (Bahkan ada sedikit lebih banyak untuk kompleksitas ini sejak piggybacks SPF pada catatan TXT, dan batas usang 512 byte pada jawaban DNS mungkin berarti mencoba kembali permintaan melalui TCP.)
Jadi, apa yang SPF pertimbangkan sebagai pencarian? Ini benar-benar paling dekat dengan sudut pandang administrator , perlu untuk mengetahui secara spesifik setiap jenis permintaan DNS (tetapi tidak sampai pada titik di mana ia benar-benar perlu menghitung datagram atau koneksi DNS individu).