Giải pháp cho giới hạn thuật ngữ tương tác DNS tối đa vượt quá trong bản ghi SPF?

Là nhà cung cấp dịch vụ lưu trữ, chúng tôi gửi email thay mặt cho khách hàng của mình, vì vậy chúng tôi giúp họ thiết lập các bản ghi email DKIM và SPF trong DNS của họ để có được khả năng gửi email vừa phải. Chúng tôi đã khuyên họ sử dụng http://mail-tester.com để kiểm tra xem họ có bỏ sót điều gì không và tôi rất thích công cụ này.

Một vấn đề chúng tôi đã gặp phải một vài lần và tôi không chắc chắn, đó là "giới hạn" DNS trên bản ghi SPF dựa trên tên miền. Vì vậy, nếu bạn có điều này:

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

Bạn sẽ nhận được

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

Thích như vậy:

Tôi có một số câu hỏi về điều này.

1. Tôi đếm sáu tên miền ở đây, không phải 10, vậy tại sao nó lại nhấn "mười" yêu cầu DNS ở đây? Đã trả lời ở đây

2. Đây có phải là 10 thuật ngữ tương tác DNS giới hạn cảnh báo hoặc lỗi thực sự không? vd: chúng ta có nên quan tâm không? Nó đang cằn nhằn khách hàng một chút và họ gửi email cho chúng tôi để được hỗ trợ. Đã trả lời ở đây

3. Có phải 10 thuật ngữ tương tác DNS này là một vấn đề thực sự trên web ngày nay? Như bạn có thể thấy, khách hàng này có rất nhiều dịch vụ gửi email cho họ và tất cả đều hợp pháp. Có lẽ giới hạn DNS này đã được đặt ra vào năm 2000 khi ủy thác các dịch vụ email như thế này không phổ biến?

Có, chúng tôi có thể khiến khách hàng của mình thay đổi bao gồm thành IP trong bản ghi SPF nhưng điều đó khiến chúng tôi bị ràng buộc nếu chúng tôi thay đổi IP, một loạt các công cụ của khách hàng sẽ bị phá vỡ. Thực sự không muốn làm điều đó ..

Có cách giải quyết nào cho việc này?

1. Hầu hết đã được trả lời, xin vui lòng lưu ý bao gồm Google theo cách này là sai - bạn muốn sử dụng _spf.google.comhoặc chịu một hình phạt cho chuyển hướng:

   ○ → 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"
   

Việc tra cứu đó sẽ tự tiêu thụ 5/10 - 4/10 vẫn hút nhưng giảm 20%.

2. Nó sẽ dừng xử lý và trả về một lỗi vĩnh viễn - tùy thuộc vào động cơ sử dụng SPF để quyết định cách nó muốn xử lý lỗi vĩnh viễn.

3. Có - không có giới hạn xử lý, các cơ chế SPF có thể được sử dụng làm bộ khuếch đại DoS chống lại bên thứ ba hoặc bên thứ hai.

Như một giải pháp thay thế, email có thể đến từ một tên miền phụ của tài sản chính - community.largecorporation.comchẳng hạn.

1. Giả sử rằng các khoản dự phòng (như nhiều tài liệu tham khảo _spf.google.comvà các hồ sơ mà nó đề cập đến) chỉ được tính một lần, tôi đếm 17 lần tra cứu từ điểm bạn đã tra cứu hồ sơ ban đầu. (Xem bên dưới.)

2. Nó từ chối tra cứu tất cả các hồ sơ cần thiết để đánh giá bản ghi SPF của bạn vì nó sẽ là "quá nhiều công việc". Có lẽ điều này có nghĩa là nó sẽ đối xử với miền của bạn như thể nó không có bản ghi SPF (hoặc có thể từ chối nó). Thông số kỹ thuật nói rằng điều này dẫn đến permerror , khiến nó khá mở để người nhận quyết định phải làm gì .

3. Tôi nghĩ rằng lạm dụng đã tăng lên chứ không phải xuống, nói chung. Giới hạn này dường như có nghĩa là ngăn chặn các miền người gửi lạm dụng có thể có thể áp đảo người nhận bằng chuỗi SPF khổng lồ, có khả năng dẫn đến DoS.

Tôi nghĩ rằng trong khi thuê ngoài email là phổ biến, thì thực tế không phổ biến để thuê ngoài email đến sáu nhà cung cấp khác nhau. Bạn sẽ phải tối ưu hóa bản ghi SPF bằng cách nào đó.
(Đối với một điều, tham chiếu đến aspmx.googlemail.comcó vẻ lãng phí vì ngay lập tức chỉ chuyển hướng đến một tên khác.)

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

Vì câu trả lời được chấp nhận cho một trong những câu hỏi được liên kết đã rõ ràng, nhiều công cụ cơ bản cho các hệ thống UNIX thực sự thực thi giới hạn này (mặc dù không hoàn toàn giống nhau), do đó, bất kỳ triển khai SPF nào sử dụng chúng - gần như hoàn toàn trên UNIX - cũng sẽ thực thi những giới hạn đó. Các hệ thống Windows là một luật đối với chính chúng và tôi không thể làm sáng tỏ chúng.

Cách giải quyết là có một công việc định kỳ để đánh giá chuỗi các bản ghi SPF thuê ngoài của bạn, thể hiện tất cả chúng dưới dạng các chuỗi mạng ipv4 và ipv6, và biến nó thành bản ghi của bạn. Đừng quên -all.

Trong trường hợp của bạn, bạn muốn khách hàng có thể xuất bản bản ghi SPF mà sau đó họ không cần phải duy trì. Một khả năng sẽ là mỗi khách hàng xuất bản một bản ghi có chứa redirect=spf.client1.jeffs-company.example, và sau đó bạn sẽ thực hiện các công việc duy trì danh sách các netblocks tại jeffs-company.example.

Có lẽ giới hạn DNS này đã được đặt ra vào năm 2000 khi ủy thác các dịch vụ email như thế này không phổ biến?

Giới hạn này khiến cho việc thuê ngoài email của bạn thành sáu hoặc bảy hoạt động lớn trở nên khó khăn; nhưng có thể tranh cãi nếu bạn đang làm điều đó vì tất cả các mục đích thực tế đã mất quyền kiểm soát email của bạn.

Một ngày nào đó, một ngày nào đó, một số lập trình viên hợp đồng phụ có sự tồn tại mà bạn hoàn toàn không biết và người mà bạn không kiểm soát sẽ đặt sai dấu chấm phẩy, và một tấn email không có thật sẽ được gửi với SPF của bạn. Kiểm soát hoàn toàn email của bạn yêu cầu toàn quyền kiểm soát cơ sở hạ tầng email của bạn và điều đó theo ý kiến ​​của tôi hoàn toàn không phù hợp với việc thuê ngoài đó.