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

[Mark Alley <[e-mail]>]

I appreciate the clarification, that is much clearer now, thank you.

I was asking for the group's guidance on this as some other vested 
individuals on this topic had similar questions as myself about this 
specific section, so I thought to ask to clear it up.

- Mark Alley


On 1/15/2023 3:18 PM, Scott Kitterman wrote:
> 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
>
>
>
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis