SPF 레코드에서 최대 DNS 대화 형 용어 제한에 대한 대안이 초과 되었습니까?

호스팅 제공 업체로서 고객을 대신하여 이메일을 보내므로 DNS에서 DKIM 및 SPF 이메일 레코드를 설정하여 이메일을 제대로 전달할 수 있습니다. 우리는 그들에게 http://mail-tester.com 을 사용 하여 아무것도 놓치지 않았 음을 테스트 하도록 조언하고 있으며, 나는이 도구를 많이 좋아합니다.

우리가 몇 번이나 겪어 왔지만 확실하지 않은 한 가지 문제는 도메인 이름을 기반으로 한 SPF 레코드의 DNS "제한"입니다. 당신이 이것을 가지고 있다면 :

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

당신은 얻을 것이다

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

이렇게 :

이것에 대해 몇 가지 질문이 있습니다.

1. 여기에는 10 개가 아닌 6 개의 도메인 이름이 포함되어 있는데 왜 여기에서 10 개의 DNS 요청이 발생합니까? 여기에 답변

2. 이 10 개의 DNS 대화 형 용어가 경고 또는 실제 오류를 제한 합니까? 예를 들어 관심을 가져야합니까? 그것은 우리 고객들에게 약간 잔소리를하며 지원을 위해 우리에게 이메일을 보냅니다. 여기에 답변

3. 이 10 개의 대화 형 대화식 용어가 오늘날 웹에서 실제로 문제가 되는가? 보시다시피이 고객은 많은 서비스를 통해 이메일을 발송하며 모두 합법적입니다. 아마도이 DNS 제한은 2000 년에 이와 같은 이메일 서비스 위임이 일반적이지 않은 때에 설정 되었습니까?

예, 고객이 SPF 레코드에서 IP에 대한 포함을 변경하도록 할 수는 있지만 IP를 변경하면 고객을 묶을 수 있습니다. 정말하고 싶지 않아 ..

이에 대한 해결 방법은 무엇입니까?

1. 대부분 이미 답변을 받았으므로 Google을 포함 하여이 방법 이 잘못_spf.google.com 되었습니다. 리디렉션 에 사용 하거나 페널티를 원합니다 .

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

이 조회는 자체적으로 5/10을 소비합니다. 4/10은 여전히 ​​빨라지지만 20 %는 줄어 듭니다.

2. 처리 를 중지하고 영구 오류를 반환합니다 . SPF를 사용하여 영구 오류를 처리 할 방법을 결정하는 것은 엔진에 달려 있습니다.

3. 예-처리 제한이 없으면 SPF 메커니즘을 타사 또는 타사에 대한 DoS 증폭기 로 사용할 수 있습니다 .

해결 방법으로, 이메일은 community.largecorporation.com예를 들어 주 속성의 하위 도메인에서 올 수 있습니다 .

1. 중복 (예 : 여러 참조 _spf.google.com및 레코드 참조)이 한 번만 계산 된다고 가정하면 이미 초기 레코드를 찾은 시점부터 17 개의 조회를 계산합니다. (아래 참조)

2. SPF 레코드는 "너무 많은 작업"이므로 SPF 레코드를 평가하는 데 필요한 모든 레코드를 찾지 않습니다. 아마도 이것은 도메인이 SPF 레코드가없는 것처럼 (또는 거부 할 수있는) 도메인을 취급한다는 것을 의미합니다. 이 사양은 이로 인해 permerror 가 발생 하므로 수신자가 무엇을해야할지 결정을 내릴 수 있도록 합니다.

3. 나는 학대가 일반적으로 다운되기보다는 오히려 일어나고 있다고 생각합니다. 이 제한은 수신자를 엄청나게 큰 SPF 체인으로 수신자를 압도하여 DoS로 이어질 수있는 악의적 인 발신자 도메인을 막기위한 것으로 보입니다.

이메일을 아웃소싱하는 것이 일반적이지만 이메일을 6 개의 다른 공급자에게 아웃소싱하는 것은 일반적이지 않습니다. 어떻게 든 SPF 레코드를 최적화해야합니다.
(즉, 참조 aspmx.googlemail.com는 즉시 다른 이름으로 리디렉션되기 때문에 참조가 낭비되는 것처럼 보입니다.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

으로 링크 된 질문 중 하나에 허용 대답은 UNIX에 거의 모든입니다 - 명확하게, UNIX 시스템을위한 기본 도구의 대부분은 실제로이 제한 (아니지만 모두 정확히 같은 방식으로) 어떤 SPF 구현하는, 그래서 그들을 사용을 강제 할 -이러한 제한도 시행합니다. Windows 시스템은 그 자체로 법이며, 나는 그 시스템을 밝힐 수 없습니다.

해결 방법은 아웃소싱 된 SPF 레코드 체인을 평가하고 모든 레코드를 ipv4 및 ipv6 넷 블록으로 표시하고이를 레코드로 만드는 크론 작업을하는 것입니다. 를 잊지 마십시오 -all.

귀하의 경우 고객이 유지 관리 할 필요가없는 SPF 레코드를 게시 할 수 있기를 원합니다. 하나의 가능성은 각 고객 redirect=spf.client1.jeffs-company.example에게을 포함하는 레코드를 게시하게하고 네트 블록 목록을 유지 관리하는 합법적 인 작업을 수행하는 것 jeffs-company.example입니다.

아마도이 DNS 제한은 2000 년에 이와 같은 이메일 서비스를 위임하는 것이 일반적이지 않은 때에 설정 되었습니까?

이 제한으로 인해 이메일을 6 ~ 7 개의 대규모 작업에 아웃소싱하기가 어렵습니다. 그러나 당신이하고있는 모든 일을 위해 어쨌든 당신의 이메일에 대한 통제력을 상실했을 것입니다.

어딘가에, 당신이 완전히 알지 못하고 당신이 통제 할 수없는 사람의 하청 계약 프로그래머는 세미콜론을 잘못 놓을 것이고, 가짜 전자 메일이 SPF 불명예와 함께 정사각형으로 전송됩니다. 귀하의 이메일을 완전히 제어하려면 귀하의 이메일 인프라를 완전히 제어해야하며, 이는 저의 아웃소싱과 완전히 일치하지 않습니다.

이러한 문제를 해결하는 또 다른 방법은 SPF 설정을 확인하는 데 정확히 어떤 소프트웨어가 사용되는지 확인하는 것입니다. 필자의 경우 cluebringer / PolicyD이며 결국 사용 Mail::SPF::Server되며 하드 코딩 된 한계를 완화 시키는 인수 를 허용 합니다. 문제는 cluebringer 자체 가 현재 이러한 주장을 완화하는 것을 지원하지 않지만 향후 변경 될 수 있으며 서비스 제공 업체에 설정을 완화 할 수있는 가능성에 대해 간단히 알릴 수 있다는 것입니다.

그들이 그렇게하기로 결정했다면 물론 통제 할 수는 없지만 적어도 기회입니다.