255자 제한을 보고하는 DNS 편집기가 반드시 귀하의 SPF 정책은 여러 레코드가 되어야 합니다. DNS TXT 형식은 하나의 리소스 레코드 내에 여러 문자열을 허용합니다. SPF 해당 콘텐츠를 하나의 연속 값으로 처리합니다. 운영상 과제는 정책과 해당 DNS 응답을 관리 가능하게 유지하면서 의도한 텍스트를 보존하는 것입니다.
세 가지 다른 한도를 분리하세요.
첫째, 개별 TXT 문자열은 255옥텟으로 제한됩니다. SPF 콘텐츠는 ASCII이므로 일반 문자는 각각 한 옥텟을 차지합니다. 싱글 TXT 레코드 그러한 문자열을 두 개 이상 포함할 수 있습니다. RFC 7208 섹션 3.3에서는 해당 표현을 명시적으로 허용합니다.
둘째, DNS 응답에는 크기가 있습니다. 여기에는 SPF 텍스트뿐만 아니라 해당 소유자 이름으로 반환된 이름, 레코드 메타데이터 및 기타 TXT 레코드가 포함됩니다. 섹션 3.4에서는 SPF DNS 응답을 레거시 512옥텟 UDP 처리에 맞게 작게 유지할 것을 권장합니다. 이는 SPF 의 범용 최대 512자가 아닌 호환성 권장 사항입니다. 최신 DNS 전송 기능이 모든 확인자, 방화벽 또는 잘림 문제를 제거하지는 않습니다.
셋째, SPF 평가에는 리소스 제한이 있습니다. 텍스트를 문자열로 분할해도 중첩된 포함 처리 또는 10개의 조회 원인 용어 제한이 줄어들지 않습니다. 짧은 정책은 평가 제한을 초과할 수 있습니다. 더 긴 명시적 주소 목록은 그렇지 않을 수 있습니다. 구문, DNS 전송 및 평가 비용을 독립적으로 평가합니다.
의도적으로 공간을 보존하십시오.
SPF 공백을 삽입하지 않고 문자열을 연결합니다. 영역 파일 표현에서, "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" 첫 번째 문자열이 공백으로 끝나기 때문에 의도된 연속 정책을 생성합니다. 해당 공백을 제거하면 인접한 두 메커니즘이 잘못된 텍스트로 결합됩니다.
위의 문서 전용 주소는 예시입니다. 귀하의 도메인에 대해 승인된 값이 아닙니다. 따옴표는 영역 파일 표시 구문입니다. 호스팅된 DNS 편집기에 입력할지 여부는 해당 공급자의 문서화된 인터페이스에 따라 다릅니다. 일부 편집기는 긴 값을 자동으로 분할하는 반면 다른 편집기는 별도의 문자열 필드를 표시합니다. 편집기의 디스플레이가 와이어 형식과 일치한다고 가정하는 대신 제공된 답변을 확인하십시오.
처음부터 두 번째 TXT 리소스 레코드를 생성하지 마세요. v=spf1 남은 것을 담기 위해. 여러 개 선택됨 SPF 레코드 생산하다 permerror. 반대로, 진단 도구에는 여러 TXT 답변이 표시되므로 관련되지 않은 TXT 확인 레코드를 삭제하지 마십시오.
게시된 값 검사
신뢰할 수 있는 TXT 응답을 캡처하고 각 리소스 레코드에 속하는 문자열을 식별합니다. 하나의 레코드 내의 문자열만 연결하여 SPF 값을 재구성합니다. 모든 분할 경계의 공백을 확인하고 하나의 버전 표시, 유효한 메커니즘 및 의도된 최종 명령문이 있는지 확인하세요.
그런 다음 중요한 네트워크에서 재귀적인 DNS 응답을 테스트하세요. 응답이 잘리거나 확인이 실패하는 경우 임의 메커니즘을 삭제하는 대신 DNS 전송 및 공급자 구성을 조사하십시오. DNSSEC 더 넓은 답변 세트는 응답 크기에 영향을 미칠 수 있습니다. 간단한 문자 수는 전체 패킷 크기 테스트가 아닙니다.
영리한 패킹보다 정책 정리를 선호합니다.
성장하는 정책은 종종 축적된 서비스를 나타냅니다. 더 이상 사용되지 않는 검토에는 복잡성이 증가하기 전에 불필요하게 광범위한 메커니즘과 중복 인증이 포함됩니다. 기록을 단축하거나 재구성하기 위한 목적으로만 현재 IP 주소를 복사하는 대신 적절한 경우 현재 공급자 관리 메커니즘을 유지하십시오. 공급자가 인프라를 변경하면 수동으로 평면화된 주소가 오래될 수 있습니다.
여전히 여러 문자열이 필요한 정책의 경우 게시된 표현과 함께 분할되지 않은 의도된 텍스트를 저장하십시오. 이는 미래의 관리자에게 안정적인 비교 대상을 제공합니다. 무해한 편집기 재형식을 의미론적 정책 변경과 혼동해서는 안 됩니다.
독자 대상 결과 확인
승인된 변경 후에는 표준 인식 평가자를 사용하여 대표 소스와 일치하지 않는 소스를 테스트한 다음 신뢰할 수 있는 실제 수신기 결과를 검사합니다. 재구성된 값, 반응 관찰 및 평가 결과를 기록합니다. 단순히 편집자가 저장을 수락한 경우가 아니라 DNS 표현과 인증 동작이 모두 올바른 경우 문제를 닫습니다.
쿼리 답변 재구성
다음은 우리가 실행한 쿼리가 아닌 종합적인 진단 연습입니다. 기록 출판하다. 실제 SPF 소유자 이름과 검증된 신뢰할 수 있는 이름으로 대체하세요. 네임서버 이러한 읽기 전용 명령을 사용하기 전에. 이러한 템플릿은 예약된 예제 이름을 사용합니다.
dig @ ns1.example.net example.com TXT +noall +답변 dig example.com TXT +noall +답변첫 번째 명령은 지정된 권한 있는 서버에 요청합니다. 두 번째는 해당 시스템에 구성된 확인자를 사용합니다. 하나의 재귀 확인자의 답변은 모든 수신자가 동일한 데이터를 본다는 것을 증명하지 않습니다. 필요한 경우 @server-address를 사용하여 명시적으로 알려진 다른 확인자를 쿼리합니다.
종합적인 답변:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "재구성된 값:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -all첫 번째 문자열에 후행 공백이 없으면 경계는 192.0.2.10ip4: 198.51.100.20 이 됩니다. 편집자는 TXT 데이터를 수락할 수 있지만 이로 인해 SPF 정책이 유효해지지는 않습니다. 대조적으로, 각각 v=spf1 로 시작하는 두 개의 별도 응답 레코드는 문자열 분할 솔루션이 아니라 다중 정책 문제입니다.
쿼리된 서버, 소유자 이름, 타임스탬프 및 답변을 저장합니다. 한 번에 하나의 레코드를 재구성하고 이를 의도한 분할되지 않은 정책과 비교한 다음 보낸 사람 권한을 별도로 평가합니다. 이 명령은 DNS 표현을 검사합니다. 완전한 SPF 평가를 실행하지 않습니다. 보다 RFC 7208 섹션 3.3 연결을 위해 섹션 4.6.4 평가 한계에 대해.