И 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, включая любые запросы, вызванные использованием механизма «include» или модификатора «redirect». Если это число превышено во время проверки, ДОЛЖНА быть возвращена PermError. Механизмы «include», «a», «mx», «ptr» и «exist», а также модификатор «redirect» учитывают этот предел. Механизмы «all», «ip4» и «ip6» не требуют поиска DNS и, следовательно, не учитываются в этом ограничении.
[...]
При оценке механизмов «mx» и «ptr» или макроса% {p} ДОЛЖЕН быть установлен предел не более 10 MX или PTR RR.
Таким образом, вы можете использовать до 10 механизмов / модификаторов, которые запускают поиск DNS. (Формулировка здесь плохая: кажется, что она устанавливает только верхнюю границу ограничения, подтверждающая реализация может иметь предел 2.)
§5.4 для механизма mx и §5.5 для механизма ptr имеют ограничение в 10 поисков такого типа имени, и это относится только к обработке этого механизма, например:
Чтобы предотвратить атаки типа «отказ в обслуживании» (DoS), НЕ ДОЛЖНО проверяться более 10 имен MX во время оценки механизма «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 представляет собой отдельную текстовую запись DNS RR. Часто задаваемые вопросы подразумевают, что вы перезапускаете счетчик при обработке «включения», поскольку это новая запись SPF. Какой беспорядок
DNS-поиск
Что такое DNS-поиск? Как пользователь . Я бы подумал, что « ping www.microsoft.com» включает в себя один DNS-запрос: есть одно имя, которое я ожидаю превратить в один IP. Просто? К сожалению нет.
Как администратор, я знаю, что www.microsoft.com может быть не простой записью A с одним IP-адресом, это может быть CNAME, который, в свою очередь, нуждается в другом дискретном поиске для получения записи A, хотя тот, который, вероятно, будет выполнять мой восходящий преобразователь а не решатель на моем рабочем столе. Сегодня для меня www.microsoft.com представляет собой цепочку из 3 CNAME, которые в конечном итоге становятся записью A на 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 или соединения).