Какие проблемы существуют с механизмом SPF 'ptr'?
Одним из механизмов SPF является ptr. Этот механизм проверяет, что отправитель, использующий некоторое доменное имя, подключается с (подтвержденного пересылкой) IP-адреса, указывающего на поддомен этого имени.
Например, если отправитель me@example.com подключается с IP-адреса 1.2.3.4, то механизм ptr сначала выполнит обратный поиск на 1.2.3.4. Если доменное имя, возвращенное этим поиском (например, mail.example.com), также имеет IP-адрес 1.2.3.4 и является поддоменом example.com, то отправитель авторизован.
Это кажется полезной функцией. На момент написания статьи домен yahoo.com использовал этот механизм в своих SPF-записях.
Однако спецификация SPF явно не рекомендует использовать механизм ptr ('НЕ ДОЛЖЕН быть опубликован' [= использование может быть допустимо в определенных обстоятельствах, но только после тщательного обдумывания]). Он дает следующее объяснение:
Примечание: Этот механизм медленный, он не так надежен, как другие механизмы в случае ошибок DNS, и он создает большую нагрузку на серверы имен .arpa. Если он используется, для хостов домена должны быть созданы соответствующие записи PTR, и механизм "ptr" ДОЛЖЕН быть одним из последних проверяемых механизмов. После многолетнего опыта развертывания SPF был сделан вывод, что в нем нет необходимости, и вместо него следует использовать более надежные альтернативы".
Это объяснение кажется мне довольно туманным или, по крайней мере, недостаточно убедительным, чтобы полностью отказаться от этой полезной функции. Почему механизм "медленный" или "ненадежный", и каким образом он создает "большую" нагрузку на серверы имен? Уверен, что выполнение одного дополнительного поиска DNS в контексте почтового сервера не может быть большой проблемой?
Есть ли веские практические причины для отказа от использования ptr, или его использование может быть оправдано, несмотря на текст RFC?
Я бы сказал, что это медленно, потому что для обработки требуется несколько запросов; сначала поиск PTR на основе IP-адреса подключения, затем подтверждение этого ответа путем поиска A или AAAA для имен, которые вы получили в PTR результат для проверки его фактического совпадения перед использованием результата PTR для определения результата SPF.
Имейте в виду, что SPF всегда сводится к указанию списка разрешенных IP-адресов, которые получатель может использовать для определения того, доставляется ли входящая почта легитимным хостом, и поэтому идеальными механизмами SPF являются ip4 / ip6 .
Все остальные механизмы - это просто косвенные ссылки, которые обеспечивают определенное удобство для издателя SPF за счет эффективности для получателя электронной почты; поэтому существует ограничение в 10 поисков из этих косвенных адресов для обеспечения некоторого баланса путем ограничения затрат на проверку входящего электронного письма для получателя.
Обратите внимание, что частным случаем механизма SPF ptr является косвенное указание, когда издатель записи SPF даже не знает, какую последовательность поисков они запрашивают у получателя электронной почты (в качестве первоначального поиска зависит от подключаемого IP-адреса!). На мой взгляд, это делает его еще более проблематичным как с точки зрения скорости, так и с точки зрения надежности.
Что касается нагрузки на .arpa nameservers, наличие механизма, который вызывает больше запросов как часть процесса доставки почты, очевидно, увеличило бы его, но трудно судить, насколько серьезной проблемой может быть на практике по сравнению со всеми другими обратными поисками, сделанными для других причины.
Действительно, упомянутые проблемы с ptrкажутся незначительными. Я бы сказал, что они вряд ли появятся в профиле производительности настройки почтового сервера.
Однако есть одно место, где ptrимеет явный недостаток по сравнению с другими механизмами. Параграф 5.5 RFC 7208 гласит:
Если при поиске PTR RR возникает ошибка DNS, то этот механизм не работает. Если при поиске A RR возникает ошибка DNS, то это доменное имя пропускается, и поиск продолжается.
Из-за этого следующая запись может оцениваться как fail = «явно не авторизован!» при возникновении ошибки DNS:
v=spf1 ptr -all
Принимая во внимание, что для других механизмов ошибка DNS будет обозначаться с помощью tempfail результат, позволяющий повторить проверку:
v=spf1 mx -all
Для меня это основная проблема сptr:Результатом такой записи может быть окончательная отрицательная авторизация, даже если запрос только что столкнулся с некоторым тайм-аутом DNS.
Тем не менее, поскольку RFC требует («ДОЛЖЕН» ), чтобы ptrподдерживалась совместимая реализация, и что он только не поощряет его использование, («НЕ ДОЛЖЕН» )], использование ptrпо-прежнему возможно и может быть приемлемым после рассмотрения компромиссов.