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

[Tim Wicinski <[e-mail]>]

On Sun, Jan 15, 2023 at 6:29 PM Scott Kitterman <[e-mail]> wrote:

> On Sunday, January 15, 2023 6:17:34 PM EST Jan Schaumann wrote:
> > Scott Kitterman <[e-mail]> wrote:
> > > There is the "overall" limit.  The count against the overall limit is
> two
> > > ('a' and 'mx').
> >
> > Thanks for clarifying.
> >
> > I find this _very_ counterintuitive, fwiw.
> >
> > My logic was roughly:
> >
> > "Well, the limit should limit how many lookups I have
> > to make in the worst case before I can decide.  Doing
> > an 'mx' lookup by itself doesn't help me at all in
> > making that decision -- I absolutely _have_ to turn
> > any hostnames I get into IP addresses, so I must
> > necessarily perform additional lookups."
> >
> > So if I'm at a DNS lookup limit of 9 when I reach the
> > 'mx' part, and the domain has 10 MX records, I perform
> > 10 additional lookups (which don't count to the total
> > limit, meaning I perform a total of 19 lookups) and
> > move on.
> >
> > But if I'm at a DNS lookup limit of 0 when I reach the
> > 'mx' part, and the domain has 11 MX records, then the
> > 'mx' evaluation yields permerror and I abort.
> >
> > But if that's what it is, then that's what it is. :-)
>
> That's what it is.  It probably made more sense in 2005 than it does now,
> but
> we're pretty well stuck with it for v=spf1.
>
> It's actually even more complex than this since most will do a PTR lookup
> for
> each IP address returned.  Also, note that the limits for the SPF PTR
> mechanism as slightly different.
>
> There were claims made at the time that there were other, easier ways to
> conduct DNS amplification attacks and the limits were overly strict.
> That's
> certainly true now.  Even so, the pre-RFC limits were strictly based on
> maximum recursion depth and had the potential for truly extraordinary
> amplification.  Given the two, I think we picked the better approach in
> 2005
> and SPFbis was correct not to fundamentally change them.
>
> If I were going to do an SPFv3 (I have no plans, don't get excited), this
> is
> one of the areas that would be ripe for redesign.
>
>
I too think the 2005 approach was the correct approach.

I also feel that technology stacks have matured over time.  Jan, do you see
real world examples
of a domain with 11 MX servers?  I ask because in 2023, I would find that
the rare exception
rather than the rule.

(Though I am now pretty sure Jan has an interesting data set that will
prove me wrong!)


tim

>
>