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

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Jan 2005 17:05:24 +0000

> 1. The draft says that if SPF record is not found for say
> "sub.example.com", that lookup should be made for zonecut record which
> would probably be "example.com". This is done as a way to simulate
> *.example.com and provide spf record for all subdomains (especially
> when they exist unlike "*"), but I think the problem is that these
> default SPF record are not identified any difernent as with "*" and
> its just normal spf record for that domain that is always the default
> and one can not turn this off. I have proposed instead using special
> prefix - possibly "*spf*" or just "**" so that such records are
> clearly identified, this would also allow in the future to add feature
> to dns server itself that it could substitute default on its own
> instead of forcing client to do 2nd lookup each time.

the SPF steamroller can't slow down or change direction, nope.  or else
we'd be using namehack-based subclassing a la the "mail-from" proposal.

however, some thought should be given to protecting the root servers.
given that a number of ill-considered SPF clientsides already do things
like look at some/all header addresses even if only envelope addresses
are indicated, thus breaking mailing list exploders who leave the headers
as they are and only rewrite the envelope, we know that SPF's clientside
will be broad, unaudited, and powerful.  it may be that given a domain
name of sub.example.com, queries will be made for TXT RRs having names

     sub.example.com
     example.com
     com
     .

which would be bad.  with specific reference to RFC 1535, i'd like this
danger to be called out in the dns-related part of the SPF document, in
case any clientside implentor ever actually reads the SPF specification.
perhaps a prohibition of the form "SPF queries must never be made for
domain names having fewer than two labels".

> 2. I'm still not perfectly happy that SPF is reusing TXT and especially 
> that this draft has changed all examples to use TXT instead of SPF record 
> type. In my opinion SPF draft should promote new SPF record type a lot 
> more and have clearly defined "exit" strategy of moving away from TXT 
> records once new DNS RR has been issued.

moreover, there should be two documents.  one an FYI describing SPF as it
is (TXT RR based), and one a proposed standard recommending a new RR type.

--
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: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Jan 2005 15:46:17 +0100

with specific reference to RFC 1535, i'd like this
    
Although I agree with Paul about the danger (unnecessarily querying
of root and tld domains) he tries to guard against with this language,
this won't help tlds with second level or deeper level structure
such as co.uk or eu.int.

This whole idea of walking up the tree looking for an SPF record
seems to be broken to me.

	jaap

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 17:15:23 +0100

On Tue, Jan 11, 2005 at 03:46:17PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 

> this won't help tlds with second level or deeper level structure

At least, it will mitigate the problem.
 
> seems to be broken to me.

The rationale is to handle domains with subdomains (like
www.example.com or sales.example.com) which typically forget to set up
a SPF record for the subdomains. So, the phisher can just say MAIL
FROM:<[email-masked]> and defeat SPF even if example.com is
protected.

Of course, the proper solution is to have SPF records automatically
generated by the same process that creates the zone file with the
proper PTR, the MX records and so on. But some people seems to edit
large zone files by hand (they typically do not know M4 or Perl or
Ruby) and want a mechanism to help them.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 17:17:34 +0000

> Ruby) and want a mechanism to help them.

People's inability to edit zonefiles by hand properly or implement proper
macro languages does not seem to me a sufficient reason to load up the DNS
servers of those above them in the hierarchy. Seems to me you are trying to
solve a layer 8 problem at the protocol layer, when it should, if anywhere,
be solved at the application layer.

I had heard wind (possibly malicious, so I don't assign it much
credibility) that the real purpose behind the tree walk was so those who
don't like the default SPF action could lobby TLDs etc. so that the default
SPF for (say) any domains within (e.g.) co.uk could be changed by (e.g.)
Nominet (and .com by Verisign etc.). I think this is a responsibility zone
operators should not seek...

Alex

---

From: Robert Martin-Legene <[email-masked]>
Date: Tue, 11 Jan 2005 20:10:43 +0100

>operators should not seek...

I wonder how many registries would really want to do this. It sounds
very dangerous. 

However, the load on the TLD servers could be greatly diminished
by adding a TLD TXT record with a very high TTL.

I am not saying it's a solution to the problem. Just yet another hack.
The application should never query the TLD servers (nor lvl 2 for e.g.
.uk) for SPF-records of any kind.

