Насколько я понимаю, спецификация SPF указывает, что получатель электронной почты не должен выполнять более 10 DNS-запросов, чтобы собрать все разрешенные IP-адреса для отправителя. Итак, если запись SPF имеет include:foo.com include:bar.com include:baz.com и у этих трех доменов есть записи SPF, которые также имеют 3 include записей, теперь у нас до 3 + 3 + 3 + 3 = 12 DNS-запросов.
правильно ли мое понимание выше?
Я использую только 2 или 3 службы для своего домена, и я уже прошел это ограничение. Применяется ли это ограничение обычно (или когда-либо) основными / второстепенными поставщиками электронной почты?
Обе 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» открыт для интерпретации, вы не знаете заранее, сколько дискретных поисков требуется, и вы не знаете, сколько дискретных поисков может потребоваться вашему рекурсивному преобразователю (см. Ниже).
Реализации SPF ДОЛЖНЫ ограничивать количество механизмов и модификаторов, выполняющих поиск в DNS, до 10 на каждую проверку SPF, включая любые поиски, вызванные использованием механизма «включить» или модификатора «перенаправления». Если это число будет превышено во время проверки, ДОЛЖНА быть возвращена ошибка PermError. Механизмы «include», «a», «mx», «ptr» и «exists», а также модификатор «redirect» учитываются при этом ограничении. Механизмы «all», «ip4» и «ip6» не требуют поиска DNS и, следовательно, не учитываются в этом ограничении.
[...]
При оценке механизмов «mx» и «ptr» или макроса% {p} ДОЛЖЕН быть предел не более 10 найденных и проверенных записей MX или PTR.
Таким образом, вы можете использовать до 10 механизмов / модификаторов, запускающих поиск DNS. (Формулировка здесь неудачная: кажется, что указана только верхняя граница предела, подтверждающая реализация может иметь предел 2.)
§5.4 для mx механизм, и §5.5 для ptr Каждый механизм имеет ограничение в 10 поисков такого типа имени, и это относится только к обработке этого механизма, например:
Чтобы предотвратить атаки типа «отказ в обслуживании» (DoS), более 10 имен MX НЕ ДОЛЖНЫ просматриваться во время оценки механизма «mx» (см. Раздел 10).
то есть у вас может быть 10 механизмов MX с до 10 именами MX, поэтому каждый из них может вызвать 20 операций DNS (10 запросов MX + 10 DNS каждая), всего 200. Это похоже на ptr или %{п}, вы можете посмотреть 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 хотя отчеты могут помочь в этом).
FAQ по OpenSPF увековечивает предел всего «10 DNS-запросов», а не более точных «10 DNS-механизмов или перенаправлений». Этот FAQ, возможно, неверен, поскольку на самом деле он говорит:
Поскольку существует ограничение в 10 запросов DNS на одну запись SPF, при указании IP-адреса [...]
что не согласуется с RFC, который налагает ограничения на операцию «проверки SPF», не ограничивает таким образом операции поиска DNS и четко указывает SPF запись представляет собой один DNS-текст RR. Часто задаваемые вопросы подразумевают, что вы перезапускаете счетчик при обработке «include», поскольку это новая запись SPF. Какой беспорядок.
В любом случае, что такое «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 или соединения).
RFC4408 s10.1 действительно, как вы отметили, накладывает некоторые ограничения на активность DNS. В частности:
Реализации SPF ДОЛЖНЫ ограничивать количество механизмов и модификаторов, выполняющих поиск в DNS, до 10 на каждую проверку SPF, включая любые поиски, вызванные использованием механизма «включить» или модификатора «перенаправления». Если это число будет превышено во время проверки, ДОЛЖНА быть возвращена ошибка PermError. Механизмы «include», «a», «mx», «ptr» и «exists», а также модификатор «redirect» учитываются при этом ограничении. Механизмы «all», «ip4» и «ip6» не требуют поиска DNS и, следовательно, не учитываются в этом ограничении. Модификатор «exp» не учитывается при этом ограничении, потому что поиск в DNS для получения строки объяснения происходит после оценки записи SPF.
и более того
При оценке механизмов «mx» и «ptr» или макроса% {p} ДОЛЖЕН быть предел не более 10 найденных и проверенных записей MX или PTR.
Обратите внимание, что первое - это ограничение на количество механизмы, а не количество выполненных поисков; но это все еще предел.
Насколько я могу судить, да, эти ограничения соблюдаются довольно жестко. Они предназначены для того, чтобы люди не создавали произвольно сложные записи SPF и не использовали их для серверов DoS, которые проверяют их записи, останавливая их в огромной цепочке запросов DNS, поэтому это в интересах любого, кто реализует средство проверки SPF для почитай их.
Вы правильно заметили, что вложенные включения, вероятно, вызовут самую большую проблему с этими ограничениями, и если вы решите включить несколько доменов, каждый из которых активно использует сами включения, то вы можете довольно быстро просмотреть их. Это не так уж сложно найти примеры людей, для которых это создало конкретные проблемы.
В результате, похоже, проблемы обычно возникают, когда люди решают использовать обе SPF и несколько разных и разрозненных компаний для обработки исходящей электронной почты. Из вашего вопроса я делаю вывод, что вы попадаете в эту категорию. SPF, похоже, не предназначен для обслуживания людей, которые решают это сделать.. Если вы настаиваете на этом, вам, вероятно, придется иметь какое-то задание cron на вашем DNS-сервере, которое постоянно оценивает все записи SPF, которые вы хотели бы включить, выражает их как серию ip4: и ip6: механизмы (количество которых не ограничено) и повторно публикует результат как вашу запись SPF.
Не забудьте закончить -all, или все упражнение было бессмысленным.