다른 TXT 레코드를 포함한 SPF 크기

다른 TXT 레코드를 포함한 SPF 크기

그만큼SPF 사양말한다:

특정 도메인 이름에 대해 게시된 SPF 레코드는 쿼리 결과가 512옥텟 내에 들어갈 수 있을 만큼 작게 유지되어야 합니다. 그렇지 않으면 DNS 프로토콜 제한을 초과할 가능성이 있습니다.

TXT 형식의 쿼리에 대한 응답 크기를 계산할 때 도메인 이름에 게시된 다른 TXT 레코드를 고려해야 합니다.

또한 최신 DNS 사양은 더 큰 UDP 응답을 허용하지만(제한 이유는 SPF 사양에서 TCP를 통한 DNS에 의존해서는 안 됨을 의미함) 실제로 "SHOULD"를 재정의하지 않는 것 같습니다. .

문제는 너무 많은 조직에서 확인 목적으로 동일한 도메인에 TXT 레코드(예 facebook-domain-verification: google-site-verification, atlassian-domain-verification, adobe-sign-verification, 등)가 필요하며 전체 TXT RRset의 크기를 512바이트를 훨씬 넘게 빠르게 늘릴 수 있다는 것입니다.

대부분의 대규모 조직이 이를 준수하는 것처럼 보이지만, 다음과 같은 몇 가지 사항을 준수해야 합니다.

% dig +noall +stats netflix.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 593

% dig +noall +stats linkedin.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 632

% dig +noall +stats twitter.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 642

% dig +noall +stats microsoft.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 1459

(다음과 같은 명령을 실행하면 잠재적인 잘림 현상을 확인할 수 있습니다 dig +notcp +noedns +ignore microsoft.com TXT.)

저는 6개월 동안 어려움을 겪었고 이제 512바이트를 훨씬 넘는 새로운 공급업체에 대한 또 다른 확인 레코드를 추가해야 합니다. 나는 SPF 기록을 통합하기 위해 최선을 다했으며 기존 확인 기록을 삭제할 수 없도록 조치했습니다.

여기서 무엇을 해야 합니까? 인증기록을 가질 수는 없지만 SPF 스펙을 무시하고 싶지는 않습니다. 즉, Microsoft는 이를 무시하고 있는 것으로 보이며 메일이 거부될 것이라고는 생각하지 않습니다.

답변1

SPF 사양을 다시 읽은 후 TXT RRset 크기에 대한 우려는 클라이언트가 다음과 같은 경우 DNS 응답이 잘릴 수 있다는 것입니다.둘 다EDNS를 지원하지 않습니다그리고클라이언트는 TCP를 통한 DNS를 지원하지 않습니다. TCP를 통한 DNS는 항상 DNS의 필수 부분이었으며, 주의할 점은 손상된 DNS와 관련이 있는 것 같습니다. (공평하게 말하자면, 특히 과거에는 DNS over TCP가 손상된 곳이 많이 있었습니다.)

그러나 나는 내 DNS 서버가 TCP를 통해 액세스할 수 있다는 것을 알고 있으며, 다른 사람들이 적극적으로 망가진 DNS보다는 그들이 (상대적으로) 새로운 DNS 사양을 지원하는지 확인하는 것에 훨씬 덜 관심이 있습니다.

그래서 대답은 내가 가진 것 같습니다."[해당] 항목을 무시하는 타당한 이유와 [및] 전체 의미가 [이해되었으며] 신중하게 평가되었습니다.".

관련 정보