-- 
Robert Martin-Legène
IT security manager
DK Hostmaster A/S

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 19:24:38 +0000

> .uk) for SPF-records of any kind.

May be I misunderstood. How does the application know to query
for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

Alex

---

From: Robert Martin-Legene <[email-masked]>
Date: Tue, 11 Jan 2005 20:28:05 +0100

>for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

I was stressing that *I* dont think it should.

It probably doesn't know, and that's a problem.

-- 
Robert Martin-Legène
IT-sikkerhedschef / IT security manager
DK Hostmaster A/S

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Jan 2005 20:37:20 +0100

Also note that there are TLDs out there which have a mixed system:
they allow myname.example. and myname.com.example.  If you want to
have any hack like this to work, you have to configure the whole
current and future name space structure in the hack to make it work.

	jaap

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 22:43:26 +0100

On Tue, Jan 11, 2005 at 05:17:34PM +0000,
 Alex Bligh <[email-masked]> wrote 
 a message of 25 lines which said:

> credibility) that the real purpose behind the tree walk was so those
> who don't like the default SPF action could lobby TLDs etc. so that
> the default SPF for (say) any domains within (e.g.) co.uk could be
> changed by (e.g.)  Nominet (and .com by Verisign etc.).

They are not rumours, some people already requested that (not the I-D
authors, nor me). A TLD even announced its SPF record for the TLD as
an "anti-spam" service...

(Today, four TLD, all managed by the same registry, have a SPF record.)

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 14:02:10 -0800 (PST)

> name of sub.example.com, queries will be made for TXT RRs having names

That is not exactly true. They are not planning to "walk down the tree" 
but they will look authoritive zone domain (the one that holds SOA for
that domain) and then lookup record at that start (i.e. if 
sub1.sub2.example.com is a host in the zone of example.com, the lookup 
will immediately come to example.com and not first to sub2.example.com). 
That pretty much means the root servers will never see the such lookups. 
But situation is different for TLDs and SLDs, there are in fact number of 
domains used as nameservers which "A" records are registered directly in 
TLD zones and I'm afraid some implementations may incorrectly assume that 
TLD zone is start of authority for that domain (they are not supposed to 
make this assumption just because "A" record is returned in the ADDITIONAL 
section but we all know majority will not do extra dns lookup once they 
get the answer - be it from ADDITIONAL section or otherwise).

I'm also generally concerned that SPF lookups just for single host will
very often result in at least 4 dns lookups with zonecut defaults (one TXT 
lookup for sub.domain.com, one SPF lookup for sub.domain.com, one TXT 
lookup for domain.com, one SPF lookup for domain.com) and that is just
too much extra load on ISP dns servers and ISPs already have more then
enough problems with their DNS servers getting overloaded because of
other anti-spam filter and as ISP operator and dns host for 1000+ domains
I'm quite concerned.

That is why when I originally mentioned the concept of putting spf default 
at zonecut at interim MARID meeting in May, I had in mind that it would 
not be SPF client doing lookups but that instead its dns server at the ISP 
that would recognize "default wildcarded" SPF records and serve them and 
I'm of the opinion that this should be considered tool for the dns server 
operator rather then client hack. 

If you remember I in fact emailed you if BIND could implement it (i.e. 
synthetic new type of wildcard for when record does exist) and if this 
would require upgrade to DNS protocol. If I understood the answer, it
would because since zones are transfered and secondary can be running
different version of dns server - it should then also be able to
understand new symantics (i.e. just like with regular wildcards where
answer is synthesized but its done same way by every dns server).

Now what I propose is that we do focus on making these zonecut default
records something for dns server to understand (which will require update
to dns specs) and synthesize the answer automatically but in the mean time 
allow clients to simulate it and do 2nd lookup. This way even if one dns 
servers understands new semantics and secondary does not, it could still 
work but we are assuming that in the future once all dns servers are upgraded
the 2nd dns lookup will never be done. If we do want to do it this way, 
then I think it should be new type of wildcard record (and "**" seems quite
good for that purpose) so it could be applicable to more then just SPF.

> domain names having fewer than two labels".

