Cả libspf2(C) và Mail::SPF::Query(perl, được sử dụng trong sendmail-spf-milter ) đều thực hiện giới hạn 10 cơ chế gây DNS , nhưng cơ chế sau không (AFAICT) áp dụng giới hạn MX hoặc PTR. libspf2giới hạn mỗi mx và ptr đến 10 cũng có.
Mail::SPF(perl) có giới hạn 10 cơ chế gây DNS và giới hạn 10 lần tra cứu trên mỗi cơ chế, trên mỗi MX và mỗi PTR. (Hai gói perl là phổ biến, mặc dù không theo mặc định, được sử dụng trong MIMEDefang .)
pyspfcó giới hạn 10 trên tất cả: "tra cứu", MX, PTR, CNAME; nhưng nó rõ ràng nhân MAX_LOOKUPS lên 4 trong khi hoạt động. Trừ khi ở chế độ "nghiêm ngặt", nó cũng nhân MAX_MX và MAX_PTR với 4.
Tôi không thể nhận xét về các triển khai thương mại / độc quyền, nhưng ở trên (ngoại trừ pyspf) rõ ràng thực hiện giới hạn trên của 10 cơ chế kích hoạt DNS (nhiều hơn ở bên dưới), cho hoặc nhận, mặc dù trong hầu hết các trường hợp, nó có thể bị ghi đè khi chạy thời gian.
Trong trường hợp cụ thể của bạn, bạn đã đúng, bao gồm 12 bao gồm và vượt quá giới hạn 10. Tôi hy vọng hầu hết các phần mềm SPF sẽ trả về "PermError", tuy nhiên , các lỗi sẽ chỉ ảnh hưởng đến (các) nhà cung cấp cuối cùng vì số lượng sẽ được tính dưới dạng tổng cộng đang chạy: Các cơ chế SPF được đánh giá từ trái sang phải và các kiểm tra sẽ "xuất hiện sớm" trên đường chuyền, do đó, nó phụ thuộc vào vị trí trong trình tự máy chủ gửi xuất hiện.
Các khoảng cách này là sử dụng cơ chế mà không làm kích hoạt tra cứu DNS, ví dụ ip4và ip6, và sau đó sử dụng mxnếu có thể như đem đến cho bạn lên đến 10 tên hơn nữa, mỗi trong số đó có thể có nhiều hơn một IP.
Do SPF dẫn đến các yêu cầu DNS tùy ý với khả năng mở rộng theo cấp số nhân, nên nó có thể dễ dàng bị khai thác cho các cuộc tấn công khuếch đại / DOS. Nó đã cố tình giới hạn thấp để ngăn chặn điều này: nó không mở rộng quy mô theo cách bạn muốn.
10 cơ chế (cơ chế nghiêm ngặt + công cụ sửa đổi "chuyển hướng") gây ra tra cứu DNS không hoàn toàn giống với 10 tra cứu DNS. Ngay cả "tra cứu DNS" cũng được mở để giải thích, bạn không biết trước có bao nhiêu tra cứu rời rạc được yêu cầu và bạn không biết có bao nhiêu tra cứu rời rạc mà trình giải quyết đệ quy của bạn có thể cần thực hiện (xem bên dưới).
RFC 4408 §10.1 :
Việc triển khai SPF PHẢI giới hạn số lượng cơ chế và công cụ sửa đổi thực hiện tra cứu DNS tối đa 10 lần cho mỗi lần kiểm tra SPF, bao gồm mọi tra cứu do sử dụng cơ chế "bao gồm" hoặc công cụ sửa đổi "chuyển hướng". Nếu vượt quá số này trong khi kiểm tra, PermError PHẢI được trả lại. Các cơ chế "bao gồm", "a", "mx", "ptr" và "tồn tại" cũng như công cụ sửa đổi "chuyển hướng" được tính theo giới hạn này. Các cơ chế "tất cả", "ip4" và "ip6" không yêu cầu tra cứu DNS và do đó không được tính vào giới hạn này.
[...]
Khi đánh giá các cơ chế "mx" và "ptr" hoặc macro% {p}, PHẢI có giới hạn không quá 10 MX hoặc PTR RR được tra cứu và kiểm tra.
Vì vậy, bạn có thể sử dụng tối đa 10 cơ chế / công cụ sửa đổi để kích hoạt tra cứu DNS. (Từ ngữ ở đây rất kém: dường như chỉ nêu giới hạn trên của giới hạn, việc triển khai xác nhận có thể có giới hạn là 2.)
§5.4 cho cơ chế mx và §5.5 cho cơ chế ptr, mỗi cơ chế có giới hạn 10 lần tra cứu loại tên đó và chỉ áp dụng cho việc xử lý cơ chế đó, ví dụ:
Để ngăn chặn các cuộc tấn công từ chối dịch vụ (DoS), hơn 10 tên MX KHÔNG được tra cứu trong quá trình đánh giá cơ chế "mx" (xem Phần 10).
tức là bạn có thể có 10 cơ chế mx, với tối đa 10 tên MX, do đó, mỗi cơ chế có thể gây ra 20 hoạt động DNS (10 MX + 10 mỗi lần tra cứu DNS) với tổng số 200. Tương tự như ptr hoặc % {p} , bạn có thể tra cứu 10 cơ chế ptr , do đó các PTR 10 x 10, mỗi PTR cũng yêu cầu tra cứu A, tổng cộng là 200.
Đây chính xác là những gì bộ kiểm tra 2009.10 kiểm tra, xem các bài kiểm tra " Giới hạn xử lý ".
Không có giới hạn trên được nêu rõ ràng trên tổng số hoạt động tra cứu DNS của khách hàng trên mỗi lần kiểm tra SPF, tôi tính toán nó là ngầm định 210, cho hoặc nhận. Ngoài ra còn có một đề xuất để giới hạn khối lượng dữ liệu DNS trên mỗi lần kiểm tra SPF, mặc dù không có giới hạn thực tế nào được đề xuất. Bạn có thể có được ước tính sơ bộ vì các bản ghi SPF bị giới hạn ở 450 byte (được chia sẻ đáng buồn với tất cả các bản ghi TXT khác), nhưng tổng số có thể vượt quá 100kiB nếu bạn hào phóng. Cả hai giá trị này rõ ràng mở cho sự lạm dụng tiềm năng như một cuộc tấn công khuếch đại, đó chính xác là những gì §10.1 nói rằng bạn cần tránh.
Bằng chứng thực nghiệm cho thấy tổng cộng 10 cơ chế tra cứu thường được thực hiện trong hồ sơ (kiểm tra SPF cho microsoft.com, những người dường như đã đi đến một số độ dài để giữ cho chính xác đến 10). Thật khó để thu thập bằng chứng về sự thất bại của quá nhiều tra cứu vì mã lỗi được ủy quyền chỉ đơn giản là "PermError", bao gồm tất cả các vấn đề ( báo cáo DMARC có thể giúp giải quyết vấn đề đó).
Câu hỏi thường gặp về OpenSPF duy trì giới hạn của tổng số "10 lần tra cứu DNS", thay vì "10 cơ chế hoặc chuyển hướng gây ra DNS" chính xác hơn. Câu hỏi thường gặp này được cho là sai vì nó thực sự nói:
Vì có giới hạn 10 lần tra cứu DNS trên mỗi bản ghi SPF, chỉ định địa chỉ IP [...]
không đồng ý với RFC, áp đặt các giới hạn cho hoạt động "kiểm tra SPF", không giới hạn các hoạt động tra cứu DNS theo cách này và nêu rõ bản ghi SPF là một văn bản DNS RR duy nhất. Câu hỏi thường gặp sẽ ngụ ý rằng bạn khởi động lại số đếm khi bạn xử lý "bao gồm" vì đó là bản ghi SPF mới. Thật là một mớ hỗn độn.
Tra cứu DNS
"Tra cứu DNS" là gì? Là người dùng . Tôi sẽ xem xét " ping www.microsoft.com" liên quan đến một "tra cứu" DNS duy nhất: có một tên mà tôi dự kiến sẽ biến thành một IP. Đơn giản? Đáng buồn là không.
Là một quản trị viên, tôi biết rằng www.microsoft.com có thể không phải là một bản ghi đơn giản với một IP duy nhất, nó có thể là một CNAME mà đến lượt nó cần một tra cứu riêng biệt khác để có được một bản ghi A, mặc dù bộ giải quyết ngược dòng của tôi có thể sẽ thực hiện thay vì trình giải quyết trên máy tính để bàn của tôi. Hôm nay, đối với tôi, www.microsoft.com là một chuỗi gồm 3 CNAME cuối cùng kết thúc dưới dạng bản ghi A trên akamaiedge.net, đó là (ít nhất) 4 hoạt động truy vấn DNS cho ai đó. SPF có thể thấy CNAME với cơ chế "ptr", bản ghi MX không nên là CNAME.
Cuối cùng, với tư cách là người quản trị DNS, tôi biết rằng việc trả lời (gần như) bất kỳ câu hỏi nào liên quan đến nhiều hoạt động DNS riêng lẻ, câu hỏi riêng lẻ và giao dịch trả lời (datagram UDP) - giả sử bộ đệm trống, trình giải quyết đệ quy cần bắt đầu từ gốc DNS và hoạt động theo cách của nó xuống: . → com→ microsoft.com→ www.microsoft.comyêu cầu các loại hồ sơ cụ thể (NS, A, v.v.) theo yêu cầu và xử lý các CNAME. Bạn có thể thấy điều này trong thực tế với dig +trace www.microsoft.com, mặc dù bạn có thể sẽ không nhận được câu trả lời chính xác tương tự do thủ thuật định vị địa lý (ví dụ ở đây ). .
Vì vậy, SPF coi như là một tra cứu? Nó thực sự gần nhất với quan điểm của quản trị viên , nó cần phải biết các chi tiết cụ thể của từng loại truy vấn DNS (nhưng không phải là điểm mà nó thực sự cần phải đếm các datagram hoặc kết nối DNS riêng lẻ).