Route 53-SPF 레코드를 TXT 레코드로 복제해야합니까?

Amazon Route 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"

SPFRR 유형이 새로운 표준 (원하는 SPF 동작의 맥락 에서) 인 것이 실제로 올바르지 않습니다 . SPF 사양 의 실험 단계 에는 새로운 레코드 유형이 할당되었지만 마이그레이션 경로가 명확하지 않아 포기되었습니다.

SPF 사양 의 현재 버전은 구체적으로 다음과 같습니다.

SPF 레코드는 반드시 DNS TXT (유형 16) 리소스 레코드 (RR) [RFC1035] 로만 게시되어야 합니다 . 레코드의 문자 내용은 [US-ASCII]로 인코딩됩니다. 대체 DNS RR 유형의 사용은 SPF의 실험 단계에서 지원되었지만 중단되었습니다.

SPF가 처음 개발 된 2003 년에
새로운 DNS RR 유형 을 할당 하기위한 요구 사항 이 현재보다 훨씬 엄격했습니다. 또한 새로운 DNS
RR 유형 의 쉬운 배포에 대한 지원 은 DNS 서버 및 프로비저닝
시스템 에 널리 배포되지 않았습니다 . 결과적으로 SPF 개발자는
SPF 레코드에 TXT RR 유형을 사용하는 것이 더 쉽고 실용적이라는 것을 알았습니다 .

SPFbis 실무 그룹은 [RFC4408]에 대한 검토에서 이중 RR 유형 전이 모델에
구현자가 서비스를 제공
하고 확인 해야하는 공통 RR 유형이 없기 때문에 근본적으로 결함이 있다고 결론 지었다 .
이 문제 를 해결하기 위해 많은 대안이 고려 되었지만 궁극적으로 실무 그룹
은 예측 가능한 미래에 SPF RR 유형으로의 상당한 마이그레이션
은 거의 불가능하고이
상호 운용성 문제 를 해결하기위한 최상의 솔루션 은 SPF RR 유형에 대한 지원을 중단하는 것이라고 결론지었습니다.
SPF 버전 1. 자세한 내용은 [RFC6686]의 부록 A를 참조하십시오.

10 년 전 SPF의 초기 구축 환경은 독특합니다.
기존 SPF 레코드를 재사용 하지 않는 SPF에 대한 향후 업데이트가 개발 된 경우 SPF RR 유형을 사용할 수 있습니다. SPF의
구조화 된 데이터에 TXT RR 유형을 사용 하는 것은
미래의 프로토콜 설계자에게 선행 으로 간주되어서는 안됩니다 .
새로운 DNS RR 유형을 사용할 때 설계 고려 사항에 대한 자세한 내용은
[RFC5507] 에서 확인할 수 있습니다 .

참고로, 예에서 발신자 ID 레코드 (다행히 다른 사양 임에도 불구하고 "spf2.0"이라고 함)가 있었으며 해당 레코드 유형에 대한 규칙은 여전히 ​​실험적이며 SPF의 실험 버전 과 일치합니다. spec , 업데이트가 게시되지 않았습니다.

예, 복제하십시오. SPF 검사기의 비율이 실제로 레코드 유형에 대한 현재 표준을 지원하는 비율을 알지 못하지만 야생 추측을한다면 검사기의 10 %가 SPF기록을 보지 않을 것 TXT입니다.