What about example.com.uk? You can't make an assumption that TLD is correct
start of domain delegation.
 
> is (TXT RR based), and one a proposed standard recommending a new RR type.

The current draft is going for experimental status RFC and is the one 
describing what could loosely be called current practice of how SPF is
used (I note that some features are in fact implemented a lot more widely 
then others, for example lookups at EHLO are done at less then 1/10th of 
the rate the MAIL-FROM lookups are done and the mentioned wildcard default 
are almost not implemented at all, which is  why I think its not too late 
to change this). I would definitely be opposed to having used TXT RR in 
standard track document but even with experiment it should be made clear
that we want to move all lookups to SPF before it could become standard.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 22:52:56 +0100

On Tue, Jan 11, 2005 at 08:37:20PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 

> current and future name space structure in the hack to make it work.

Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
lookup, which avoids any assumption about the structure or the depth
of the name space...

With the "security belt" added by Paul Vixie (never request for names
of zero or one label), it seems safe, even if there are better
solutions (like mentioned by Alex Bligh).

For the fun, do note that the zone cut algorithm can be defeated by
unusual configurations (so it is a good idea to introduce Paul Vixie's
limit). For instance, try to find the zone cut above doesnotexist.ac
(hint: some of the name servers of the TLD are recursive).

---

From: Don Stokes <[email-masked]>
Date: Wed, 12 Jan 2005 11:21:58 +1300

>FROM:<[email-masked]> and defeat SPF even if example.com is

What's wrong with a wildcard TXT (or better still SPF) RR for such
subdomains?  Put that in the SPF spec, rather than speculatively heading
up the three.

-- don

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jan 2005 23:22:36 +0000

> "*" wildcards are only useful for hosts that don't exist at all (no dns 
> RR of any kind for that hostname), but they will not work for hosts that 
> have some RR record which is what SPF people are after.

that still doesn't make any sense.  SPF RRs will only be used when there
is an extant LHS@RHS, and the RHS has to have either an A or MX RR which
is at either a real or synthesized (wildcard) name.  put the SPF RR (or
the TXT RR) adjacent to the existing MX or A RR, either at a real name if
that's how the A or MX is found, or at a wildcard "name" if that's how the
A or MX is found.

> P.S. Is there some reason you have not read the Ed Lewis's wildcard draft 
> that was discussed on this list just couple months ago? 

i'm pretty sure that we've all read that, or helped write it, or whatever.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 23:32:40 +0000

> (Today, four TLD, all managed by the same registry, have a SPF record.)

Well I'm no fan of spam, but I believe the argument over an SPF default
should be an IETF one - I can't (and I'm involved with a registry) see a
justification for registries effectively retrospectively being able to
impose an alternative. IE I am presuming there are good reasons the SPF
default is the way it is, and it should not be within the administrative
purview of some other entity to go change it (shades of sitefinder...).
That said, the argument that tree iteration is going to cause load problems
is more serious.

Alex

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 18:22:35 -0600

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <[email-masked]> Paul Vixie <[email-masked]> writes:

> is at either a real or synthesized (wildcard) name.

The problem is that spammers and phishers can easily use
nonexistant.subdomain.example.com to get around example.com's sender
policy.  This has to work for both the RFC2821 MAIL FROM identity and
the RFC2821 HELO identity.  Sure the email receiver can have a policy
of rejecting email from non-existant domains or domains without an A
record, but in the world of email, there is far too much garbage sent
by legitimate mailers to make such a receiver policy universal.  There
needs to be a way for example.com to publish something for the entire
zone that it controls, even the non-existant parts.

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:44:59 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

>> when they exist unlike "*"), [...]
>

Hi Paul.

Although I've been reading posts from you since the late 80s, I'm
afraid I haven't read enough to know for sure whether you are speaking
sarcastically or not, so please excuse me if I respond seriously to a
joke.

Yes, it is now very hard to slow down or change the direction of SPF.
The spec has been pretty slushy for over a year, and incompatible
changes are going to cause a lot of problems.

As far as the namehack-based subclassing thing goes, two points.

First, William was talking about where to find the SPF record that
should be used as a *default*, not where all SPF records are located.
What he was talking about had nothing to do with subtyping the TXT RR
instead using a new RR type (e.g. SPF).

