І libspf2(C), і Mail::SPF::Query(perl, використовувані в sendmail-spf-milter ) реалізують ліміт 10 механізмів , що викликають DNS , але останній не застосовує (AFAICT) межі MX або PTR. libspf2також обмежує кожен з mx та ptr до 10.
Mail::SPF(perl) має обмеження 10 механізмів, що викликають DNS, і обмеження 10 підходів на механізм, на MX та на PTR. (Два пакети perl зазвичай використовуються в MIMEDefang , хоча вони не за замовчуванням .)
pyspfмає обмеження 10 на всіх: "пошуку", MX, PTR, CNAME; але він явно множує MAX_LOOKUPS на 4 під час роботи. Якщо в режимі "суворий" режим, він також множить MAX_MX та MAX_PTR на 4.
Я не можу коментувати комерційні / власні реалізації, але вище (за винятком pyspf) чітко реалізується верхня межа 10 механізмів, що викликають DNS (детальніше про це нижче), давати або приймати, хоча в більшості випадків це можна змінити під час запуску- час.
У вашому конкретному випадку ви правильні, це 12 включає, і це перевищує ліміт 10. Я очікував би, що більшість програмного забезпечення SPF поверне "PermError", однак , помилки вплинуть лише на остаточного постачальника (включених), оскільки кількість буде обчислюватися як поточний загальний результат: механізми SPF оцінюються зліва направо, і перевірки будуть "достроково" на пропуску, тому це залежить від того, де в послідовності відображається сервер, що відправляє.
Шляхом цього є використання механізмів, які не викликають пошук DNS, наприклад, ip4і ip6, а потім використовувати, mxякщо це можливо, ви отримуєте до 10 подальших імен, кожне з яких може мати більше одного IP-адреси.
Оскільки SPF призводить до довільних запитів DNS з потенційно експоненціальним масштабуванням, його можна легко використовувати для атак DOS / посилення. У нього свідомо низькі межі, щоб запобігти цьому: він не масштабує так, як вам хочеться.
10 механізмів (строго механізми + модифікатор переспрямування), що викликають пошук DNS, не зовсім те саме, що 10 пошукових запитів DNS. Навіть "пошук DNS" відкритий для інтерпретації, ви не знаєте заздалегідь, скільки дискретних пошукових запитів потрібно, і ви не знаєте, скільки дискретних пошуків може знадобитися виконувати рекурсивний роздільник (див. Нижче).
RFC 4408 §10.1 :
Реалізації SPF ОБОВ'ЯЗКОВО обмежують кількість механізмів і модифікаторів, які здійснюють пошук DNS не більше ніж 10 за кожну перевірку SPF, включаючи будь-які пошуки, спричинені використанням механізму "включати" або модифікатора "перенаправлення". Якщо це число перевищено під час перевірки, ПЕРЕМОГА ПОВИННА повернутись. Механізми "включати", "a", "mx", "ptr" і "існує", а також модифікатор "перенаправлення" зараховуються до цієї межі. Механізми "всі", "ip4" та "ip6" не вимагають пошуку DNS і тому не враховуються до цієї межі.
[...]
Оцінюючи механізми "mx" і "ptr", або макрос% {p}, ОБОВ'ЯЗКОВО слід встановити обмеження не більше 10 MX або PTR RR, яке було перевірено та перевірено.
Таким чином, ви можете використовувати до 10 механізмів / модифікаторів, які викликають пошук DNS. (Формулювання тут бідне: воно, мабуть, зазначає лише верхню межу межі; підтверджуюча реалізація може мати межу 2).
§5.4 для механізму mx та §5.5 для механізму ptr мають обмеження в 10 пошукових запитів такої назви, і це стосується лише обробки цього механізму, наприклад:
Для запобігання атак на відмову в сервісі (DoS) під час оцінки механізму "mx" НЕ ПОВИННІ шукати більше 10 імен MX (див. Розділ 10).
тобто у вас може бути 10 mx механізмів, до 10 імен MX, тому кожен з них може спричинити 20 DNS-операцій (10 MX + 10 A DNS-пошуку в кожному) на загальну 200. Це схоже на ptr або % {p} , ви можна шукати 10 ptr механізмів, отже, 10x10 PTR, кожен PTR також потребує пошуку A, знову ж, 200.
Саме це перевіряє тестовий набір 2009.10 , див . Тести " Обмеження обробки ".
Немає чітко зазначеної верхньої межі щодо загальної кількості операцій пошуку DNS клієнта за перевірку SPF, я обчислюю це як неявно 210, даю чи беру. Також є пропозиція обмежити об'єм даних DNS за перевірку SPF, проте фактична межа не пропонується. Ви можете отримати приблизну оцінку, оскільки записи SPF обмежені 450 байтами (що, на жаль, ділиться з усіма іншими записами TXT), але загальна сума може перевищити 100 КБ, якщо ви щедрі. Обидві ці цінності явно відкриті для потенційного зловживання як нападу посилення, саме тому §10.1 говорить, що потрібно уникати.
Емпіричні дані свідчать про те, що загалом у документах реалізується 10 механізмів пошуку (перегляньте SPF для microsoft.com, який, схоже, досяг певного рівня, щоб утримати його точно до 10). Важко зібрати докази відмови занадто багато-пошукових запитів, оскільки доручений код помилки просто "PermError", який охоплює всілякі проблеми ( DMARC звітність може допомогти у цьому).
Поширені питання OpenSPF продовжує обмеження загальної кількості "10 пошукових запитів DNS", а не більш точних "10 DNS, що викликають механізми або переадресації". Цей FAQ може бути помилковим, оскільки він фактично говорить:
Оскільки існує обмеження 10 пошукових запитів DNS на запис SPF із зазначенням IP-адреси [...]
яка не згідна з RFC, яка накладає обмеження на операцію "перевірка SPF", не обмежує таким чином операції пошуку DNS, і чітко заявляє, що запис SPF є єдиним текстом RR DNS. Поширені питання означають, що ви перезавантажуєте кількість під час обробки "включати", оскільки це новий запис SPF. Який безлад.
Пошук DNS
Що таке "пошук DNS" у будь-якому випадку? Як користувач . Я вважаю, що " ping www.microsoft.com" буде задіяно один "пошук" DNS: є одне ім'я, яке я очікую перетворити в один IP. Простий? На жаль, ні.
Як адміністратор, я знаю, що www.microsoft.com може бути не простою записом з єдиним IP-адресою; це може бути CNAME, який, у свою чергу, потребує іншого дискретного пошуку, щоб отримати запис A, хоч і такий, який, ймовірно, виконає мій розв'язник за течією а не роздільник на моєму робочому столі. Сьогодні для мене www.microsoft.com - це ланцюжок із 3-х CNAME, які нарешті є записом на akamaiedge.net, це (принаймні) 4 операції запиту DNS для когось. SPF може бачити CNAME з механізмом "ptr", запис MX не повинен бути CNAME.
Нарешті, як адміністратор DNS я знаю, що відповідь (майже) на будь-яке запитання включає багато дискретних операцій DNS, окремих питань та транзакцій відповідей (дейтаграми UDP) - припускаючи порожній кеш, рекурсивний вирішальник повинен запускатися в корені DNS і працювати на своєму шляху вниз: . → com→ microsoft.com→ www.microsoft.comзапит на конкретні типи записів (NS, A тощо), як це потрібно, та спілкування з CNAME. Ви можете бачити це в дії dig +trace www.microsoft.com, хоча ви, мабуть, не отримаєте точно таку ж відповідь через хитрість геолокації (приклад тут ). (Існує навіть трохи більше цієї складності, оскільки копіювання файлів SPF в TXT-записах, а застарілі межі 512 байт на відповіді DNS можуть означати повторний пошук запитів через TCP.)
Отже, що SPF розглядає як пошук? Це дійсно найближче до точки зору адміністратора , воно повинно знати про особливості кожного типу запитів DNS (але не до того, коли йому насправді потрібно рахувати окремі дейтаграми або з'єднання DNS).