|
Re: Re: Draft ammendments on DNS lookup limits
2005-03-18 23:33:57
Please, comment on the entire idea of the paragraph. Individual phrases
really are out of context otherwise. Nonetheless, I will attempt to
address your comments below:
Frank Ellermann wrote:
Radu Hociung wrote:
A. All SPF checkers MUST resolve at least 10 DNS queries,
...................................^^^^^^^^
Objection. "at least" is no precise limit, the same sender and
policy would work with some receivers but not others.
Further in the same paragraph I explain that after the 10th query, the
only possible SPF outcome can be PermError. So whether someone does 10
or more queries, all checkers will have the same outcome.
I used the wording "at least", because there are ways to discover if the
SPF record is trying to DOS, or is just making a mistake. But for a
client to find this out, they have to perform, or at least count a few
more queries.
regardless of type and recursion.
.........................^^^^^^^^^
Objection, an overall limit of 10 DNS queries is way too small.
I picked 10 because I cannot justify requiring a higher number, though I
did find some complex scenarios that can be satisfied with fewer than 10
queries.
If you can justify a higher limit, please explain the configuration you
have in mind.
I will quote the entire paragraph and explain:
A. All SPF checkers MUST resolve at least 10 DNS queries,
regardless of type and recursion. It is recommended that all
clients perform only 10 queries. PermError must be returned if
the first 10 queries do not yield an authoritative SPF policy.
In other words, the client must do 10 queries. If there are further DNS
mechanisms, the result shall be PermError anyway. It is not necessary to
do the lookups.
By "authoritative SPF policy" I mean "matching mechanism". As in, the
sender explicitly provided an action type (+,-,~,?) to be applied for
the given IP address.
It is recommended that all clients perform only 10 queries.
........^^^^^^^^^^^
Objection, the limit must be a MUST for consistent results
with different implementations.
For consistent result, the MUST in point A should be used. "All checkers
MUST resolve (at least) 10 DNS queries".
This recommendation means that after you've done the 10th, you've
satisfied the standard, and you may stop and return PermError. Or you
may continue, if you want to find out whether this was a DOS attempt.
PermError must be returned if the first 10 queries do not
..^^^^^^^^^
yield an authoritative SPF policy.
...........^^^^^^^^^^^^^^^^^^^^^^^^
Objection, the maximal number of DNS queries to get a policy
is _two_ (q=spf and q=txt), authoritative or not is irrelevant.
The result if you don't get a policy is "None" or "TempError",
not "PermError" (the SPF-bible chapter 4 verse 5).
Poor choice of words on my part. "authoritative SPF policy" should read
"matching mechanism".
B. All SPF checkers SHOULD resolve at most 20 DNS queries
.....................................^^^^^^^.^^^^^^^^^^^^^^
Objection. "at most" is no precise limit, the same sender and
policy would work with some receivers but not others.
This upper limit is meant for detecting DOS. I think it should be up to
the individual postmasters as to what they consider DoS. They will
likely blacklist DoS'ers, but I want the standard to allow them to raise
this limit if they see fit (for instance during transitional periods)
without becoming uncompliant to the standard.
Objection. 20 DNS queries are still too small, a mechanism like
mx:t-online.de could result in 1+8=9 queries.
As I have pointed out before, t-online, as an ISP, should publish a
record made up of list of their 8 servers' IP addresses. All 8 SMTP
servers are within t-online's IP space, so it's not like they will
change IP address without t-online knowing:
[root(_at_)sun src]# host -t mx t-online.de
t-online.de mail is handled by 10 mailin06.sul.t-online.de.
t-online.de mail is handled by 10 mailin07.sul.t-online.de.
t-online.de mail is handled by 10 mailin00.sul.t-online.de.
t-online.de mail is handled by 10 mailin01.sul.t-online.de.
t-online.de mail is handled by 10 mailin02.sul.t-online.de.
t-online.de mail is handled by 10 mailin03.sul.t-online.de.
t-online.de mail is handled by 10 mailin04.sul.t-online.de.
t-online.de mail is handled by 10 mailin05.sul.t-online.de.
What t-online.de should publish, if they ever publish an SPF record is:
Compiled record (9 mechs, len 153, 1 TXT query):
v=spf1 ip4:194.25.134.74 ip4:194.25.134.11 ip4:194.25.134.75
ip4:194.25.134.8 ip4:194.25.134.72 ip4:194.25.134.9
ip4:194.25.134.73 ip4:194.25.134.10 -all
Which can also be expressed as (1 TXT query):
v=spf1 ip4:194.25.134.72/30 ip4:194.25.134.8/30 -all
Can we put t-online.de's case to rest yet?
The quantity of 20 is to each site's discression, and MAY be
set higher or lower.
Objection, the same sender with the same policy would then get
pseudo-random results from 2xx over 4xx to 5xx. A receiver is
free to do whatever it likes, but it MUST NOT claim that this
is a result of some SPF-goes-PRA-plus-timeout-at-the-MUA "test"
Please see my ASCII table below. It shows well defined SMTP responses,
not the pseudo-random results you suggest.
the receiving host may take evasive action
SPF is about _sender_ policies, and not about the management
of local blacklists or iptables at _receivers_ against attacks.
Yes, but it's not about deciding what SMTP errors should be returned for
each SPF result either. Yet, we should somehow mention what the intended
application is for every possible SPF outcome.
Regardless of the local setting as to what constitutes 'DoS',
the checker MUST return PermError
If you've blacklisted an abusive IP you never come to the point
where you'd lie saying "PermError". Or is that a scheme to get
mailto:postmaster@ but reject anything else ? Even then it's
not correct ty say "SPF Permerror" instead of "blacklisted".
I don't understand this?
Black-listing is only one of the possible "evasive measures". Another
possibility is to block the incoming IP at the switch. Another
possibility is to also block the domain at the SMTP server
MAIL-FROM/EHLO stage. It really should be up to the postmaster to decide
how to deal with DoS. Depending on the severity of the problem,
different response may be needed. If you got bombarded with 1 million
emails an hour, would you still want mail from that IP to your postmaster ?
In any case, SPF is not about specifying what to do with DOS. I think it
is enough if we provide a way to inform the postmaster when DoS is
probably happening, so they can do whatever is necessary and
appropriate. That is simply out of the scope of SPF, as you have
mentioned above.
Here is my proposed change expressed as a matrix of possible results and
recommended actions. It is ASCII with 70 characters per line, so it
would display best with a fixed-width font. I appologize in advance if
you cannot read it. In that case, cutting-and-pasting into Notepad may
show it the way it was intended:
Query | Type | Possible | Recommended
number| | SPF Outcomes | SMTP reply
------+------+-------------------+-----------------------------------
| | TempError | 4xx Temporary DNS failure
1 | TXT | PermError | 5xx Sender domain does not exist
| | None | 200 Ok this time. No SPF record.
------+------+-------------------+-----------------------------------
2 | any | |
3 | any | |
4 | any | TempError | 4xx Temporary DNS failure
5 | any | PermError | 5xx Fix it your SPF record
6 | any | Pass | 200 Ok
7 | any | Fail | 200 Ok or 5xx I don't believe you
8 | any | Softfail | 200 Ok but be warned
9 | any | Neutral | 200 Ok I will scrutinize
10 | any | |
------+------+-------------------+-----------------------------------
11 | any | |
12 | any | |
13 | any | |
14 | any | |
15 | any | |
16 | any | PermError | 5xx: Too many DNS queries
17 | any | |
18 | any | |
19 | any | |
20 | any | |
------+------+-------------------+-----------------------------------
21+ | - | PermError | 5xx: You are now blacklisted
A few comments:
It is easy to see that since all clients are required (MUST) to do "at
least" 10 queries, records that take up to 10 queries to find a
"matching mechanism" will yield the *same SPF outcome* at all sites. If
some do 8 and some do 9, then we would have different outcomes.
Since we require that queries in excess of 10 be treated as PermError,
all clients will behave the same, even if they choose to do more than 10
queries. If they would find something other than PermError after the
10th query, then we would have different outcomes.
I also show that the limit of 20 is used to decided when to switch from
a simple "Too many DNS queries" response to a more heavy-handed response
of "You are now blacklisted".
Please provide justification for higher or lower limits. A real
configuration using existing domain names, or a detailed fictitious
configurations will do.
A limit of 10 seemed low to me to when I started thinking about this a
couple of months ago. I have been looking for real situations that
honestly require more than that, and I couldn't find any. It doesn't
mean they don't exist. Please point them out if they do.
Regards,
Radu.
|
|