Маршрут 53 - Должен ли я дублировать свои записи SPF как записи TXT?

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 запись должна быть опубликована в виде TXT DNS (тип 16) запись ресурса (RR) [RFC1035] только . Содержимое символов записи кодируется как [US-ASCII]. Использование альтернативных типов DNS RR поддерживалось на экспериментальной стадии SPF, но было прекращено.

В 2003 году, когда SPF впервые разрабатывался, требования для
назначения нового типа DNS RR были значительно более строгими, чем сейчас. Кроме того, поддержка простого развертывания новых
типов DNS RR не была широко развернута на DNS-серверах и в
системах обеспечения . В результате разработчики SPF обнаружили, что
для записей SPF проще и практичнее использовать тип TXT RR.

В своем обзоре [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. spec , обновления не опубликованы.

Да, продублируйте их; Я не знаю, какое соотношение SPF-контроллеров на самом деле поддерживает текущий стандарт для типа записи, но если бы я сделал дикое предположение, я бы поспорил, что, вероятно, 10% контролеров не будут смотреть только на SPFзапись TXT.