As for why the (current) SPF spec doesn't use the namehack-based
subclassing, at one time the SPF spec did use _spf.domain.tld.
Unfortunately, we found too many DNS hosting services that didn't
allow the underscore to be entered into the web pages.  This is kind
of a delema for those hosting services.  Yes, an underscore is
perfectly valid for a domain name, but it isn't valid for a host
name.  Trying to explain this difference to the general public
requires more effort than I suspect most DNS hosters are willing to
do.  Making a special exception for SPF records was not something we
expected that DNS hosters would make.  At least not when this was
changed over a year ago.

> however, some thought should be given to protecting the root servers.

I agree, and I'll try to find a good spot to add some language about
this.

Things are not quite as bad as they may seem.  It is subtle, but if an
SPF implementation conforms to the draft-schlitt-spf-classic-00 spec,
it takes work to generate a DNS query with only one label.  The ABNF
requires all domain specs to end with a dot followed by a "toplabel",
or a macro variable.  So, "include:com" is already invalid.  Normally,
the macro variables will have at least two labels in them, so
"include:%{o}" isn't going to be a problem either.  Even
"include:1.2.3.4" isn't valid, so the root servers won't be hit with
lookups for IP addresses.

> [...]                                    it may be that given a domain
> which would be bad.

I agree that this would be bad, but the current SPF spec would not
allow the checking for SPF records at "com" or ".".  If an SPF record
is not found at the exact domain name, the only other location that is
checked is at the top of the zone (i.e., right under the zone cut).

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:49:25 -0600

> operators should not seek...

Any such rumors that you have heard are either due to ignorance or
maliciousness.  None of the various SPF specs that have existed have
ever called for an arbitrary tree-walk, let alone one all the way to
the root.  The current SPF spec calls for checking SPF records in two
places, and two places only: at the given domain, and at the top of
the zone (just below the zone cut).  As such, any conforming SPF
implementation would never know about any SPF records at co.uk, or
.com.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 05:24:36 +0000

> > ... how would you propose to discover the "zone cut" you're speaking of?
> 
> By checking the authority section:

did you know that the authority section is optional in positive responses?
(have you read RFC 2308?)

> > i know how i had to do it in bind8's res_findzonecut() ...
> 
> Personally I'd not mind with having that function becoming part of resolver,
> that will sure help us out ...

it has been part of the BIND resolver library since BIND 8.2 or so.  but
you are asking that every SMTP listener possess it and call it on every
SMTP session, which is a lot of potential extra traffic for all concerned.

and none of it is necessary to your application.  just don't query for
anything except the RHS.  (see my other reply elsewhere on this thread.)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 06:30:08 +0000

> Positive responses are not a problem - if somebody queries for SPF RR and 
> gets it, there is no need to do anything else. If there is no authority 
> section for negative response, then client can directly query for SOA.

it is very nearly unthinkable to me that a mail server, as a client of dns,
should ever have to make an SOA query, under any circumstances, especially
not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

> > ... are asking that every SMTP listener possess it and call it on every
> Which is exactly why I said that we should make it special prefix that
> dns server can recognize it and synthesize the answer. The client can
> simulate this with zonecut method but as more dns servers begin to
> support it, its no longer a problem in the long run.

i really am pretty sure that the dns servers will be changed to support SPF
other than to support a new RRtype when y'all get around to proposing that.

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Jan 2005 09:23:47 +0100

> solutions (like mentioned by Alex Bligh).

that 'belt', which I guess Paul didn't really suggest, tends to be at least as
bad as the desease. The 'tree climbing' approach is the result of a
misconception about the DNS: it tries to kind of inherit records or even policy
from higher levels in the DNS, which is not only wrong for TLD or "registry
level" zones like DE or co.uk, respectively, but also further down the tree.
The foo department of bar.example cannot be assumed to by default apply
the same policies as bar.example. In the same way we do not inherit or
deduce MX RRs or A RRs, the temptation should be resisted in this case.

Unfortunately there are some precedents (see 'wpad'), but those should not
count as justification. This is DNS, other services might be more appropriate
for the inheritance approach.

-Peter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Jan 2005 10:39:38 +0100

