Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

From: John Levine <[email-masked]>
Date: 13 Jan 2005 02:48:53 -0000

>> The zone cut stuff is working, in practice, for me in my beta-code.
>> If it can't be made to work, or we can find another idea that would
>> work better, I'm all for dropping it.

I would surmise that none of your clients use djbdns as their DNS
software.  Its cache does correct negative caching, but it doesn't
return SOA records as additional or authority data.  You don't have to
like djbdns, but enough people use it that you can't wave it off.

The only halfway reliable ways to find zone cuts are either to build
your own resolver into your application and follow the chain of NS
records from the root, which seems a lot to ask an application to do,
or as an approximation walk up the DNS tree looking for SOA records.
If you're going to walk up the tree anyway, you might as well look for
the data you really want rather than SOAs and permit domain-wide data
at any DNS node.

Beyond the faux wildcard issue, there are some other DNS issues with
SPF that I'm wondering about.  The most serious is the blizzard of
requests that interpreting SPF records can require.  I realize that
CNAME has many of the same issues, but SPF introduces not just long
chains but bushy trees.  For a contrived example, check the SPF for
very.slow.sp.am, which takes about half an hour to resolve.  When I
pointed out this DOS opportunity to Meng, he "fixed" it by setting
arbitrary limits on the number of indirect references allowed when
interpreting an SPF record, thereby introducing a variety of ways to
make make working SPF mysteriously fail as domains down the tree add
an extra reference or two.  Based on other experience with DNS, is
there anything helpful one could say other than suggesting that they
take the bushiness out?

Another question is the big record problem.  Some SPF descriptions are
complicated enough that they won't fit in 512 bytes.  What's the best
thing to do?  Hotmail.com broke theirs up into four chunks named
spf-a.hotmail.com through spf-d.hotmail.com, with the main hotmail.com
SPF including the four.  The total amount of data is only about 1K so
a UDP transaction with the truncation bit followed by a TCP
transaction would probably be fewer packets than the five queries the
split version needs.  Other than reminding people that EDNS0 is
available for their large packet needs, any suggestions on artificial
subdivision vs. TCP?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: wayne <[email-masked]>
Date: Thu, 13 Jan 2005 02:02:34 -0600

> like djbdns, but enough people use it that you can't wave it off.

It is likely that my code has not been tested on djbdns, but doing
digs by hand, I could not find any problems.  Pobox.com uses tinydns
and checking ns1.rightbox.com seems to return SOA records just fine.

Could you please give me some more details?

> requests that interpreting SPF records can require.

This is also a large concern of mine.  Have you read the current I-D?
In particular, the processing limits for the number of DNS requests?

>                          For a contrived example, check the SPF for
> very.slow.sp.am, which takes about half an hour to resolve.

Is this the same example as you gave here?

http://www.imc.org/ietf-mxcomp/mail-archive/msg02436.html

If so, my response is pretty much the same as last time:

http://www.imc.org/ietf-mxcomp/mail-archive/msg02438.html

Since then, I *have* been allowed to add a time to SPF checks and I
have also added process limits similar to the ones found in the
libspf2 SPF implementation that I mentioned in my reply.

I also brought up the subject of SPF and DDoS attacks in this message.
http://www.imc.org/ietf-mxcomp/mail-archive/msg02440.html
There is a URL to a another message in there which is munged.  It
should be:
http://archives.listbox.com/[email-masked]/200312/0393.html

>                                                              When I
> interpreting an SPF record,

I'm not sure when you pointed this out to Meng but the SPF specs have
had limits on the number of include: and redirect= references for a
year.

> [...]                       thereby introducing a variety of ways to
> an extra reference or two.

I'm not sure if anything can be done about that.  Either you have
limits, in which case you can run into those limits, or you don't have
limits, in which case you have DNS DoS and DDoS problems.

In practice, very few domains come even close to the process limits.
(I have done surveys of all SPF records in the .com, .net and .org
domains.  Results from the surveys were posted on the MARID list.)

>                             Based on other experience with DNS, is

You mean by removing the include: and redirect= mechanisms?  That
would be a huge incompatiblity, and wouldn't by itself solve the DoS
problems.

> available for their large packet needs, any suggestions on artificial

Hotmail has some of the largest SPF records that I know of, most SPF
records are fall smaller.  (Again, survey results were posted to
MARID.)  It is my understanding that MS has listed every IP address
that they own in their SPF records, instead of listing the ranges that
send email.  My initial reaction to hotmail's records is that they
should put a little effort into making their records smaller.

As far as DNS over TCP goes, there are a lot of (broken) firewalls out
there that have been configured to reject TCP port 53.  Any SPF
publisher that wishes to have their records available to everyone
needs to avoid falling back to TCP.

As far as the total amount of traffic caused by hotmail's 5 SPF
records vs one TCP DNS lookup, I'm not sure that TCP would be
cheaper.  You would generate one UDP lookup anyway, and then you have
the three-way TCP startup handshake and the four-way TCP teardown.

-wayne

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Jan 2005 15:43:30 +0100

On Wed, Jan 12, 2005 at 10:08:36PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 94 lines which said:

> somebody around here told me recently that they had had to delete
> their SPF records because one or more SPF Clients had implemented
> SPF improperly, and were rejecting mailing list e-mail based on the
> mismatch between the header From: and the list exploder.

I know at least one program which is broken enough to do so, a Mozilla
Thunderbird extension:

http://www.extensionsmirror.nl/index.php?showtopic=1338

(Checking the RFC 2822 From: has nothing to do with SPF.)

But the adventure of your somebody proves nothing: after all, I had to
change my email configuration several times because people were
implementing stupid checks, too (see the thread "fixing insecure email
infrastructure" today on NANOG).

> all this proves is that no matter how careful a specification is
> authored, it still has to run the gauntlet of wide scale
> implementation.)

We all agree there are broken software and hasty implementors. But the
bug in the mentioned program is so huge, there is nothing the draft
authors could have done against it.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Jan 2005 10:43:24 -0500

Time for a periodic rant.

>authors could have done against it.

Why isn't such a situation brought to the attention of the IETF?

The IETF is supposed to design "good" protocols and to develop 
"clear" documents.  ("Good" manifested in achieving Proposed 
Standard, "clear" manifested in achieving Draft Standard.)

The way I look at it - there is a balance between documents 
(representing design) and code (representing implementation).

The documents represent strategy or design for solving a problem, 
considering all the angles (and "corner cases").  E.g., data model, 
management model, congestion management of the transport, IDN 
compatibility, etc.  The value of the IETF is that so many different 
kinds of expertise can be called on to review a solution.

Code represents the muscle of the Internet, the pragmatic view of the 
world.  It is how the network works.  Code deals with physical 
limits, I/O speed, data transmission speed; it deals with user 
nuances and legal issues too.

Code without design is a mess.  We know that.  Design without code is 
useless.  Evidently we need to do a better job preventing that.

If implementers (or interoperability testers) find a document to be 
inaccurate they should be encouraged to say so.  The IETF would be 
strengthened by such feedback.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 14 Jan 2005 11:29:35 +0100

On 13 Jan 2005 02:48:53 -0000

>  available for their large packet needs, any suggestions on artificial

The main argument against TCP is not a traffic argument (although if
one is volume charged it could be a consideration) but the amount of
state the OS the nameserver runs on needs to maintain.

-- Olaf