Amazon Route 53 поддерживает как «Записи SPF», так и «Записи TXT». В большей части документации, которую я читаю, мне предлагается указать мою запись SPF как запись TXT. Я понимаю, что SPF Record - это новый стандарт. Поэтому правильно ли для меня дублировать мои записи SPF, чтобы они были перечислены как записи SPF и TXT, чтобы обеспечить обратную совместимость, а также следовать новому стандарту? Я не знаком с DNS, поэтому не уверен, что это вызовет какие-либо проблемы, или мне даже стоит их дублировать?
Мои записи следующие:
"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"
На самом деле неверно, что SPF Тип RR - это новый стандарт (в контексте желаемого поведения SPF). В экспериментальная фаза спецификации SPF был назначен новый тип записи, но путь миграции был неясен, и с тех пор от нее отказались.
В текущая версия спецификации SPF в частности, говорится:
SPF записи ДОЛЖЕН быть опубликован как запись ресурса DNS TXT (тип 16). (RR) [RFC1035] только. Символьное содержимое записи кодируется как [US-ASCII]. Использование альтернативных типов DNS RR поддерживалось на экспериментальной стадии SPF, но было прекращено.
В 2003 году, когда SPF только разрабатывался, требования к
Назначение нового типа DNS RR было значительно более строгим, чем сейчас. Кроме того, поддержка простого развертывания нового DNS.
Типы RR не получили широкого распространения на DNS-серверах и при инициализации.
системы. В результате разработчикам SPF стало проще и даже больше.
Практично использовать тип TXT RR для записей SPF.В своем обзоре [RFC4408] рабочая группа SPFbis пришла к выводу, что ее модель перехода типа Dual RR была в корне ошибочной, поскольку она
не содержал общего типа RR, который разработчики должны были обслуживать
и требуется проверить. Было рассмотрено множество альтернатив для решения
этот вопрос, но в конечном итоге рабочая группа пришла к выводу, что
значительный переход на тип SPF RR в обозримом будущем
было очень маловероятно, и это лучшее решение для решения этой
проблема взаимодействия заключалась в отказе от поддержки типа SPF RR из
SPF версии 1. Дополнительную информацию см. В Приложении A [RFC6686].Обстоятельства, связанные с первоначальным развертыванием SPF десять лет назад, уникальны. Если будет разработано будущее обновление SPF, которое не
повторно использовать существующие записи SPF, он может использовать тип SPF RR. Использование SPF
типа TXT RR для структурированных данных никоим образом не следует воспринимать как
прецедент для будущих разработчиков протоколов. Дальнейшее обсуждение
рекомендации по проектированию при использовании новых типов DNS RR можно найти в
[RFC5507].
Кстати, в вашем примере также была запись идентификатора отправителя (к сожалению, называемая «spf2.0», несмотря на то, что это другая спецификация), правила для этого типа записи все еще являются экспериментальными и соответствовать экспериментальной версии спецификации SPF, обновлений не публиковалось.
Да, продублируйте их; Я не знаю, какое соотношение проверяющих SPF на самом деле поддерживает текущий стандарт для типа записи, но если бы я сделал дикое предположение, я бы поспорил, что, вероятно, 10% проверяющих не будут смотреть на SPF запись, только TXT.