모두 libspf2(C)와 Mail::SPF::Query(에 사용되는 펄, 센드 메일-SPF-산란기의 물고기 수컷은 ) 10의 제한 구현 DNS 유발하는 메커니즘을 하지만, 후자는하지 않습니다 (AFAICT)의 MX 또는 PTR 제한을 적용합니다. mx 와 ptr도libspf2 각각 10으로 제한합니다 .
Mail::SPF(perl)은 DNS를 유발하는 메커니즘 10 개, 메커니즘 당, MX 당 및 PTR 당 10 개로 제한됩니다. (2 개의 perl 패키지는 일반적으로 MIMEDefang 에서 기본적으로 사용되지는 않지만 일반적으로 사용됩니다 .)
pyspf"검색", MX, PTR, CNAME 모두에 대해 10 개의 제한이 있습니다. 그러나 작동 중에 MAX_LOOKUPS에 4를 명시 적으로 곱합니다. "엄격한"모드가 아닌 한 MAX_MX와 MAX_PTR을 4로 곱합니다.
상업 / 독점 구현에 대해서는 언급 할 수 없지만 위의 (제외 pyspf)는 10 개의 DNS 트리거 메커니즘 (아래에서 더 자세히 설명)의 상한을 명확하게 구현하거나 제공하거나 취해야하지만 대부분의 경우 실행시 재정의 될 수 있습니다. 시각.
귀하의 특정 경우에 귀하는 12 포함이며 한계는 10을 초과합니다. 대부분의 SPF 소프트웨어가 "PermError"를 반환 할 것으로 예상 하지만 , 실패는 최종 "포함 된"제공자에게만 영향을 미칩니다. SPF 메커니즘은 왼쪽에서 오른쪽으로 평가 되며 통과시 "초기"검사되므로 전송 서버가 나타나는 순서에 따라 달라집니다.
이 문제를 해결하는 방법은 DNS 조회를 트리거하지 않는 메커니즘 (예 : ip4및 ip6)을 사용 mx하고 가능한 경우 최대 10 개의 추가 이름을 얻을 수있는 방식을 사용하는 것입니다. 각 이름에는 둘 이상의 IP가있을 수 있습니다.
SPF는 잠재적으로 지수 확장이 가능한 임의의 DNS 요청을 생성하므로 DOS / 증폭 공격에 쉽게 악용 될 수 있습니다. 이를 방지하기 위해 의도적으로 낮은 제한이 있습니다. 원하는 방식으로 확장되지 않습니다.
DNS 조회를 일으키는 10 가지 메커니즘 (엄격한 메커니즘 + "리디렉션"수정 자) 은 10 개의 DNS 조회와 정확히 동일하지 않습니다. "DNS 조회"도 해석에 개방적이며, 얼마나 많은 이산 조회가 필요한지 미리 알지 못하며, 재귀 적 리졸버가 수행해야하는 이산 조회가 몇 개인 지 알 수 없습니다 (아래 참조).
RFC 4408 §10.1 :
SPF 구현은 "include"메커니즘 또는 "redirect"수정 자의 사용으로 인한 조회를 포함하여 DNS 조회를 수행하는 메커니즘 및 수정 자의 수를 SPF 확인 당 최대 10 개로 제한해야합니다. 점검 중에이 숫자를 초과하면 PermError가 리턴되어야합니다. "리디렉션"수정 자뿐만 아니라 "include", "a", "mx", "ptr"및 "exists"메커니즘도이 제한에 포함됩니다. "all", "ip4"및 "ip6"메커니즘에는 DNS 조회가 필요하지 않으므로이 제한에 포함되지 않습니다.
[...]
"mx"및 "ptr"메커니즘 또는 % {p} 매크로를 평가할 때는 최대 10 개의 MX 또는 PTR RR을 조회하고 확인해야합니다.
따라서 DNS 조회를 트리거하는 최대 10 개의 메커니즘 / 수정자를 사용할 수 있습니다. (여기서 표현이 잘못되었습니다. 한도의 상한 만 나타내는 것 같습니다. 확인 구현은 한도를 2로 할 수 있습니다.)
§5.4위한 MX의 기구 및 §5.5 PTR의 기구는 각각의 이름이 10 가지의 조회 한계가 있고, 이는 그 메커니즘 만, 예를 들면 처리에 적용
DoS (서비스 거부) 공격을 방지하려면 "mx"메커니즘을 평가하는 동안 10 개가 넘는 MX 이름을 조회해서는 안됩니다 (섹션 10 참조).
즉, 최대 10 개의 MX 이름을 가진 10 개의 mx 메커니즘을 가질 수 있으므로 각각의 총 200 개의 DNS 작업이 20 개의 DNS 작업 (각각 10 MX + 10 개의 DNS 조회)을 유발할 수 있습니다. ptr 또는 % {p} 와 유사 합니다. 10 개의 ptr 메커니즘, 따라서 10x10 PTR을 조회 할 수 있으며 , 각 PTR에는 A 조회, 다시 총 200이 필요합니다.
이것이 바로 2009.10 테스트 스위트가 확인하는 내용입니다. " 프로세스 제한 "테스트를 참조하십시오 .
SPF 검사 당 총 클라이언트 DNS 조회 작업 수 에 대한 명확한 상한은 없으며 암시 적으로 210,주고 받음으로 계산합니다. SPF 검사 당 DNS 데이터의 양을 제한하는 제안도 있지만 실제 제한은 제안되지 않습니다. SPF 레코드가 450 바이트 (다른 모든 TXT 레코드와 슬프게 공유 됨)로 제한되어 있기 때문에 대략적인 추정치를 얻을 수 있지만 관대하다면 총 100kiB를 초과 할 수 있습니다. 이 두 값은 모두 증폭 공격으로서 잠재적 남용에 대해 분명하게 개방되어 있습니다. 이는 정확히 §10.1에서 피해야한다고 말합니다.
경험적 증거에 따르면 총 10 개의 조회 메커니즘이 일반적으로 레코드에 구현되어 있음을 나타냅니다 (정확히 10으로 유지하기 위해 일정 시간이 지난 것으로 보이는 microsoft.com의 SPF 참조). 위임 된 오류 코드는 단순히 "PermError"이므로 모든 방식의 문제를 처리하기 때문에 너무 많은 조회 실패의 증거를 수집하기가 어렵습니다 ( DMARC 보고가 도움이 될 수 있음).
OpenSPF FAQ 는보다 정확한 "10 DNS로 인한 메커니즘 또는 리디렉션"보다는 총 "10 DNS 조회" 의 제한 을 유지합니다 . 이 FAQ는 실제로 다음과 같이 명시되어 있기 때문에 잘못되었습니다.
SPF 레코드 당 10 개의 DNS 조회가 제한되어 있으므로 IP 주소를 지정하면 [...]
"SPF 확인"작업에 제한을 부과하는 RFC와 의견이 일치하지 않으며, 이러한 방식으로 DNS 조회 작업을 제한하지 않으며 SPF 레코드 가 단일 DNS 텍스트 RR임을 명확하게 명시합니다 . FAQ는 새 SPF 레코드 인 "포함"을 처리 할 때 카운트를 다시 시작 함을 의미합니다. 엉망이야
DNS 조회
어쨌든 "DNS 조회"란 무엇입니까? 사용자 로서 . " ping www.microsoft.com"은 단일 DNS "조회"를 포함하는 것으로 간주 합니다. 하나의 IP로 전환 할 것으로 예상되는 이름이 하나 있습니다. 단순한? 안타깝게도
관리자 로서 나는 www.microsoft.com이 단일 IP를 가진 단순한 A 레코드가 아닐 수도 있다는 것을 알고 있습니다. CNAME 일 수도 있습니다. A 레코드를 얻으려면 다른 개별 조회가 필요합니다. 내 바탕 화면의 리졸버보다는. 현재 www.microsoft.com은 3 개의 CNAME 체인으로, akamaiedge.net에서 A 레코드로 끝납니다. 이는 적어도 누군가를위한 4 개의 DNS 쿼리 작업입니다. SPF는 "ptr"메커니즘을 사용하는 CNAME을 볼 수 있지만 MX 레코드는 CNAME이 아니어야합니다.
마지막으로, DNS 관리자 로서 거의 모든 질문에 답하기 위해서는 많은 개별 DNS 작업, 개별 질문 및 답변 트랜잭션 (UDP 데이터 그램)이 포함됩니다. 빈 캐시를 가정 할 때 재귀 해결 프로그램은 DNS 루트에서 시작하여 그 방식대로 작업해야합니다. 아래로 : . → com→ microsoft.com→ www.microsoft.com특정 유형의 레코드 (NS, A 등)를 요구하고 CNAME을 처리합니다. dig +trace www.microsoft.com지리적 위치 정보 (예 : here ) 로 인해 정확히 동일한 답변을 얻지 못할 수도 있지만 이 기능을 사용하여 볼 수 있습니다 . TXT 레코드에 대한 SPF 피기 백과 DNS 응답에 사용되지 않는 512 바이트 제한이 TCP를 통해 쿼리를 다시 시도한다는 의미이므로이 복잡성에는 약간의 차이가 있습니다.
SPF는 조회로 무엇을 고려합니까? 실제로 관리자의 관점에 가장 가까우 므로 각 유형의 DNS 쿼리에 대한 세부 사항을 알고 있어야합니다 (단, 개별 DNS 데이터 그램 또는 연결을 실제로 계산해야하는 시점은 아님).