wayne wrote:
The intent of my limits is to do basically what you say:
Domain owners can count the number of mechanisms and tell if
they are within the limits.
And wizards, and validators. I'm not sure about your limits.
T-Online has 8 MXs (each with one IP), Hotmail has 4 MXs (each
with 4 IPs). I found no worse cases for AOL / ATT / GMX / UOL
and some other ISPs. Whatever that means.
Your "10 MXs ought to be enough for everybody" sounds like the
famous 640 KB. And your example already squeezed 13 MXs into a
DNS answer (maybe, my nslookup didn't tell me what it actually
did before displaying its result, and I was too lazy to use its
debug options).
"Count directives without ip4 or ip6" is a very simple recipe.
"Use a global timeout of at least 20 seconds" is unreliable:
I wouldn't like a sender policy where my mail is "sometimes"
rejected with a PermError, but at other times it works. I hate
intermittent bugs. "Count check_host() calls _and_ MXs _and_
PTRs" is reliable, but rather complex. If you'd insist on it
I'd prefer a plain "count DNS queries" with a limit of say 100.
A mx:t-online.de directive would be counted as 1+8 (for 8 MXs),
a mx:hotmail.com as 1+4 (4 MXs) queries.
it is somewhat common to have more than 10 incoming MTAs
(AOL, Yahoo, etc. have hundreds), this is generally done by
creating many A records for each MX domain name
Yahoo uses apparently 4 MXs, each with up to 5 IPs. But their
load balancing is irrelevant for SPF, that's "4" in your MX
count, "1" in my count of directives, and "1+4" for an overall
DNS query limit.
if you are a web hoster with 1000 virtual domains all served
by the same machine, you can easily have 1000 PTR RRs.
I've never used "nslookup -q=ptr" before, but it works, nice.
BTW, and I've never read Randy Bush's paper (2181) before, but
it's clear. Must be something "you" have discussed here long
before I started to read this list - because as I said I was
stunned why the sender policy for claranet.de didn't cover my
xyzzy.claranet.de. Whatever the SPF wizard did at this time,
it certainly didn't use a "zone cut" as defined in RfC 2181.
Back to the 1000 hosts names with one IP, how does this work ?
With virtual hosts like www.xyzzy.claranet.de it's a wildcard,
and the rest is handled by apache. Dito SMTP for xyzzy. But
you're not talking about a wildcard solution, or are you ?
My ISP returns one name for `nslookup -q=ptr 212.82.225.58`,
home.claranet.de, not www.xyzzy or 1000 other names. What
happens in a "nslookup q=ptr" if you have 1000 PTR records ?
Is anything which doesn't fit in a packet silently ignored ?
all of those PTR references should work equally well for the
SPF ptr: mechanism since they all point back to the same
machine. In the case of forged email, none of them will
work.
And if it's mixed, 1000 bogus PTRs trying to hide a valid PTR,
how does DNS handle this ? Probably irrelevant for your DDoS
scenario, but I'm always curious. Anyway, in your count that's
1000 DNS queries for the names, and in an overall count it's
1001. But I've no idea how the PTR query reported these 1000
names, certainly not in 512 bytes.
it will be very rare for domain owners to even have to know
of this limit.
The wizards / validators have to tell them what's going on if
they try this stunt. You said that 1000 names is a "normal"
case for some web hosters depending on their "zone editors"
(or whatever the name for these tools is). Some domain owners
probably don't know this.
And the author of rxdyndns.htm most definitely didn't know it:
| record once, a powerful example is "v=spf1 a mx ptr -all".
"Powerful nonsense". I'll delete the dubious "ptr" a.s.a.p.
The limits are fairly easy for domain owners to understand
One overall DNS query limit is also "fairly easy". But a PTR
with 1000 names cries for an explicit CAVEAT. The draft says
only "not recommended" without mentioning this reason.
The limits I've specified in the spec are the limits that
have been in place in libspf2 for many months now.
Your "implementation guide" (or whatever it is) is not the same
as a draft created by the person who volunteered as new editor
when SPF was badly hit by MARID, MicroSoft, PRA, and SenderID.
If these limits (in whatever form) are generally useful for SPF
implementations (and I think they are) I want them in the draft
proposed as experimental RfC.
The limits look messing in the spec.
Yes, an overall limit would be much clearer, How you implement
it is another question, first the underlying DNS issues must be
clear for anybody trying to read the SPF draft. Like the IESG.
Bye, Frank