Re: [spfbis] RFC7208 4.6.4 Interpretation - MX Lookup Count Inconsistencies

[Scott Kitterman <[e-mail]>]

Comments inline.

On Friday, January 13, 2023 3:09:03 PM EST Mark Alley wrote:
> Hi all, I have two questions about section 4.6.4 regarding "mx" 
> mechanism DNS lookup counts during SPF evaluation that I would like some 
> guidance on. I haven't been able to find anything regarding this topic 
> specifically in the ML archive aside from one niche topic relating to 
> the MX AAAA ipv6 queries counting as void lookups.
> 
> ------------------------------------
> 
> First, checking logic implementations of the "mx" mechanism DNS lookup 
> count of various SPF validator tools compared to the logic described in 
> section 4.6.4, I discovered implementation inconsistencies that have led 
> me to question what the "correct" logic is for counting MX lookups in an 
> SPF record. There are 12 SPF validators on the internet that seem to 
> skip over this during lookup counting (many from well-established 
> vendors), and only 3 that do not.
> 
> So, given this, based on the below information, which is the correct 
> counting interpretation?
> 
> There is a domain - katrinafox.com - which has an SPF record that looks 
> like this:
> 
> /v=spf1 +a +mx +ip4:35.213.205.66 include:_spf.mailspamprotection.com ~all/
> 
> Breaking down DNS lookups manually, we get this:
> 
> 1 - "a" mechanism
> 
> 4 - "mx" mechanism (1 initial MX record lookup, +3 A/AAAA MX names
> returned)
 
> 4 - "include" mechanism (1 initial include lookup, +3 recursive includes)
> 
> Per the first paragraph of section 4.6.4, it reads as such: "/When 
> evaluating the "mx" mechanism, the number of "MX" resource//records 
> queried is included in the overall limit of 10 mechanisms///modifiers 
> that cause DNS lookups as described above."/
> 
> My interpretation is that the language is clear; the MX names (A/AAAA 
> RRs) returned by the MX query are counted against the overall 10 lookup 
> count of the evaluated SPF record. Leaving this domain's SPF record with 
> a total of 9 lookups. However, the overwhelming majority of SPF 
> validator tools (and I haven't even started researching receiver-side 
> logic implementations of this yet) seem to implement this /skipping/ the 
> MX query returned names as part of the lookup count, which leaves the 
> lookup count for this domain at 6.

First, some history.  In the predecessor document, RFC 4408, the processing 
limits were in security considerations, not in the main specification (Section 
10.1).  There are some changes between RC 4408 and RFC 7208 in this area that 
may account for some differences, but I don't think this is correct for either 
version of the limits.

Moving forward, here's the full text specific to MX from RFC 7208, Section 
4.6.4:

>    When evaluating the "mx" mechanism, the number of "MX" resource
>    records queried is included in the overall limit of 10 mechanisms/
>    modifiers that cause DNS lookups as described above.  In addition to
>    that limit, the evaluation of each "MX" record MUST NOT result in
>    querying more than 10 address records -- either "A" or "AAAA"
>    resource records.  If this limit is exceeded, the "mx" mechanism MUST
>    produce a "permerror" result.

In the example you gave, only the +mx lookup counts against the overall limit.  
"MX" resource records are exactly that.  The address records (A/AAAA) are 
counted separately as clearly indicated in the sentence after the one you 
quoted.  

The change from RFC 4408 to RFC 7208 is in how the second limit (no more than 
10 address records) is addressed.  As you can see, RFC 7208 specifies an error 
if that number is exceeded.  RFC 4408 specified to truncate lookups at 10 
without error.  We changed this for RFC 7208 because the silent truncation 
specified by RFC 4408 left a risk of inconsistent results (if there are more 
than 10, there's no guarantee of the order they are returned in, so an 
identical message might pass one time and not another).

MX records with more than 10 address records are relatively rare, so it would 
not surprise me if some implementers did not consider this a change worth 
spending the money to make.


> ------------------------------------
> 
> Second, addressing the second sentence of the second paragraph in 4.6.4 
> (which continues the context of the last above question): "/In addition 
> to that limit, the evaluation of each "MX" record MUST NOT result in 
> querying more than 10 address records -- either "A" or "AAAA" resource 
> records./"
> 
> There seems to be the same inconsistencies among SPF validator tools for 
> this logic as well. Three tools, one being MXtoolbox, say this domain 
> has "too many IP addresses returned from the MX query" (of which there 
> are well over 10 total), which results in their evaluation returning 
> "permerror".
> 
> It seems some implementors have interpreted the "10 address records" 
> phrase to mean "/the number of IP address records //resulting //from an 
> MX name A/AAAA RR query/", rather than "/the total sum of the MX names 
> themselves/", as would seem described by the section's language. Of my 
> interpretation from this section's language, it would seem this domain 
> should exceed neither the SPF lookup count, nor the MX A/AAAA query count.
> 
> Which is the most accurate interpretation of this section?

See above.  Yes.  "address records" and "IP address records" are synonymous.  
If a record has multiple "MX" mechanisms, each one can have up to 10 address 
records (A/AAAA).  The assigned names fo A/AAAA are "a host address"/"IP6 
Address" [1], so I don't see how it could be anything else.

Also, as mentioned above, if some validators raise an error and some don't, 
that's a result of the change going to RFC 7208 from RFC 4408 that I mentioned 
above.

I think you need to go back and revisit you assessment of how these work as I 
don't think it's correct.  We struggled with this in the SPFbis working group 
as it was very difficult to come up with clear and accurate language, so I'm not 
surprised to see it's not immediately obvious what we meant.

Scott K

[1] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4