Sia libspf2(C) che Mail::SPF::Query(perl, usati in sendmail-spf-milter ) implementano un limite di 10 meccanismi che causano DNS , ma quest'ultimo (AFAICT) non applica i limiti MX o PTR. libspf2limita anche ciascuno di mx e ptr a 10.
Mail::SPF(perl) ha un limite di 10 meccanismi che causano DNS e un limite di 10 ricerche per meccanismo, per MX e per PTR. (I due pacchetti perl sono comunemente, sebbene non di default, usati in MIMEDefang .)
pyspfha limiti di 10 su tutti: "ricerche", MX, PTR, CNAME; ma moltiplica esplicitamente MAX_LOOKUPS per 4 durante il funzionamento. A meno che in modalità "rigorosa", moltiplica anche MAX_MX e MAX_PTR per 4.
Non posso commentare implementazioni commerciali / proprietarie, ma quanto sopra (tranne pyspf) implementa chiaramente un limite superiore di 10 meccanismi di innesco DNS (più su quello sotto), dare o prendere, anche se nella maggior parte dei casi può essere ignorato in fase di esecuzione- tempo.
Nel tuo caso specifico hai ragione, è 12 include e supera il limite di 10. Mi aspetterei che la maggior parte dei software SPF restituisca "PermError", tuttavia i guasti influenzeranno solo i fornitori finali "inclusi" perché il conteggio verrà calcolato come totale parziale: i meccanismi SPF vengono valutati da sinistra a destra e i controlli si "anticipano" in un passaggio, quindi dipende da dove appare nella sequenza il server di invio.
Il modo per aggirare questo è di usare meccanismi che non attivano le ricerche DNS, ad esempio ip4e ip6, e quindi utilizzare mxse possibile in quanto ti porta fino a 10 altri nomi, ognuno dei quali può avere più di un IP.
Poiché SPF genera richieste DNS arbitrarie con ridimensionamento potenzialmente esponenziale, potrebbe essere facilmente sfruttato per attacchi DOS / amplificazione. Ha deliberatamente dei limiti bassi per evitarlo: non si ridimensiona nel modo desiderato.
10 meccanismi (rigorosamente meccanismi + il modificatore "reindirizzamento") che causano ricerche DNS non sono esattamente la stessa cosa di 10 ricerche DNS. Anche le "ricerche DNS" sono suscettibili di interpretazione, non sai in anticipo quante ricerche discrete sono necessarie e non sai quante ricerche discrete potrebbe essere necessario per il tuo risolutore ricorsivo (vedi sotto).
RFC 4408 §10.1 :
Le implementazioni SPF DEVONO limitare il numero di meccanismi e modificatori che eseguono ricerche DNS a un massimo di 10 per controllo SPF, comprese eventuali ricerche causate dall'uso del meccanismo "include" o del modificatore "reindirizzamento". Se questo numero viene superato durante un controllo, DEVE essere restituito un PermError. I meccanismi "include", "a", "mx", "ptr" ed "esiste" così come il modificatore "reindirizzamento" contano per questo limite. I meccanismi "all", "ip4" e "ip6" non richiedono ricerche DNS e pertanto non contano per questo limite.
[...]
Quando si valutano i meccanismi "mx" e "ptr" o la macro% {p}, DEVE esserci un limite di non più di 10 RR MX o PTR cercati e controllati.
Quindi è possibile utilizzare fino a 10 meccanismi / modificatori che attivano le ricerche DNS. (La formulazione qui è scarsa: sembra indicare solo il limite superiore del limite, un'implementazione di conferma potrebbe avere un limite di 2.)
§5.4 per il meccanismo mx e §5.5 per il meccanismo ptr hanno ciascuno un limite di 10 ricerche con quel tipo di nome, e questo vale solo per l'elaborazione di quel meccanismo, ad esempio:
Per prevenire gli attacchi Denial of Service (DoS), NON DEVONO essere cercati più di 10 nomi MX durante la valutazione di un meccanismo "mx" (vedere la Sezione 10).
cioè potresti avere meccanismi di 10 mx, con un massimo di 10 nomi MX, quindi ognuno di questi può causare 20 operazioni DNS (10 ricerche MX + 10 A DNS ciascuna) per un totale di 200. È simile per ptr o % {p} , tu può cercare 10 meccanismi ptr , quindi 10x10 PTR, ogni PTR richiede anche una ricerca A, ancora per un totale di 200.
Questo è esattamente ciò che verifica la suite di test 2009.10 , vedere i test " Limiti di elaborazione ".
Non esiste un limite superiore chiaramente indicato sul numero totale di operazioni di ricerca DNS client per controllo SPF, lo calcolo implicitamente come 210, do o take. C'è anche un suggerimento per limitare il volume di dati DNS per controllo SPF, tuttavia non viene suggerito alcun limite effettivo. È possibile ottenere una stima approssimativa poiché i record SPF sono limitati a 450 byte (che purtroppo è condiviso con tutti gli altri record TXT), ma il totale potrebbe superare i 100 kB se si è generosi. Entrambi questi valori sono chiaramente aperti al potenziale abuso come attacco di amplificazione, che è esattamente ciò che §10.1 dice che è necessario evitare.
L'evidenza empirica suggerisce che un totale di 10 meccanismi di ricerca è comunemente implementato nei record (controlla l'SPF per microsoft.com che sembra aver fatto di tutto per mantenerlo esattamente a 10). È difficile raccogliere prove del fallimento di troppe ricerche perché il codice di errore obbligatorio è semplicemente "PermError", che copre tutti i tipi di problemi (il reporting DMARC potrebbe essere d'aiuto in questo caso).
Le FAQ di OpenSPF perpetuano il limite di un totale di "10 ricerche DNS", piuttosto che il più preciso "10 DNS che causano meccanismi o reindirizzamenti". Questa FAQ è probabilmente errata poiché in realtà dice:
Poiché esiste un limite di 10 ricerche DNS per record SPF, è possibile specificare un indirizzo IP [...]
che è in disaccordo con la RFC che impone i limiti su un'operazione di "controllo SPF", non limita in questo modo le operazioni di ricerca DNS e afferma chiaramente che un record SPF è un singolo testo DNS RR. Le FAQ implicherebbero il riavvio del conteggio quando si elabora un "include" in quanto si tratta di un nuovo record SPF. Che casino.
Ricerche DNS
Che cos'è comunque una "ricerca DNS"? Come utente . Considererei " ping www.microsoft.com" coinvolgere una singola "ricerca" DNS: c'è un nome che mi aspetto di trasformare in un IP. Semplice? Purtroppo no.
Come amministratore so che www.microsoft.com potrebbe non essere un semplice record A con un singolo IP, potrebbe essere un CNAME che a sua volta ha bisogno di un'altra ricerca discreta per ottenere un record A, anche se probabilmente quello che il mio risolutore a monte probabilmente eseguirà piuttosto che il resolver sul mio desktop. Oggi, per me, www.microsoft.com è una catena di 3 CNAME che alla fine finiscono come record A su akamaiedge.net, ovvero (almeno) 4 operazioni di query DNS per qualcuno. SPF può vedere CNAME con il meccanismo "ptr", tuttavia un record MX non dovrebbe essere un CNAME.
Infine, come amministratore DNS so che rispondere (quasi) a qualsiasi domanda implica molte operazioni DNS discrete, singole domande e transazioni di risposta (datagrammi UDP) - supponendo una cache vuota, un risolutore ricorsivo deve iniziare dalla radice DNS e funzionare a modo suo down: . → com→ microsoft.com→ www.microsoft.comrichiedere specifici tipi di record (NS, A ecc.) secondo necessità e trattare con CNAME. Puoi vederlo in azione con dig +trace www.microsoft.com, anche se probabilmente non otterrai la stessa risposta esatta a causa di un trucco di geolocalizzazione (esempio qui ). (C'è anche un po 'di più in questa complessità poiché i piggyback SPF sui record TXT e limiti obsoleti di 512 byte sulle risposte DNS potrebbero significare riprovare query su TCP.)
Cosa considera SPF come una ricerca? È davvero il più vicino al punto di vista dell'amministratore , deve essere consapevole delle specifiche di ciascun tipo di query DNS (ma non al punto in cui deve effettivamente contare i singoli datagrammi DNS o connessioni).