On Tue, Jan 11, 2005 at 02:02:10PM -0800,
 william(at)elan.net <[email-masked]> wrote 
 a message of 114 lines which said:

> They are not planning to "walk down the tree" but they will look
> authoritive zone domain (the one that holds SOA for that domain)

The SPF draft says "the SPF client MUST find the Zone Cut as defined
in [RFC2181] section 6" and RFC 2181 uses NS records, not SOA.

For a "normal" zone loaded by BIND, it does not matter. But you can
always find funny cases where it's different depending on wether you
use NS or SOA (study doesnotexist.ac).

---

From: Robert Martin-Legene <[email-masked]>
Date: Wed, 12 Jan 2005 15:15:51 +0100

On Tue, Jan 11, 2005 at 09:23:35PM +0000, Paul Vixie wrote:
>> However, the load on the TLD servers could be greatly diminished by
>> adding a TLD TXT record with a very high TTL.
>
>no.  enough broken dns clients out there fail to cache anything at all,
>positive or negative, that the presence of a TLD TXT RR would not slow
>down the rate at which these queries were generated, or needlessly and
>endlessly repeated.

Yes it would.

That there are some broken clients does not mean that all others will
misbehave. And if you are lucky they even have a cache in front of them
- but you assume that is broken too, I suppose - we have all seen
repetetive queries on our servers. Fine. But it still has an effect for
all correctly functioning implementations. So I think you are
exaggerating a little bit when you say plainly that it will have no
effect.

(and I still don't think it's a solution to a problem)

-- 
Robert Martin-Legène
IT security manager
DK Hostmaster A/S

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:44:38 +0000

> As I said, on the tests it appears that dns servers (bind 8 and bind 9 
> at least) do provide this information nearly all the time including for 
> NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
> very often.

this is namedroppers@, not bind-workers@.  how a particular implementation
behaves is of no interest to the ietf, other than if a widely implemented
protocol violation (which this is not) makes it necessary to design-around
(which this does not).

> And yes it does sound weird for non-dns service to query for soa, but
> its not breaking anything either as far as I can see and querying for
> soa can be usefull for more then just dns internal communication, for
> example to find tech/hostmaster address if whois is not available (ok,
> you can go ahead and blame me for this trick and inappropriate use :)

that's what RP RR's are for.  or did you not know that SOA was never cached?

> > i really am pretty sure that the dns servers will be changed to support 
> > SPF other than to support a new RRtype when y'all get around to 
> > proposing that.

s/will/won't/, sorry.  though i suppose it was clear in context.

> Should I take as that you're willing to support such a feature (synthetic
> wildcard for existing hostname but without needed RR) in future versions
> of bind?

no.  i misspoke.  BIND will implement the dns protocol as defined by the
ietf, with occasional experimental features if those do not violate the
protocol defined by the ietf.

> In that case it makes sense for this to become a new dns protocol
> feature so that other dns servers would know how to support it too, so
> I think it would be good idea to write it out as ietf document
> (separate and not just part of spf draft).

even though i misspoke, there's a path forward illuminated by the mistake.
if you want rrtype-specific wildcards, like for example an "**" label in a
zone file should be a wildcard but only for the rrtypes at the "**" node,
then go ahead and propose it.  if ietf approved such a standard, then BIND
will implement it.  i suspect that the process would be too long for SPF's
requirements.

> And to make it possible to identify dns records where such new wildcard 
> does need to be supported, I think we do need special prefix (and its not 
> too late as I don't even know any spf implementation that is doing zonecut  
> default checks yet). 

that's not a reason for a special prefix.  but as SOA is not cached, it is
not something that should be queried for other than as part of DNS operations
such as serial number queries governing IXFR/AXFR or UPDATE.  since SPF does
not yet do any zonecut checks, please remove that part of the draft.

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jan 2005 18:01:41 +0700

Date:        Tue, 11 Jan 2005 22:52:56 +0100
    From:        Stephane Bortzmeyer <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
  | lookup,

Huh?

I wrote 2181 - there is no "zone cut algorithm" in it.

It does describe what a zone cut is, and gives some properties,
but most certainly doesn't pretend there is some piece of magic
by which clients can discover where a cut exists.

Dynamic updates do something like that, but only from inside the
zone.

kre