Обычно предел С 10 ПОИСКАМИ DNS в спецификации SPF осуществлен?
От sshd_config(5) страница справочника:
ChrootDirectory
Specifies a path to chroot(2) to after authentication. This
path, and all its components, must be root-owned directories that
are not writable by any other user or group.
Необходимо выключить бит записи группы.
Both libspf2 (C) and Mail::SPF::Query (perl, used in sendmail-spf-milter) implement a limit of 10 DNS-causing mechanisms, but the latter does not (AFAICT) apply the MX or PTR limits. libspf2 limits each of mx and ptr to 10 also.
Mail::SPF (perl) has a limit of 10 DNS-causing mechanisms, and a limit of 10 lookups per mechanism, per MX and per PTR. (The two perl packages are commonly, though not by default, used in MIMEDefang.)
pyspf has limits of 10 on all of: "lookups", MX, PTR, CNAME; but it explicitly multiplies MAX_LOOKUPS by 4 during operation. Unless in "strict" mode, it also multiples MAX_MX and MAX_PTR by 4.
I can't comment on commercial/proprietary implementations, but the above (except pyspf) clearly implement an upper limit of 10 DNS-triggering mechanisms (more on that below), give or take, though in most cases it can be overridden at run-time.
In your specific case you are correct, it is 12 includes and that exceeds the limit of 10. I would expect most SPF software to return "PermError", however, failures will only affect the final "included" provider(s) because the count will be calculated as a running total: SPF mechanisms are evaluated left-to-right and checks will "early-out" on a pass, so it depends on where in the sequence the sending server appears.
The way around this is to use mechanisms which do not trigger DNS lookups, e.g. ip4 and ip6, and then use mx if possible as that gets you up to 10 further names, each of which can have more than one IP.
Since SPF results in arbitrary DNS requests with potentially exponential scaling, it could easily be exploited for DOS/amplification attacks. It has deliberately low limits to prevent this: it does not scale the way you want.
10 mechanisms (strictly mechanisms + the "redirect" modifier) causing DNS look-ups is not exactly the same thing as 10 DNS look-ups though. Even "DNS lookups" is open to interpretation, you don't know in advance how many discrete lookups are required, and you don't know how many discrete lookups your recursive resolver may need to perform (see below).
SPF implementations MUST limit the number of mechanisms and modifiers которые выполняют поиск в DNS не более 10 за проверку SPF, включая любые поиск, вызванный использованием механизма "включить" или модификатор "перенаправление". Если это число превышено во время проверки, PermError ДОЛЖЕН быть возвращен. "Include", "a", "mx", "ptr" и Учитываются механизмы "существует", а также модификатор "перенаправление" против этого предела. Механизмы "all", "ip4" и "ip6" не работают. требуют поиска DNS и поэтому не учитываются в этом ограничении.
[...]
При оценке механизмов «mx» и «ptr» или макроса% {p}, ДОЛЖЕН быть предел не более 10 записей MX или PTR, найденных и checked.
So you may use up to 10 mechanisms/modifiers which trigger DNS lookups. (The wording here is poor: it seems to state only the upper bound of the limit, a confirming implementation could have a limit of 2.)
§5.4 for the mx mechanism, and §5.5 for the ptr mechanism each have a limit of 10 lookups of that kind of name, and that applies to the processing of that mechanism only, e.g.:
To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the оценка механизма "mx" (см. раздел 10).
т.е. у вас может быть 10 механизмов mx с до 10 имен MX, поэтому каждый из них может вызвать 20 операций DNS (10 запросов MX + 10 A DNS каждая) всего 200. Это похоже на ptr или % {p} , вы можете найти 10 ptr механизмов, следовательно, 10x10 PTR, каждый PTR также требует Поиск, снова всего 200.
Это именно то, что проверяет набор тестов 2009.10 , см. Тесты « Пределы обработки ».
Четко не указано. верхний предел общего числа клиентских операций поиска DNS на SPF-проверку, я рассчитываю его как неявно 210, плюс-минус. Также предлагается ограничить объем данных DNS для каждой SPF-проверки, однако фактического ограничения не предлагается. Вы можете получить приблизительную оценку, так как записи SPF ограничены 450 байтами (которые, к сожалению, разделяются со всеми другими записями TXT), но общая сумма может превышать 100 КБ, если вы щедры. Оба эти значения явно открыты для потенциального злоупотребления в виде атаки с усилением, а именно этого, как сказано в §10.1, вам следует избегать.
Эмпирические данные показывают, что всего из 10 механизмов поиска обычно реализованы в записях ( посмотрите SPF для microsoft.com, которые, похоже, приложили немало усилий, чтобы сохранить его ровно 10). Трудно собрать свидетельства сбоя слишком большого количества запросов, потому что обязательный код ошибки - это просто PermError, который охватывает все виды проблем (хотя отчеты DMARC могут помочь в этом).
OpenSPF FAQ увековечивает ограничение на общее количество " одно имя, которое я ожидаю превратить в один 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 рассматривает как поиск? Это'
RFC4408 s10.1 does, as you have noted, put some limits on DNS activity. Specifically:
SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.
and moreover
When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked.
Note that the former is a limit on the number of mechanisms, not the number of lookups performed; but it is still a limit.
As far as I can tell, yes, these limits are enforced fairly hard. They're designed to stop people constructing arbitrarily complex SPF records and using those to DoS servers that check their record by grinding them to a halt in a huge chain of DNS lookups, so it's in the best interests of anyone who implements an SPF checker to honour them.
You are right to note that nested includes are likely to cause the biggest problem with these limits, and if you decide to include several domains each of which makes heavy use of includes themselves, then you can fairly quickly go over them. It's not too hard to find examples of people for whom this has created concrete issues.
The upshot seems to be that problems generally arise when people decide to use both SPF
and several distinct and disparate companies to handle their outgoing email. I infer from your question that you fit into that category. SPF does not seem to be designed to serve people who choose to do this. If you insist on doing this, you will likely have to have some kind of cron job on your DNS server that constantly evaluates all the SPF records you would have wished to include, expresses them as a series of ip4: and ip6: mechanisms (on the number of which there is no limit), and republishes the result as your SPF record.
Don't forget to finish with a -all, or the whole exercise was pointless.