Маршрут 53 - я должен копировать свои записи SPF как записи TXT?
Маршрут Amazon 53 поддержки и "Записи SPF" и "Записи TXT". Большая часть документации, которую я прочитал, говорит мне перечислять свою Запись SPF как Запись TXT. Я понимаю, что Запись SPF является более новым стандартом. Это поэтому корректно для меня для дублирования моих Записей 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 пришла к выводу, что его модель перехода типа двойного 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 .