Ruta 53 - ¿Debo duplicar mis registros SPF como registros TXT?

Amazon Route 53 es compatible con "SPF Records" y "TXT Records". La mayoría de la documentación que leí me dice que enumere mi registro SPF como un registro TXT. Entiendo que el Registro SPF es un estándar más nuevo. Por lo tanto, ¿es correcto para mí duplicar mis registros SPF para que aparezcan como registros SPF y registros TXT para garantizar la compatibilidad con versiones anteriores y al mismo tiempo seguir el nuevo estándar? No estoy familiarizado con DNS, así que no estoy seguro de si esto podría causar algún problema o si incluso debería molestarme en duplicarlos.

Mis registros son los siguientes:

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

En realidad, no es correcto que el SPFtipo RR sea el estándar más nuevo (en el contexto del comportamiento SPF deseado). La fase experimental de la especificación SPF tenía un nuevo tipo de registro asignado, pero la ruta de migración no estaba clara y desde entonces ha sido abandonada.

La versión actual de la especificación SPF establece específicamente:

Los registros SPF DEBEN publicarse como un Registro de recursos (RR) DNS TXT (tipo 16 ) [RFC1035] solamente . El contenido de caracteres del registro está codificado como [US-ASCII]. El uso de tipos de RR DNS alternativos se admitió en la fase experimental de SPF, pero se suspendió.

En 2003, cuando se desarrolló SPF por primera vez, los requisitos para la
asignación de un nuevo tipo de RR DNS eran considerablemente más estrictos de lo que son ahora. Además, el soporte para una fácil implementación de nuevos
tipos de RR DNS no se implementó ampliamente en los servidores DNS y los
sistemas de aprovisionamiento . Como resultado, los desarrolladores de SPF encontraron más fácil y más
práctico usar el tipo TXT RR para registros SPF.

En su revisión de [RFC4408], el grupo de trabajo SPFbis concluyó que su modelo de transición de tipo RR dual era fundamentalmente defectuoso ya que
no contenía ningún tipo RR común que los implementadores debían cumplir
y que debían verificar. Se consideraron muchas alternativas para resolver
este problema, pero finalmente el grupo de trabajo concluyó que la
migración significativa al tipo SPF RR en el futuro previsible
era muy improbable y que la mejor solución para resolver este
problema de interoperabilidad era abandonar el soporte para el tipo SPF RR
SPF versión 1. Consulte el Apéndice A de [RFC6686] para obtener más información.

Las circunstancias que rodearon el despliegue inicial de SPF hace una década son únicas. Si se desarrollara una actualización futura de SPF que no
reutilizara los registros SPF existentes, podría usar el tipo SPF RR. El uso
de SPF del tipo TXT RR para datos estructurados de ninguna manera debe tomarse como
precedente para futuros diseñadores de protocolos. Se
puede encontrar más información sobre las consideraciones de diseño cuando se utilizan nuevos tipos de RR DNS en
[RFC5507].

Como nota al margen, también había un registro de ID de remitente (desafortunadamente denominado "spf2.0" a pesar de ser una especificación diferente) en su ejemplo, las reglas para ese tipo de registro aún son experimentales y coinciden con la versión experimental del SPF especificación , no se han publicado actualizaciones.

Sí, duplícalos; No sé de antemano qué proporción de verificadores SPF realmente admite el estándar actual para el tipo de registro, pero si tuviera que adivinar, apostaría a que probablemente el 10% de los verificadores no mirarán un SPFregistro, solo TXT.